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  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:   Tue, 4 Apr 2017 08:46:02 -0700
From:   Kees Cook <>
To:     Michal Hocko <>
Cc:     Christoph Lameter <>,
        Andrew Morton <>,
        Pekka Enberg <>,
        David Rientjes <>,
        Joonsoo Kim <>,
        Linux-MM <>,
        LKML <>
Subject: Re: [PATCH] mm: Add additional consistency check

On Tue, Apr 4, 2017 at 8:16 AM, Michal Hocko <> wrote:
> On Tue 04-04-17 10:07:23, Cristopher Lameter wrote:
>> On Tue, 4 Apr 2017, Michal Hocko wrote:
>> > NAK without a proper changelog. Seriously, we do not blindly apply
>> > changes from other projects without a deep understanding of all
>> > consequences.
>> Functionalitywise this is trivial. A page must be a slab page in order to
>> be able to determine the slab cache of an object. Its definitely not ok if
>> the page is not a slab page.
> Yes, but we do not have to blow the kernel, right? Why cannot we simply
> leak that memory?

I can put this behind CHECK_DATA_CORRUPTION() instead of BUG(), which
allows the system builder to choose between WARN and BUG. Some people
absolutely want the kernel to BUG on data corruption as it could be an

>> The main issue that may exist here is the adding of overhead to a critical
>> code path like kfree().
> Yes, nothing is for free. But if the attack space is real then we
> probably want to sacrifice few cycles (to simply return ASAP without
> further further processing). This all should be in the changelog ideally
> with some numbers. I suspect this would be hard to measure in most
> workloads.

Given the trivial nature of the check, yeah, it seemed impossible to
actually show performance changes.


Kees Cook
Pixel Security

Powered by blists - more mailing lists