On Wed, Sep 7, 2016 at 2:24 PM, Jiri Olsa wrote:
>
> I'll give this more testing, but it looks ok so far,
Looks fine to me.
I'd perhaps suggest using a simpler interface than
"__get_free_pages(GFP_KERNEL, 0);".
If nothing else, just drop the "order" argument and use
"__get_free_page()", but may
On Wed, Sep 07, 2016 at 09:25:59PM +0200, Jiri Olsa wrote:
> On Wed, Sep 07, 2016 at 09:58:01AM -0700, Linus Torvalds wrote:
> > On Wed, Sep 7, 2016 at 9:38 AM, Andi Kleen wrote:
> > >>
> > >> - n = copy_to_user(buffer, (char *)start,
> > >> tsz);
> > >> +
On Wed, Sep 07, 2016 at 09:58:01AM -0700, Linus Torvalds wrote:
> On Wed, Sep 7, 2016 at 9:38 AM, Andi Kleen wrote:
> >>
> >> - n = copy_to_user(buffer, (char *)start, tsz);
> >> + buf = kzalloc(tsz, GFP_KERNEL);
> >
> > You have to add some
On Wed, Sep 7, 2016 at 10:17 AM, Kees Cook wrote:
>
> !DEVKMEM is easy to represent, but STRICT_DEVMEM=y gets a little ugly,
I think you can just do
config STRICT_DEVMEM
bool "Filter access to /dev/mem" if !HARDENED_USERCOPY
depends on MMU
depends on ARCH_HAS_DEVMEM_IS
On Tue, Sep 6, 2016 at 12:48 PM, Linus Torvalds
wrote:
> On Tue, Sep 6, 2016 at 12:41 PM, Andi Kleen wrote:
>>
>> I suspect it's more than just /proc/kcore, there could be also
>> legitimate cases to read kernel text from /dev/mem or /dev/kmem
>
> Yes, that's probably true. Although I suspect tha
On Wed, Sep 7, 2016 at 9:38 AM, Andi Kleen wrote:
>>
>> - n = copy_to_user(buffer, (char *)start, tsz);
>> + buf = kzalloc(tsz, GFP_KERNEL);
>
> You have to add some limit and a loop, otherwise a user can eat all kernel
> memory,
> or copies
> ---
> diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
> index a939f5ed7f89..de07c273f725 100644
> --- a/fs/proc/kcore.c
> +++ b/fs/proc/kcore.c
> @@ -515,8 +515,20 @@ read_kcore(struct file *file, char __user *buffer,
> size_t buflen, loff_t *fpos)
> } else {
>
On Tue, Sep 06, 2016 at 01:56:40PM -0400, Kees Cook wrote:
SNIP
> > static __must_check __always_inline int
> > diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
> > index a939f5ed7f89..c7a22a8a157e 100644
> > --- a/fs/proc/kcore.c
> > +++ b/fs/proc/kcore.c
> > @@ -516,7 +516,7 @@ read_kcore(struct
On Tue, Sep 6, 2016 at 12:41 PM, Andi Kleen wrote:
>
> I suspect it's more than just /proc/kcore, there could be also
> legitimate cases to read kernel text from /dev/mem or /dev/kmem
Yes, that's probably true. Although I suspect that we should just say
that user-copy hardening is incompatible wi
On Tue, Sep 06, 2016 at 11:34:28AM -0700, Linus Torvalds wrote:
> On Tue, Sep 6, 2016 at 10:56 AM, Kees Cook wrote:
> >
> > In the meantime, how about continuing to use a bounce buffer like
> > already done in the vmalloc_or_module_addr() case immediately above?
>
> Yes please. Let's not make up
On Tue, Sep 6, 2016 at 10:56 AM, Kees Cook wrote:
>
> In the meantime, how about continuing to use a bounce buffer like
> already done in the vmalloc_or_module_addr() case immediately above?
Yes please. Let's not make up even more of the user access functions
with magical properties, for some spe
On Mon, Sep 5, 2016 at 4:47 AM, Jiri Olsa wrote:
> On Fri, Sep 02, 2016 at 08:17:13AM -0700, Andi Kleen wrote:
>> On Fri, Sep 02, 2016 at 02:25:45PM +0200, Jiri Olsa wrote:
>> > One of the bullets for hardened usercopy feature is:
>> > - object must not overlap with kernel text
>> >
>> > which i
On Mon, Sep 05, 2016 at 10:47:22AM +0200, Jiri Olsa wrote:
> On Fri, Sep 02, 2016 at 08:17:13AM -0700, Andi Kleen wrote:
> > On Fri, Sep 02, 2016 at 02:25:45PM +0200, Jiri Olsa wrote:
> > > One of the bullets for hardened usercopy feature is:
> > > - object must not overlap with kernel text
> > >
On Fri, Sep 02, 2016 at 08:17:13AM -0700, Andi Kleen wrote:
> On Fri, Sep 02, 2016 at 02:25:45PM +0200, Jiri Olsa wrote:
> > One of the bullets for hardened usercopy feature is:
> > - object must not overlap with kernel text
> >
> > which is what we expose via /proc/kcore. We can hit
> > this ch
On Fri, Sep 02, 2016 at 08:17:13AM -0700, Andi Kleen wrote:
> On Fri, Sep 02, 2016 at 02:25:45PM +0200, Jiri Olsa wrote:
> > One of the bullets for hardened usercopy feature is:
> > - object must not overlap with kernel text
> >
> > which is what we expose via /proc/kcore. We can hit
> > this ch
On Fri, Sep 02, 2016 at 02:25:45PM +0200, Jiri Olsa wrote:
> One of the bullets for hardened usercopy feature is:
> - object must not overlap with kernel text
>
> which is what we expose via /proc/kcore. We can hit
> this check and crash the system very easily just by
> reading the text area in
One of the bullets for hardened usercopy feature is:
- object must not overlap with kernel text
which is what we expose via /proc/kcore. We can hit
this check and crash the system very easily just by
reading the text area in kcore file:
usercopy: kernel memory exposure attempt detected from f
17 matches
Mail list logo
