From: Matt Mackall <mpm@selenic.com>
To: Vasiliy Kulikov <segoon@openwall.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
kernel-hardening@lists.openwall.com,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Arnd Bergmann <arnd@arndb.de>,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org
Subject: [kernel-hardening] Re: [RFC v2] implement SL*B and stack usercopy runtime checks
Date: Mon, 18 Jul 2011 14:08:22 -0500 [thread overview]
Message-ID: <1311016102.23043.235.camel@calx> (raw)
In-Reply-To: <20110718183951.GA3748@albatros>
On Mon, 2011-07-18 at 22:39 +0400, Vasiliy Kulikov wrote:
> This patch implements 2 additional checks for the data copied from
> kernelspace to userspace and vice versa (original PAX_USERCOPY from PaX
> patch). Currently there are some very simple and cheap comparisons of
> supplied size and the size of a copied object known at the compile time
> in copy_* functions. This patch enhances these checks to check against
> stack frame boundaries and against SL*B object sizes.
>
> More precisely, it checks:
>
> 1) if the data touches the stack, checks whether it fully fits in the stack
> and whether it fully fits in a single stack frame. The latter is arch
> dependent, currently it is implemented for x86 with CONFIG_FRAME_POINTER=y
> only. It limits infoleaks/overwrites to a single frame and local variables
> only, and prevents saved return instruction pointer overwriting.
>
> 2) if the data is from the SL*B cache, checks whether it fully fits in a
> slab page and whether it overflows a slab object. E.g. if the memory
> was allocated as kmalloc(64, GFP_KERNEL) and one tries to copy 150
> bytes, the copy would fail.
FYI, this should almost certainly be split into (at least) two patches:
- the stack check
- the SL*B check (probably one patch per allocator, preceded by one for
any shared infrastructure)
--
Mathematics is the supreme nostalgia of our time.
WARNING: multiple messages have this Message-ID (diff)
From: Matt Mackall <mpm@selenic.com>
To: Vasiliy Kulikov <segoon@openwall.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
kernel-hardening@lists.openwall.com,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Arnd Bergmann <arnd@arndb.de>,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC v2] implement SL*B and stack usercopy runtime checks
Date: Mon, 18 Jul 2011 14:08:22 -0500 [thread overview]
Message-ID: <1311016102.23043.235.camel@calx> (raw)
In-Reply-To: <20110718183951.GA3748@albatros>
On Mon, 2011-07-18 at 22:39 +0400, Vasiliy Kulikov wrote:
> This patch implements 2 additional checks for the data copied from
> kernelspace to userspace and vice versa (original PAX_USERCOPY from PaX
> patch). Currently there are some very simple and cheap comparisons of
> supplied size and the size of a copied object known at the compile time
> in copy_* functions. This patch enhances these checks to check against
> stack frame boundaries and against SL*B object sizes.
>
> More precisely, it checks:
>
> 1) if the data touches the stack, checks whether it fully fits in the stack
> and whether it fully fits in a single stack frame. The latter is arch
> dependent, currently it is implemented for x86 with CONFIG_FRAME_POINTER=y
> only. It limits infoleaks/overwrites to a single frame and local variables
> only, and prevents saved return instruction pointer overwriting.
>
> 2) if the data is from the SL*B cache, checks whether it fully fits in a
> slab page and whether it overflows a slab object. E.g. if the memory
> was allocated as kmalloc(64, GFP_KERNEL) and one tries to copy 150
> bytes, the copy would fail.
FYI, this should almost certainly be split into (at least) two patches:
- the stack check
- the SL*B check (probably one patch per allocator, preceded by one for
any shared infrastructure)
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Matt Mackall <mpm@selenic.com>
To: Vasiliy Kulikov <segoon@openwall.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
kernel-hardening@lists.openwall.com,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Arnd Bergmann <arnd@arndb.de>,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC v2] implement SL*B and stack usercopy runtime checks
Date: Mon, 18 Jul 2011 14:08:22 -0500 [thread overview]
Message-ID: <1311016102.23043.235.camel@calx> (raw)
Message-ID: <20110718190822.Fh4gKPix1dE2VlBsUMKkmyk_1uIYtALK5macTeCPjqU@z> (raw)
In-Reply-To: <20110718183951.GA3748@albatros>
On Mon, 2011-07-18 at 22:39 +0400, Vasiliy Kulikov wrote:
> This patch implements 2 additional checks for the data copied from
> kernelspace to userspace and vice versa (original PAX_USERCOPY from PaX
> patch). Currently there are some very simple and cheap comparisons of
> supplied size and the size of a copied object known at the compile time
> in copy_* functions. This patch enhances these checks to check against
> stack frame boundaries and against SL*B object sizes.
>
> More precisely, it checks:
>
> 1) if the data touches the stack, checks whether it fully fits in the stack
> and whether it fully fits in a single stack frame. The latter is arch
> dependent, currently it is implemented for x86 with CONFIG_FRAME_POINTER=y
> only. It limits infoleaks/overwrites to a single frame and local variables
> only, and prevents saved return instruction pointer overwriting.
>
> 2) if the data is from the SL*B cache, checks whether it fully fits in a
> slab page and whether it overflows a slab object. E.g. if the memory
> was allocated as kmalloc(64, GFP_KERNEL) and one tries to copy 150
> bytes, the copy would fail.
FYI, this should almost certainly be split into (at least) two patches:
- the stack check
- the SL*B check (probably one patch per allocator, preceded by one for
any shared infrastructure)
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2011-07-18 19:08 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-03 11:10 [kernel-hardening] [RFC v1] implement SL*B and stack usercopy runtime checks Vasiliy Kulikov
2011-07-03 11:10 ` Vasiliy Kulikov
2011-07-03 11:10 ` Vasiliy Kulikov
2011-07-03 18:27 ` [kernel-hardening] " Linus Torvalds
2011-07-03 18:27 ` Linus Torvalds
2011-07-03 18:27 ` Linus Torvalds
2011-07-03 18:57 ` [kernel-hardening] " Vasiliy Kulikov
2011-07-03 18:57 ` Vasiliy Kulikov
2011-07-03 18:57 ` Vasiliy Kulikov
2011-07-03 19:10 ` [kernel-hardening] " Linus Torvalds
2011-07-03 19:10 ` Linus Torvalds
2011-07-03 19:10 ` Linus Torvalds
2011-07-03 19:24 ` [kernel-hardening] " Vasiliy Kulikov
2011-07-03 19:24 ` Vasiliy Kulikov
2011-07-03 19:37 ` Joe Perches
2011-07-03 19:37 ` Joe Perches
2011-07-03 19:53 ` Vasiliy Kulikov
2011-07-03 19:53 ` Vasiliy Kulikov
2011-07-06 3:39 ` Jonathan Hawthorne
2011-07-06 3:39 ` Jonathan Hawthorne
2011-07-18 18:39 ` [kernel-hardening] [RFC v2] " Vasiliy Kulikov
2011-07-18 18:39 ` Vasiliy Kulikov
2011-07-18 18:39 ` Vasiliy Kulikov
2011-07-18 18:52 ` [kernel-hardening] " Andrew Morton
2011-07-18 18:52 ` Andrew Morton
2011-07-18 18:52 ` Andrew Morton
2011-07-18 19:33 ` [kernel-hardening] " Vasiliy Kulikov
2011-07-18 19:33 ` Vasiliy Kulikov
2011-07-19 7:40 ` Vasiliy Kulikov
2011-07-19 7:40 ` Vasiliy Kulikov
2011-07-18 19:08 ` Matt Mackall [this message]
2011-07-18 19:08 ` Matt Mackall
2011-07-18 19:08 ` Matt Mackall
2011-07-18 19:24 ` [kernel-hardening] " Vasiliy Kulikov
2011-07-18 19:24 ` Vasiliy Kulikov
2011-07-18 19:24 ` Vasiliy Kulikov
2011-07-18 21:18 ` [kernel-hardening] " Christoph Lameter
2011-07-18 21:18 ` Christoph Lameter
2011-07-18 21:18 ` Christoph Lameter
2011-07-19 6:53 ` [kernel-hardening] " Vasiliy Kulikov
2011-07-19 6:53 ` Vasiliy Kulikov
2011-07-19 6:53 ` Vasiliy Kulikov
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=1311016102.23043.235.camel@calx \
--to=mpm@selenic.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=cl@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=penberg@kernel.org \
--cc=segoon@openwall.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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 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.