linux-kernel - Re: [PATCH] habanalabs: select CRC32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47e60186-2408-19cf-3231-92bd9c30483a@oracle.com>
Date:   Mon, 11 Oct 2021 18:29:02 +0200
From:   Vegard Nossum <vegard.nossum@...cle.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Oded Gabbay <ogabbay@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] habanalabs: select CRC32

On 10/11/21 5:33 PM, Arnd Bergmann wrote:
> On Mon, Oct 11, 2021 at 5:14 PM Vegard Nossum <vegard.nossum@...cle.com> wrote:
>>
>> Fix the following build/link error by adding a dependency on the CRC32
>> routines:
>>
>>   ld: drivers/misc/habanalabs/common/firmware_if.o: in function `hl_fw_dynamic_request_descriptor':
>>   firmware_if.c:(.text.unlikely+0xc89): undefined reference to `crc32_le'
>>
>> Signed-off-by: Vegard Nossum <vegard.nossum@...cle.com>
> 
> Patch looks good to me, I wonder how I never caught that with my own randconfig
> build testing. May I ask how you found it?
> 
> Fixes: 8a43c83fec12 ("habanalabs: load boot fit to device")
> Acked-by: Arnd Bergmann <arnd@...db.de>
> 

Thanks.

I'm working on a couple of new make targets, satconfig and
satrandconfig, which can generate .configs that respect a set of choices
specified in a .satconfig file (and, of course, the Kconfig files).

In this case, I was just doing satrandconfig builds and noticed that the
crc32_le ones popped up quite often so I just added CONFIG_CRC32=n to my
.satconfig, which means that satrandconfig will generate only configs
that have CRC32=n.

I also suspect that satrandconfig samples the configuration space MUCH
more uniformly than randconfig, in the sense that "make randconfig" will
tend to have CRC32 enabled just because there are so many drivers that
_do_ select it. (Think of it this way, every prompt for an option that
has "select CRC32" in it will be another 50% probability of actually
enabling the option.)

I just tried doing 'make randconfig' 100 times and the result was
CRC32=y every single time.

If I do the same for 'make satrandconfig', I get the following
distribution of values:

48 CRC32=y
10 CRC32=m
42 CRC32=n

That's probably still not really uniform, but quite a bit better, and as
I said I can still put CONFIG_CRC32=n in my .satconfig and get _only_
configs that respect this choice.

The really cool thing about sat{,rand}config IMHO is that you can fairly
easily generate random configs that you know will be bootable (because
you've forced it to only output configs that respect options that you
need to boot on your particular setup).

This project itself is about 11 years old, but I made a breakthrough
recently and I'm polishing the patches for submission now. I thought I
would try to fix the breakage that I could find first so it doesn't
appear as if the tool itself is broken... (that's not to say it doesn't
have any bugs, however!)

Vegard