From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id CB757138A6C for ; Sat, 18 Apr 2015 13:46:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 87077E0882; Sat, 18 Apr 2015 13:45:56 +0000 (UTC) Received: from mail.ramses-pyramidenbau.de (ramses-pyramidenbau.de [46.38.238.63]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 55C10E085B for ; Sat, 18 Apr 2015 13:45:54 +0000 (UTC) Received: from [IPv6:2a02:810d:8440:554:cddf:15cb:93e:b4a4] (unknown [IPv6:2a02:810d:8440:554:cddf:15cb:93e:b4a4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ramses-pyramidenbau.de (Postfix) with ESMTPSA id B665881D1B for ; Sat, 18 Apr 2015 15:45:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ramses-pyramidenbau.de; s=default; t=1429364751; bh=E90+Fp9lgXTaMl4/KsJfXUmkz6amb4IzIi3ObwWNVnU=; h=Date:From:To:Subject:References:In-Reply-To; b=G919VXyg2mfMLxpYXzpCVbPTZEU4/KGsFTk9OFFIv+eyXB6GjPAYYBHW+QP1+GRaT UTbJ7kVSmEeRv80hEKFCfAO/VYufj59RtwJLp1Zc/EVn7+LfUfERw2AGWzJNkYyRB+ D9Fdbg5G9EIhc4k8RkKeZPj0Zr6C33qeq2VVT7lY= Message-ID: <55326014.8020901@ramses-pyramidenbau.de> Date: Sat, 18 Apr 2015 15:45:56 +0200 From: Ralf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] cryptsetup wont use aes-xts:plain64 References: <553248F4.1070306@baums-on-web.de> <55324A34.8060600@ramses-pyramidenbau.de> <553251A7.10205@baums-on-web.de> In-Reply-To: <553251A7.10205@baums-on-web.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 3171f03c-cb71-48cc-a5b2-45bc2bdfe6c7 X-Archives-Hash: 7bc6169eebc67a83b4375a0bb3a5bb8f Hi, @Marko tl;dr: it's going a bit offtopic. Marko, try to hardcompile those modules into your kernel. This should be the simplest fix of your problem. On 04/18/2015 02:44 PM, Heiko Baums wrote: > Am 18.04.2015 um 14:12 schrieb Ralf: > >> No. Could you please explain why you think so? >> Even if your root partition is encrypted, your ramdisk could load the >> modules. > Are you sure about that? Are you sure that the necessary modules are > definitely put into the initrd and that the kernel will be able to load > them soon enough at boot time? I double checked it and now I am sure: For reasons of comfortability I inspected a standard Arch-Linux installation. It supports rootfs encryption and xts is loaded in the initrd as module. So it is possible to treat it as a module. Besides that: Why should your kernel config allow you to compile it as module if it isn't useable as module? > > Compiling those modules into the kernel is definitely more secure (in > terms of being sure that they are always available) and doesn't do any > harm, because they need to be loaded anyway. Yes for a homebrew kernel, i can second that. > > Btw., several dm-crypt/LUKS documentation (all that I've read) say that > those modules have to be compiled into the kernel directly. > >> After loading the modules you can see that they are available by cat >> /proc/crypto. > You won't be able to run this command when the kernel tries to unlock > the LUKS container at boot time. No, but it is accessible when creating your LUKS volume, and that's Marko problem at the moment. > >> The modules can be loaded _after_ bootup as well. > If you want to unlock the LUKS container at boot time (particularly if > your root partition is encrypted), loading the modules after bootup is > too late. Loading those modules during the early bootup phase in your initrd is actually not too late. Ah, and for completeness sake: Grub2 is able to speak LUKS. So your kernel and initrd maybe inside an encrypted volume. > > So I wouldn't risk it. Neither do I. Cheers Ralf