[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200804200001.GA6212@openwall.com>
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.
