Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Grub custom ebuild with argon2 support
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
etnull
Guru
Guru


Joined: 26 Mar 2019
Posts: 464
Location: Russia

PostPosted: Sat Oct 03, 2020 10:43 pm    Post subject: Grub custom ebuild with argon2 support Reply with quote

I'm trying to hack-in the argon2 key derivation function support into Grub. The patchset was taken from the mailing list, original author Patrick Steinhardt. I'm not a programmer, now I'm stuck at the compilation stage with this error:
Code:
make[2]: Entering directory '/home/gentoo/gt/grub-gentoos/grub/grub-core'
make  all-am
make[3]: Entering directory '/home/gentoo/gt/grub-gentoos/grub/grub-core'
cat syminfo.lst | sort | gawk -f ./genmoddep.awk > moddep.lst || (rm -f moddep.lst; exit 1)
__moddi3 in argon2 is not defined
__umoddi3 in argon2 is not defined
make[3]: *** [Makefile:49858: moddep.lst] Error 1
make[3]: Leaving directory '/home/gentoo/gt/grub-gentoos/grub/grub-core'
make[2]: *** [Makefile:27732: all] Error 2
make[2]: Leaving directory '/home/gentoo/gt/grub-gentoos/grub/grub-core'
make[1]: *** [Makefile:12018: all-recursive] Error 1
make[1]: Leaving directory '/home/gentoo/gt/grub-gentoos/grub'
make: *** [Makefile:3784: all] Error 2

Can someone help me to figure this out? Here is my overlay:
https://gitlab.com/odx/overlay/-/tree/master/sys-boot/grub
Back to top
View user's profile Send private message
GDH-gentoo
Guru
Guru


Joined: 20 Jul 2019
Posts: 543
Location: South America

PostPosted: Sun Oct 04, 2020 7:02 pm    Post subject: Reply with quote

The patchset modifies two Makefile.*.def files; doing an eautoreconf in the ebuild is not enough. I'll have a closer look to see if I can suggest a fix.
Back to top
View user's profile Send private message
GDH-gentoo
Guru
Guru


Joined: 20 Jul 2019
Posts: 543
Location: South America

PostPosted: Sun Oct 04, 2020 10:30 pm    Post subject: Reply with quote

Well, after regenerating Makefile.util.am and grub-core/Makefile.core.am, the build fails with the same error. So after investigating some more, I now think that the patches you have in your repository are not ready for use yet. I don't know if there is some more recent version of them, but here's what I've found.

There are two errors, one that is independent of GRUB_PLATFORMS, and one that manifests for GRUB_PLATFORMS=pc (i.e. for BIOS installs).

First one:
Code:
x86_64-pc-linux-gnu-gcc [...] -c -o grub-core/lib/argon2/libgrubkern_a-core.o `test -f 'grub-core/lib/argon2/core.c' ||
   echo '/var/tmp/portage/sys-boot/grub-2.05_alpha20200310/work/grub-2.05_alpha20200310/'`grub-core/lib/argon2/core.c

/var/tmp/portage/sys-boot/grub-2.05_alpha20200310/work/grub-2.05_alpha20200310/grub-core/lib/argon2/core.c: In function ‘secure_wipe_memory’:
/var/tmp/portage/sys-boot/grub-2.05_alpha20200310/work/grub-2.05_alpha20200310/grub-core/lib/argon2/core.c:135:5: warning: implicit declaration of function ‘explicit_bzero’ [-Wimplicit-function-declaration]
/var/tmp/portage/sys-boot/grub-2.05_alpha20200310/work/grub-2.05_alpha20200310/grub-core/lib/argon2/core.c:135:5: warning: nested extern declaration of ‘explicit_bzero’ [-Wnested-externs]
sys-boot/grub/files/argon2-patch3.patch
Code:
--- /dev/null
+++ b/grub-core/lib/argon2/core.c
[...]
+#if defined(__OpenBSD__)
+#define HAVE_EXPLICIT_BZERO 1
+#elif defined(__GLIBC__) && defined(__GLIBC_PREREQ)
+#if __GLIBC_PREREQ(2,25)
+#define HAVE_EXPLICIT_BZERO 1
+#endif
+#endif
+
+void NOT_OPTIMIZED secure_wipe_memory(void *v, grub_size_t n) {
+#if defined(_MSC_VER) && VC_GE_2005(_MSC_VER)
+    SecureZeroMemory(v, n);
+#elif defined grub_memset_s
+    grub_memset_s(v, n, 0, n);
+#elif defined(HAVE_EXPLICIT_BZERO)
+    explicit_bzero(v, n);
+#else
+    static void *(*const volatile grub_memset_sec)(void *, int, grub_size_t) = &grub_memset;
+    grub_memset_sec(v, 0, n);
+#endif
This logic appears to be wrong. The checks for macros __GLIBC__ and __GLIBC_PREREQ will pick the call of explicit_bzero(), but the header that declares it is not included (<string.h>).

Second, and most important one:
Code:
x86_64-pc-linux-gnu-gcc [...] -m32 -nostdinc [...] -c -o lib/argon2/argon2_module-core.o `test -f 'lib/argon2/core.c' ||
   echo '/var/tmp/portage/sys-boot/grub-2.05_alpha20200310/work/grub-2.05_alpha20200310/grub-core/'`lib/argon2/core.c
x86_64-pc-linux-gnu-gcc [...] -m32 -nostdinc [...] -c -o lib/argon2/argon2_module-ref.o `test -f 'lib/argon2/ref.c' ||
   echo '/var/tmp/portage/sys-boot/grub-2.05_alpha20200310/work/grub-2.05_alpha20200310/grub-core/'`lib/argon2/ref.c
OK, for GRUB_PLATFORMS=pc, these are compiled with -m32 (use only 32-bit instructions), and this results in:
Code:
$ nm /var/tmp/portage/sys-boot/grub-2.05_alpha20200310/work/grub-2.05_alpha20200310-pc/grub-core/lib/argon2/argon2_module-ref.o:
         [...]
         U __moddi3
         U __umoddi3
$ nm /var/tmp/portage/sys-boot/grub-2.05_alpha20200310/work/grub-2.05_alpha20200310-pc/grub-core/lib/argon2/argon2_module-core.o:
         [...]
         U __umoddi3
That is, the source files contain some language constructs that make GCC emit calls to functions __moddi3() and __umoddi3(). Where are these? They are in the 32-bit version of libgcc:
Code:
$ nm /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/32/libgcc.a
_moddi3.o:
00000000 T __moddi3
[...]
_umoddi3.o:
00000000 T __umoddi3
However, module argon2 is built like this:
Code:
x86_64-pc-linux-gnu-gcc -Os -m32 [...] -nostdlib [...] -o argon2.module lib/argon2/argon2_module-argon2.o lib/argon2/argon2_module-core.o lib/argon2/argon2_module-ref.o lib/argon2/blake2/argon2_module-blake2b.o
Building a GRUB module with -nostdlib is probably correct, since GRUB does not run on an operating system, so it cannot link to system libraries. But this option also means that it won't be linked to libgcc either, resulting in undefined symbols that cause the build failure.

Quote:
GRUB imports the official reference implementation of Argon2 from https://github.com/P-H-C/phc-winner-argon2. In order to make the library usable for GRUB, we need to perform various conversions.
I guess the necessary conversions are not complete...
Back to top
View user's profile Send private message
etnull
Guru
Guru


Joined: 26 Mar 2019
Posts: 464
Location: Russia

PostPosted: Sun Oct 04, 2020 11:14 pm    Post subject: Reply with quote

Thanks, I can't participate in a discussion of this in any meaningful way because of my incompetence.
This post of his gave me hope that it could work, maybe it doesn't after all.
Quote:
One addition with LUKS2 was support of the key derival function Argon2
in addition to the previously supported PBKDF2 algortihm. In order to
ease getting in initial support for LUKS2, we only reused infrastructure
to support LUKS2 with PBKDF2, but left out Argon2.

This commit now introduces support for Argon2 to enable decryption of
LUKS2 partitions using this key derival function. As the code for Argon2
has been added in a previous commit in this series, adding support is
now trivial.

https://lists.gnu.org/archive/html/grub-devel/2020-03/msg00108.html
Back to top
View user's profile Send private message
reagentoo
n00b
n00b


Joined: 01 Aug 2016
Posts: 6

PostPosted: Wed Nov 04, 2020 10:33 am    Post subject: Reply with quote

GDH-gentoo wrote:
There are two errors, one that is independent of GRUB_PLATFORMS, and one that manifests for GRUB_PLATFORMS=pc (i.e. for BIOS installs).

Thank you for your exploration. Actually I see no point in using the 'pc' with this patchset. I see only QA problem:
Code:
 * QA Notice: Package triggers severe warnings which indicate that it
 *            may exhibit random runtime failures.
 * /var/tmp/portage/sys-boot/grub-9999/work/grub-9999/grub-core/lib/argon2/core.c:135:5: warning: implicit declaration of function ‘explicit_bzero’ [-Wimplicit-function-declaration]

After build with GRUB_PLATFORMS="efi-64" I tested it. But I can say cryptomount decryption still slow (ab. 30 second on 8kb key)
I've added argon2_v2 patchset here (I think it's no different from etnull's patches)
BTW this repo also contains johnlane's cryptopatch branch with added luks2 support: https://github.com/reagentoo/grub/tree/cryptopatch_v5
and partuuid improvements for search cmd: https://github.com/reagentoo/grub/tree/search_partuuid
Back to top
View user's profile Send private message
etnull
Guru
Guru


Joined: 26 Mar 2019
Posts: 464
Location: Russia

PostPosted: Wed Nov 04, 2020 11:44 am    Post subject: Reply with quote

reagentoo, does it work for efi-64? I mean you could decrypt if luks volume was created with --type luks2 --pbkdf argon2id ?

Quote:
But I can say cryptomount decryption still slow (ab. 30 second on 8kb key)

In my tests it isn't the keysize which slows things down, but the iterations. if I set 5000 iterations it takes forever on my system, 2000 is better but still quite slow, also the slownes is the point, you don't want to be able to guess 1000 keys a second.
Back to top
View user's profile Send private message
reagentoo
n00b
n00b


Joined: 01 Aug 2016
Posts: 6

PostPosted: Wed Nov 04, 2020 1:08 pm    Post subject: Reply with quote

etnull wrote:
reagentoo, does it work for efi-64? I mean you could decrypt if luks volume was created with --type luks2 --pbkdf argon2id ?

Yes, it compiles and works only for efi-64. I tested it with argon2i which is default for --type luks2:
Code:
cryptsetup luksDump --key-file /path/to/key --header /path/to/hdr /dev/sde3 | grep PBKDF
PBKDF:      argon2i

etnull wrote:
In my tests it isn't the keysize which slows things down, but the iterations. if I set 5000 iterations it takes forever on my system, 2000 is better but still quite slow, also the slownes is the point, you don't want to be able to guess 1000 keys a second.

I haven't tried specifying a different number of iterations. But I wonder how this can be done.

P.s.: another discussion thread here: https://github.com/johnlane/grub/issues/21
Back to top
View user's profile Send private message
etnull
Guru
Guru


Joined: 26 Mar 2019
Posts: 464
Location: Russia

PostPosted: Wed Nov 04, 2020 3:19 pm    Post subject: Reply with quote

good to know, unfortunately I'm on legacy bios.
Back to top
View user's profile Send private message
reagentoo
n00b
n00b


Joined: 01 Aug 2016
Posts: 6

PostPosted: Wed Nov 04, 2020 7:47 pm    Post subject: Reply with quote

etnull wrote:
good to know, unfortunately I'm on legacy bios.

I've come to the conclusion that there is no point in using kdf keys for grub. The master key is only 64 bytes long and it verifies in a second (luks2_verify_key).
For my usage pattern, using a header and a master key is enough. And I see no reason to wait for official support for argon2. Maybe I'll create a new cryptopatch for grub for this pattern. And it will be easier.
I am not an expert in cryptography, so if anyone sees any disadvantages in this usage pattern (header+master_key), please let me know.


Last edited by reagentoo on Wed Nov 04, 2020 8:34 pm; edited 1 time in total
Back to top
View user's profile Send private message
etnull
Guru
Guru


Joined: 26 Mar 2019
Posts: 464
Location: Russia

PostPosted: Wed Nov 04, 2020 8:32 pm    Post subject: Reply with quote

I use keyfile just to make it more convenient, one single passphrase decrypts all of my drives. I know almost nothing about cryptography, but If people infinitely smarter than me are doing research and implementation in this direction, I assume it's quite important, either right now, or will be in the midterm future. Though, again, mostly depends on your threat model and potential adversary, is your stuff costs more than 1000x(RTX3080TI) needed to crack you? most likely not...
Back to top
View user's profile Send private message
GDH-gentoo
Guru
Guru


Joined: 20 Jul 2019
Posts: 543
Location: South America

PostPosted: Wed Nov 04, 2020 8:39 pm    Post subject: Reply with quote

reagentoo wrote:
I see only QA problem:
Code:
 * QA Notice: Package triggers severe warnings which indicate that it
 *            may exhibit random runtime failures.
 * /var/tmp/portage/sys-boot/grub-9999/work/grub-9999/grub-core/lib/argon2/core.c:135:5: warning: implicit declaration of function ‘explicit_bzero’ [-Wimplicit-function-declaration]

Yes, that's error #1 identified in my previous post, and even though GCC somehow allows this to compile with only a warning, it would make me suspect about the resulting build being subtly broken.
Back to top
View user's profile Send private message
reagentoo
n00b
n00b


Joined: 01 Aug 2016
Posts: 6

PostPosted: Wed Nov 04, 2020 8:55 pm    Post subject: Reply with quote

etnull wrote:
I use keyfile just to make it more convenient, one single passphrase decrypts all of my drives. I know almost nothing about cryptography, but If people infinitely smarter than me are doing research and implementation in this direction, I assume it's quite important, either right now, or will be in the midterm future. Though, again, mostly depends on your threat model and potential adversary, is your stuff costs more than 1000x(RTX3080TI) needed to crack you? most likely not...

If I understand correctly, argon2 (and old pbkdf2 method) is just needed for users who like short passphrases. But this greatly affects the performance of master_key decryption. Therefore, I think it is advisable to use the master key directly. Maybe I'm wrong.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum