All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Kees Cook <keescook@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: [kernel-hardening] Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR
Date: Sat, 3 Dec 2016 10:11:21 +0100	[thread overview]
Message-ID: <20161203091121.GA8502@kroah.com> (raw)
In-Reply-To: <20161203091057.GA8468@kroah.com>

On Sat, Dec 03, 2016 at 10:10:57AM +0100, Greg KH wrote:
> On Fri, Dec 02, 2016 at 01:32:24PM -0800, Kees Cook wrote:
> > On Thu, Dec 1, 2016 at 8:22 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> > > This adds two tests, to check that a read or write to LIST_POISON1 and
> > > ZERO_SIZE_PTR are blocked.
> > >
> > > The default values for both (256 and 16) typically fall in the range
> > > of valid user space addresses. However in general mmap_min_addr is 64K,
> > > which prevents user space from mapping anything at those addresses.
> > >
> > > However it's feasible that an attacker will be able to find a way to
> > > cause an access at an offset from either value, and if that offset is
> > > greater than 64K then they can access user space again.
> > >
> > > To simulate that case, in the test we create a user mapping at
> > > approximately mmap_min_addr, and offset the pointer by that amount. This
> > > gives the test the greatest chance of failing (ie. an access
> > > succeeding). We don't actually use mmap_min_addr, because that would
> > > require exporting it to modules, instead we use the default value at
> > > compile time as a reasonable approximation.
> > >
> > > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> > 
> > Thanks for this! I like it. :)
> > 
> > Acked-by: Kees Cook <keescook@chromium.org>
> > 
> > Greg, can you take this into your tree?
> 
> Sure, will do so on Monday.

Oops, no, I will not, kbuild reports build errors with it :(

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Kees Cook <keescook@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	"kernel-hardening@lists.openwall.com" 
	<kernel-hardening@lists.openwall.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR
Date: Sat, 3 Dec 2016 10:11:21 +0100	[thread overview]
Message-ID: <20161203091121.GA8502@kroah.com> (raw)
In-Reply-To: <20161203091057.GA8468@kroah.com>

On Sat, Dec 03, 2016 at 10:10:57AM +0100, Greg KH wrote:
> On Fri, Dec 02, 2016 at 01:32:24PM -0800, Kees Cook wrote:
> > On Thu, Dec 1, 2016 at 8:22 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> > > This adds two tests, to check that a read or write to LIST_POISON1 and
> > > ZERO_SIZE_PTR are blocked.
> > >
> > > The default values for both (256 and 16) typically fall in the range
> > > of valid user space addresses. However in general mmap_min_addr is 64K,
> > > which prevents user space from mapping anything at those addresses.
> > >
> > > However it's feasible that an attacker will be able to find a way to
> > > cause an access at an offset from either value, and if that offset is
> > > greater than 64K then they can access user space again.
> > >
> > > To simulate that case, in the test we create a user mapping at
> > > approximately mmap_min_addr, and offset the pointer by that amount. This
> > > gives the test the greatest chance of failing (ie. an access
> > > succeeding). We don't actually use mmap_min_addr, because that would
> > > require exporting it to modules, instead we use the default value at
> > > compile time as a reasonable approximation.
> > >
> > > Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> > 
> > Thanks for this! I like it. :)
> > 
> > Acked-by: Kees Cook <keescook@chromium.org>
> > 
> > Greg, can you take this into your tree?
> 
> Sure, will do so on Monday.

Oops, no, I will not, kbuild reports build errors with it :(

  reply	other threads:[~2016-12-03  9:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02  4:22 [kernel-hardening] [PATCH v2] lkdtm: Add tests for LIST_POISON and ZERO_SIZE_PTR Michael Ellerman
2016-12-02  4:22 ` Michael Ellerman
2016-12-02 21:32 ` [kernel-hardening] " Kees Cook
2016-12-02 21:32   ` Kees Cook
2016-12-03  9:10   ` [kernel-hardening] " Greg KH
2016-12-03  9:10     ` Greg KH
2016-12-03  9:11     ` Greg KH [this message]
2016-12-03  9:11       ` Greg KH
2016-12-03  7:24 ` [kernel-hardening] " kbuild test robot
2016-12-03  7:24   ` kbuild test robot

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=20161203091121.GA8502@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.