From: Kees Cook <keescook@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
linux-mm@kvack.org,
Muhammad Usama Anjum <usama.anjum@collabora.com>,
David Laight <David.Laight@aculab.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v3] usercopy: Check valid lifetime via stack depth
Date: Fri, 25 Feb 2022 17:35:49 -0800 [thread overview]
Message-ID: <202202251728.1634F405@keescook> (raw)
In-Reply-To: <20220225160157.680ecdea21ce81183059bb63@linux-foundation.org>
On Fri, Feb 25, 2022 at 04:01:57PM -0800, Andrew Morton wrote:
> On Fri, 25 Feb 2022 09:33:45 -0800 Kees Cook <keescook@chromium.org> wrote:
>
> > Under CONFIG_HARDENED_USERCOPY=y, when exact stack frame boundary checking
> > is not available (i.e. everything except x86 with FRAME_POINTER), check
> > a stack object as being at least "current depth valid", in the sense
> > that any object within the stack region but not between start-of-stack
> > and current_stack_pointer should be considered unavailable (i.e. its
> > lifetime is from a call no longer present on the stack).
> >
> > Introduce ARCH_HAS_CURRENT_STACK_POINTER to track which architectures
> > have actually implemented the common global register alias.
> >
> > Additionally report usercopy bounds checking failures with an offset
> > from current_stack_pointer, which may assist with diagnosing failures.
> >
> > The LKDTM USERCOPY_STACK_FRAME_TO and USERCOPY_STACK_FRAME_FROM tests
> > (once slightly adjusted in a separate patch) will pass again with
> > this fixed.
>
> Again, what does this actually do?
One of the things that CONFIG_HARDENED_USERCOPY checks is whether an
object is overlapping the stack at all. If it is, it performs a number
of inexpensive bounds checks. One of the finer-grained checks is whether
an object cross stack frame within the stack region. Doing this with
CONFIG_FRAME_POINTER was cheap/easy. Doing it with ORC is too heavy, and
was left out (a while ago), leaving the courser whole-stack check.
The LKDTM tests try to exercise the cross-frame cases to validate the
defense. They have been failing every since (which was expected). More
below...
>
> > Reported-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
>
> A link to that report would shed some light. But actually describing
> the user-visible impact right there in the changelog is preferable.
Yes, good point. The bug[1] involves multiple LKDTM tests and their
failure modes, so it wasn't a very clean pointer. But I will include it.
[1] https://github.com/kernelci/kernelci-project/issues/84
> It sounds like a selftest is newly failing, which makes it a
> userspace-visible regression, perhaps?
No, it's been failing since ORC was introduced, but the regression in
coverage (due to switching from FRAME_POINTER to ORC unwinder) was
minimal. While discussing this with Muhammad, I realized we did,
actually, have something that could be tested that was less than "the
entire stack area" and "each specific frame", and that was current stack
depth, so we gain back a little coverage.
> If so, do we have a Fixes: and is a cc:stable warranted?
I don't think it's warranted; it is technically a new feature.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2022-02-26 1:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 17:33 Kees Cook
2022-02-26 0:01 ` Andrew Morton
2022-02-26 1:35 ` Kees Cook [this message]
2022-02-26 1:46 ` Andrew Morton
2022-02-26 2:22 ` Kees Cook
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=202202251728.1634F405@keescook \
--to=keescook@chromium.org \
--cc=David.Laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=jpoimboe@redhat.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=usama.anjum@collabora.com \
--cc=willy@infradead.org \
/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