From: Eric Biggers <ebiggers@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Dmitry Vyukov <dvyukov@google.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
linux-security-module <linux-security-module@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Laura Abbott <labbott@redhat.com>,
Rik van Riel <riel@surriel.com>
Subject: Re: crypto: Kernel memory overwrite attempt detected to spans multiple pages
Date: Thu, 11 Apr 2019 13:56:41 -0700 [thread overview]
Message-ID: <20190411205640.GE225654@gmail.com> (raw)
In-Reply-To: <CAGXu5jJo0jXhB5Xy0fryrYPy7zN2RhSsMb0r0DPQ91dNR0zPCA@mail.gmail.com>
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@kernel.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
next prev parent reply other threads:[~2019-04-11 21:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-19 11:54 crypto: Kernel memory overwrite attempt detected to spans multiple pages Geert Uytterhoeven
2019-03-19 17:09 ` Eric Biggers
2019-03-20 18:57 ` Eric Biggers
2019-03-21 17:45 ` Kees Cook
2019-03-21 17:51 ` Eric Biggers
2019-04-10 3:17 ` Eric Biggers
2019-04-10 18:30 ` Kees Cook
2019-04-10 19:07 ` Eric Biggers
2019-04-10 21:57 ` Kees Cook
2019-04-10 23:11 ` Eric Biggers
2019-04-10 23:27 ` Kees Cook
2019-04-11 17:58 ` Eric Biggers
2019-04-11 18:33 ` Kees Cook
2019-04-11 19:26 ` Eric Biggers
2019-04-11 19:28 ` [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP Eric Biggers
2019-04-11 20:32 ` Kees Cook
2019-04-12 5:38 ` Dmitry Vyukov
2019-04-15 2:24 ` Matthew Wilcox
2019-04-15 2:46 ` Herbert Xu
2019-04-16 2:18 ` Matthew Wilcox
2019-04-16 3:14 ` Kees Cook
2019-04-17 4:08 ` Matthew Wilcox
2019-04-17 8:09 ` Russell King - ARM Linux admin
2019-04-17 9:54 ` Robin Murphy
2019-04-11 20:36 ` crypto: Kernel memory overwrite attempt detected to spans multiple pages Kees Cook
2019-04-11 20:56 ` Eric Biggers [this message]
2019-04-11 1:37 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190411205640.GE225654@gmail.com \
--to=ebiggers@kernel.org \
--cc=dvyukov@google.com \
--cc=geert@linux-m68k.org \
--cc=herbert@gondor.apana.org.au \
--cc=keescook@chromium.org \
--cc=labbott@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=riel@surriel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).