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, 11 Apr 2019 13:56:41 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Laura Abbott <labbott@...hat.com>,
        Rik van Riel <riel@...riel.com>
Subject: Re: crypto: Kernel memory overwrite attempt detected to spans
 multiple pages

On Thu, Apr 11, 2019 at 01:36:37PM -0700, Kees Cook wrote:
> On Thu, Apr 11, 2019 at 12:26 PM Eric Biggers <ebiggers@...nel.org> wrote:
> > Well, I guess I'll just add __GFP_COMP so I at least don't get spammed with
> > useless bug reports.
> 
> Thanks, I appreciate it.
> 
> > But I don't think it's in any way acceptable to change the semantics of the
> > kernel's page allocator but only under some obscure config option, don't
> > document it anywhere, ignore the known problems for years, say that the option
> > is broken anyway so it shouldn't be used, and have to exchange 15 emails to get
> > anything resembling an explanation.
> 
> I understand what you mean, yeah. I'm sorry I wasn't clear about it
> earlier. What do you think might help the situation as far as
> documentation?
> 

Explanation in Documentation/core-api/memory-allocation.rst of when to use
__GFP_COMP and why.  Where "why" includes the real underlying reason why it's
designed the way it is, not just "you now need to provide this flag in order to
stop the hardened usercopy thing from crashing, even though previously it meant
something else, because that's the way it is."

Also a brief, improved explanation of __GFP_COMP in include/linux/gfp.h.

Also get Documentation/security/self-protection.rst up to date with what's
actually in the kernel.  Currently it doesn't mention hardened usercopy at all,
and it's unclear about what's supported now vs. what is future work.

And actually fix the known problems with the pagespan check, not ignore them for
years.  If not feasible, remove the option.

- Eric

Powered by blists - more mailing lists