Date: Tue, 4 Aug 2020 22:00:01 +0200 From: Solar Designer <solar@...nwall.com> To: lkrg-users@...ts.openwall.com Subject: Re: lkrg: Fix build LKRG for kernel 5.8+ Hi, On Thu, Jul 09, 2020 at 05:53:43PM +0300, Andy Lavr wrote: > Fix for kernel 5.8+: > > --- p_lkrg_main.h.orig 2020-07-09 08:47:17.958122925 +0300 > +++ p_lkrg_main.h 2020-07-09 11:03:47.754854373 +0300 > @@ -60,7 +62,11 @@ > > #include <linux/signal.h> > #include <linux/timex.h> > +#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,8,0) > +#include <crypto/sha.h> > +#else > #include <linux/cryptohash.h> > +#endif > > #include <linux/stacktrace.h> > #include <asm/stacktrace.h> Thank you for this contribution, Andy! I was hoping Adam would take care of this, but he was busy and now Linux 5.8 is out and we should include a fix without further delay. So I took a look myself. So Linux 5.8 in fact moved linux/cryptohash.h to crypto/sha.h. However, what do we need that header file for? Per my analysis, we only make use of it on older kernels (< 4.4.72 or < RHEL 7.4) for the one use of md5_transform() in get_random_long(). On newer kernels, we simply use the kernel-provided get_random_long(). Further, 5.8's crypto/sha.h doesn't declare md5_transform() anyway (linux/cryptohash.h on much older kernels did). So I think a cleaner fix would be to wrap #include <linux/cryptohash.h> inside an #if with the same condition that we use to decide whether to define a custom get_random_long(). And longer-term I'd like to revisit that custom get_random_long() and its safety. I've just pushed that fix to: https://github.com/openwall/lkrg And yes, we're moving from Bitbucket to GitHub. Thanks again, Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.