From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1eei1p-0006Ms-72 for mharc-grub-devel@gnu.org; Thu, 25 Jan 2018 08:57:21 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eei1n-0006J6-2H for grub-devel@gnu.org; Thu, 25 Jan 2018 08:57:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eei1i-0004uj-G1 for grub-devel@gnu.org; Thu, 25 Jan 2018 08:57:19 -0500 Received: from tomli.me ([2a00:1a28:1157:199::5a76]:45990) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eei1i-0004q4-4O for grub-devel@gnu.org; Thu, 25 Jan 2018 08:57:14 -0500 Received: from tomli.me (localhost [127.0.0.1]) by tomli.me (OpenSMTPD) with ESMTP id 1ebfb8a9; Thu, 25 Jan 2018 13:57:08 +0000 (UTC) X-HELO: x220 Authentication-Results: tomli.me; auth=pass (login) smtp.auth=tomli; iprev=fail Received: from solidresearchbase.com (HELO x220) (163.172.209.4) by tomli.me (qpsmtpd/0.95) with ESMTPSA (DHE-RSA-CHACHA20-POLY1305 encrypted); Thu, 25 Jan 2018 13:57:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=tomli.me; h=date:from:to:cc:subject:message-id:mime-version:content-type; s=1490979754; bh=IJaVQdb/3sxUf+wXyPwxAe3Qm/bioyZPt3fa/BbxdEE=; b=SNR0XCmGZeJyMO/4j7MFzpuy1/+AKLHdv8ncSy1v1eJgVzwHMIPzZmXzRWTmvQS3kR/Gi0JssBBRhlRRVuWiO+gg4nfhpf65yP02Xezfgye7YLj2PyVqauYrF1R43Gx/JE4b+m0D+fy+3VpqCzCdJUNNH8vkynF3WSTJlQMxwqkfKrvD2CwxAodmI1Q4TiO5sxRmq48mC0/RhqtK3GOXjVNkwTR4exedkMo5PXh6GginVSwEtdO0bfcj6HZr7GNUzL9/1tsp6F81j0I5W/06yWIz5wxW7GiigmXr8Ldotr2H9xuQ54K2NOzucueu7vJUqhIJnfM7bwpUvTrwfHrhag== Date: Thu, 25 Jan 2018 21:56:55 +0800 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? Message-ID: <20180125135655.GA45678@x220> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1a28:1157:199::5a76 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 13:57:20 -0000 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