linux-kernel - Re: [PATCH v4 6/8] x86: bump ZO_z_extra

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]

Date:   Thu, 2 Apr 2020 20:25:49 +0000
From:   Nick Terrell <terrelln@...com>
To:     Borislav Petkov <bp@...en8.de>
CC:     Nick Terrell <nickrterrell@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Chris Mason <clm@...com>,
        "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Petr Malat <oss@...at.biz>, Kees Cook <keescook@...omium.org>,
        Kernel Team <Kernel-team@...com>,
        Adam Borowski <kilobyte@...band.pl>,
        Patrick Williams <patrickw3@...com>,
        "Michael van der Westhuizen" <rmikey@...com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "Patrick Williams" <patrick@...cx.xyz>,
        Sedat Dilek <sedat.dilek@...il.com>
Subject: Re: [PATCH v4 6/8] x86: bump ZO_z_extra_bytes margin for zstd

> On Apr 2, 2020, at 8:58 AM, Borislav Petkov <bp@...en8.de> wrote:
> 
> On Wed, Apr 01, 2020 at 05:33:03PM +0000, Nick Terrell wrote:
>> The code is currently written so that all the compression algorithms use the
>> same ZO_z_extra_bytes. It is taken to be the maximum of the growth rate
>> plus the maximum fixed overhead. Just a few lines above is the comment:
>> 
>> # … Hence safety
>> # margin should be updated to cover all decompressors so that we don't
>> # need to deal with each of them separately. Please check
>> # the description in lib/decompressor_xxx.c for specific information.
>> 
>> So I was been following the guidance in the comments.
> 
> Please state that in the commit message when you send your next
> revision.

Will do.

>> Does it matter? I’m not an expert here,
> 
> Huh, you're only sending the code then? Or what do you mean with not
> being an expert?

I mean that while I’ve read and understood this piece of the code, have tested
the patches, have followed the template of other compression methods
added, and am confident in the correctness of the code, I’m not a regular
contributor to the pre-boot x86 kernel code. So it is possible that there is a
use case for kernel compression that I’m not aware of where RAM is extremely
tight and within 64 KB of the current limits.

It seems to me that adding 64KB to the memory requirement for kernel
decompression is not going to break anyone. If it did the kernel image is taking
up nearly all available RAM, which doesn’t seem likely. But, I don’t know all
use cases. If it does break someone, we can put up a separate patch that
switches all the compression methods over a per-method ZO_z_extra_bytes.

Best,
Nick