From: tomli@tomli.me
To: grub-devel@gnu.org
Cc: phcoder@gmail.com
Subject: [HELP] cryptomount is slow, what is the proper way to [PATCH] libgcrypt-grub?
Date: Thu, 25 Jan 2018 21:56:55 +0800 [thread overview]
Message-ID: <20180125135655.GA45678@x220> (raw)
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.
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 import_gcry.py. I've read import_gcry.py 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 import_gcry.py?
I can't understand. From some comments, modifications of libgcrypt itself is not
allowed at all, and import_gcry.py should do all the additional fixups?
So what is the proper way to add new code and optimizations to libgcrypt-grub,
and integrate it to GRUB?
Happy Hacking,
Tom Li
[1] http://lists.gnu.org/archive/html/grub-devel/2016-10/msg00018.html
next reply other threads:[~2018-01-25 13:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-25 13:56 tomli [this message]
2018-01-27 0:42 ` [HELP] cryptomount is slow, what is the proper way to [PATCH] libgcrypt-grub? Vladimir 'phcoder' Serbinenko
2018-01-28 9:03 ` tomli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180125135655.GA45678@x220 \
--to=tomli@tomli.me \
--cc=grub-devel@gnu.org \
--cc=phcoder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.