[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HELP] cryptomount is slow, what is the proper way to [PATCH] libgcr

From: Vladimir 'phcoder' Serbinenko
Subject: Re: [HELP] cryptomount is slow, what is the proper way to [PATCH] libgcrypt-grub?
Date: Sat, 27 Jan 2018 00:42:19 +0000

On Thu, 25 Jan 2018, 14:57 , <address@hidden> wrote:
phcoder and everyone else on the list, hello.

As many of you know, the builtin LUKS decryption in GRUB is a major feature
that enables many advanced setups, such as coreboot-based Full Disk Encryption.

However, it has been reported [1] the speed of cryptomount is extremely slow.
On my box, if a large number of iterations is used (by default), GNU/Linux takes
2 seconds to derive the LUKS master key, while on GRUB, it takes about 40 seconds.

It strongly affects the usability of LUKS on GRUB. On one hand, if user chooses
a large number of iterations, GRUB will take at least 40 seconds to unlock an
encrypted partition. If a typo is made while entering the passphrase, it will
be even slower. It forces many users to choose a smaller number of iterations, but
it makes the passphrase more vulnerable to brute-force attacks from modern CPUs
and GPUs with their ever-increasing computational power, and thus discouraged by
LUKS developers. The performance issue must be solved.

I've investigated the cause of the issue, and I found the culprit is the
C-implementation of SHA-512 hash function, which is essential for a 256-bit
encryption setup. Since SHA-512 manipulates 64-bit integers, its performance is
very poor on x86.

Now, I'm working on some GRUB hacking to integrate a SSE2-optimized version of
SHA512 hash function for GRUB on x86. It would boost the performance of key
derivation by 400%. I've already added the implementation to libgcrypt-grub, and
it would be automatically selected based on CPUID, in the same way as libgcrypt
does it in the upstream.
In GRUB SSE registers are disabled. If you want to use SSE, you need to make sure you enable them and that they are disabled again before kernel handoff

The problem is, when I has finished these improvements, and tried to compile
GRUB, I realized the libgcrypt in GRUB is somehow automatically imported from
the upstream, and preprocessed by I've read and
found it was complicated, it generates new code, compiler flags, etc, and pack
different algorithms to loadable modules.

I have no idea about how to integrate my changes. For example, how to link .c
and .S assembly together in the same GRUB module by changing
I can't understand. From some comments, modifications of libgcrypt itself is not
allowed at all, and should do all the additional fixups?
Yes, just put your version of libgcrypt there and rerun ./

So what is the proper way to add new code and optimizations to libgcrypt-grub,
and integrate it to GRUB?

Happy Hacking,
Tom Li


reply via email to

[Prev in Thread] Current Thread [Next in Thread]