From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tobias Geerinckx-Rice Subject: Re: GRUB LUKS support is slow? Date: Sat, 16 Dec 2017 02:10:24 +0100 Message-ID: <323370e6-660e-0e7e-065b-39a7346c22cc@tobias.gr> References: <87a7yjfy15.fsf@gnu.org> <87po7fzjqc.fsf@netris.org> <13AFAEE7-656C-4DC8-ACA5-A6F01DD89748@vany.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQ0xF-0002bh-Cb for guix-devel@gnu.org; Fri, 15 Dec 2017 20:07:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQ0xE-0004zD-3p for guix-devel@gnu.org; Fri, 15 Dec 2017 20:07:53 -0500 In-Reply-To: <13AFAEE7-656C-4DC8-ACA5-A6F01DD89748@vany.ca> Content-Language: en-GB List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: adam@vany.ca, guix-devel@gnu.org, mhw@netris.org, ludo@gnu.org Guix, I'm afraid you'll all be somewhat disappointed by the answer... Adam Van Ymeren wrote on 16/12/17 at 00:25: > On December 15, 2017 5:53:15 PM EST, Mark H Weaver > wrote: >> ludo@gnu.org (Ludovic Courtès) writes: >> >>> I have an encrypted root. When GRUB asks me for my passphrase, >>> it takes 5–10 seconds after I hit enter before it displays the >>> menu; then, once I've selected an entry, it takes another 5 seconds >>> or so to boot. >>> >>> It’s always been this way for me (that’s on UEFI), but I’m >>> sufficiently annoyed to write this message today. :-) >>> >>> Are others experiencing this as well? Any hints? >> >> I also use a LUKS-encrypted root partition, and the same thing >> happens to me. I would guess that the cryptographic operations in >> GRUB are not well optimized, but I haven't looked closely. >> >> Mark > > Even unoptimized 5-10s seems pretty long. It's not like it has a > lot of data to process. Alas, you'd be wrong :-) The whole point of the key derivation function (PBKDF2 in this case) is to take a long time — i.e., generate *a lot* of data — before deriving the actual encryption key from your passphrase. It's basically a slow hash, run many times over. That's the delay we're talking about here. PBKDF2 is designed to be ‘impossible’ to optimise, parallelise, or cut short[0], so there's no way around running several seconds of busy work before you can even check a passphrase. On GuixSD, the default run time is: $ cryptsetup --help | grep iteration -i, --iter-time=msecs PBKDF2 iteration time for LUKS (in ms) Default PBKDF2 iteration time for LUKS: 2000 (ms) However, this run time is measured at volume creation time, with all fancy CPU features available. It wouldn't surprise me if real-mode[1] GRUB and the early kernel code are badly optimised and take longer to complete the same number of iterations to obtain the key. Furthermore, as Ludo' discovered, it's very likely that both GRUB *and* Linux will have to re-calculate the key, doubling the total time. > I have an encrypted root as well, I don't think it takes 5s after I > enter the passphrase to get the grub men, maybe 1 or 2. Next time I > reboot I'll make a note of it. It takes about ~7s on my systems (rough guess; they're all servers so I'm not that impatient). It should *never* take less than 2 seconds unless you or your distro changed ‘--iter-time’, or your volumes were encrypted on a different, slower machine, or something's just wrong. * * * TLDR: unfortunately, these delays sound quite normal. Aside from writing optimised PBKDF2 implementations that can run in whatever CPU modes GRUB does[1], the only way to significantly reduce the wait is to use a lower ‘--iter-time’ when creating volumes. It's probably not worth it. Your box will boot a few seconds faster; your attacker just saw their brute-force speeds double — or worse. Kind regards, T G-R [0]: This is from memory, but should be correct for all practical purposes. [1]: I presume real-mode; don't ask me how UEFI affects all this.