On Thu, Sep 03, 2020 at 08:56:13AM +0200, Christoph Hellwig wrote:
> On Wed, Sep 02, 2020 at 06:23:30PM +0100, Mark Rutland wrote:
> > I've pushed an initial/incomplete/WIP stab (just the kernel accessors)
> > to:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/
On Wed, Sep 02, 2020 at 06:23:30PM +0100, Mark Rutland wrote:
> I've pushed an initial/incomplete/WIP stab (just the kernel accessors)
> to:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/set_fs-removal
Thanks!
> ... and doing that made it clear that the necessar
On Wed, Sep 02, 2020 at 03:32:31PM +0200, Christoph Hellwig wrote:
> On Wed, Sep 02, 2020 at 12:43:48PM +0100, Mark Rutland wrote:
> > I'll see what I can do.
> >
> > At first glance it looks like we might need to flesh out or refactor the
> > arm64 kernel maccess routines first (since we want the
On Wed, Sep 02, 2020 at 12:43:48PM +0100, Mark Rutland wrote:
> I'll see what I can do.
>
> At first glance it looks like we might need to flesh out or refactor the
> arm64 kernel maccess routines first (since we want the user maccess
> routines to use LDTR/STTR instructions that can't access kern
On Tue, Sep 01, 2020 at 05:46:29PM +0200, Christoph Hellwig wrote:
> On Tue, Sep 01, 2020 at 05:05:53PM +0200, Christoph Hellwig wrote:
> > > Is there anything in particular that's tricky, or do you just want
> > > someone to look generally? From a quick grep arch/arm64/* looks clean, but
> > > I s
On Tue, Sep 01, 2020 at 03:00:44PM +, David Laight wrote:
> e user-space accesses.
> >
> > Well, yes, but that's a much bigger job which can be done later.
>
> Isn't this all rather difficult to exploit though?
> (Unlike the original Spectre which trivially let kernel
> memory be read.)
> Don
On Tue, Sep 01, 2020 at 05:05:53PM +0200, Christoph Hellwig wrote:
> > Is there anything in particular that's tricky, or do you just want
> > someone to look generally? From a quick grep arch/arm64/* looks clean, but
> > I suspect that's misleading.
>
> Yes, it should be mostly trivial. I just be
On Tue, Sep 01, 2020 at 03:54:42PM +0100, Mark Rutland wrote:
> On Tue, Sep 01, 2020 at 04:46:41PM +0200, Christoph Hellwig wrote:
> > On Tue, Sep 01, 2020 at 03:02:08PM +0100, Mark Rutland wrote:
> > > One thing to consider is whether you need a speculation barrier after
> > > set_fs(). Otherwise
From: Josh Poimboeuf
> Sent: 01 September 2020 15:27
>
> On Tue, Sep 01, 2020 at 08:32:20AM +, David Laight wrote:
> > > Yes, it would make sense to put the masking in access_ok() somehow. But
> > > to do it properly, I think we'd first need to make access_ok() generic.
> > > Maybe that's do-
On Tue, Sep 01, 2020 at 04:46:41PM +0200, Christoph Hellwig wrote:
> On Tue, Sep 01, 2020 at 03:02:08PM +0100, Mark Rutland wrote:
> > One thing to consider is whether you need a speculation barrier after
> > set_fs(). Otherwise for code like:
>
> FYI, at least for x86 and powerpc I have a pending
On Tue, Sep 01, 2020 at 09:21:58AM -0500, Josh Poimboeuf wrote:
> On Tue, Sep 01, 2020 at 03:02:08PM +0100, Mark Rutland wrote:
> > d instead do user pointer
> > > masking, throughout the x86 uaccess code. This is similar to what arm64
> > > is already doing.
> > >
> > > barrier_nospec() is now u
On Tue, Sep 01, 2020 at 03:02:08PM +0100, Mark Rutland wrote:
> One thing to consider is whether you need a speculation barrier after
> set_fs(). Otherwise for code like:
FYI, at least for x86 and powerpc I have a pending series to kill
set_fs(). I'd love to see someone help with the arm/arm64 si
On Tue, Sep 01, 2020 at 03:02:08PM +0100, Mark Rutland wrote:
> d instead do user pointer
> > masking, throughout the x86 uaccess code. This is similar to what arm64
> > is already doing.
> >
> > barrier_nospec() is now unused, and can be removed.
>
> One thing to consider is whether you need a
On Tue, Sep 01, 2020 at 08:32:20AM +, David Laight wrote:
> > Yes, it would make sense to put the masking in access_ok() somehow. But
> > to do it properly, I think we'd first need to make access_ok() generic.
> > Maybe that's do-able, but it would be a much bigger patch set.
> >
> > First I'
On Wed, Aug 19, 2020 at 09:50:06AM -0500, Josh Poimboeuf wrote:
> The x86 uaccess code uses barrier_nospec() in various places to prevent
> speculative dereferencing of user-controlled pointers (which might be
> combined with further gadgets or CPU bugs to leak data).
>
> There are some issues wit
From: Josh Poimboeuf
> Sent: 31 August 2020 18:31
> On Sat, Aug 29, 2020 at 07:31:20PM +, David Laight wrote:
> > > Rereading the patch it looks like a lot of bloat (as well as a
> > > lot of changes).
> > > Does the array_mask even work on 32bit archs where the kernel
> > > base address is 0xc
On Sat, Aug 29, 2020 at 07:31:20PM +, David Laight wrote:
> > Rereading the patch it looks like a lot of bloat (as well as a
> > lot of changes).
> > Does the array_mask even work on 32bit archs where the kernel
> > base address is 0xc000?
Why wouldn't it on work on 32-bit? My patch does
From: David Laight
> Sent: 29 August 2020 14:21
>
> From: Josh Poimboeuf
> > Sent: 28 August 2020 20:29
> >
> > On Wed, Aug 19, 2020 at 09:50:06AM -0500, Josh Poimboeuf wrote:
> > > The x86 uaccess code uses barrier_nospec() in various places to prevent
> > > speculative dereferencing of user-cont
From: Josh Poimboeuf
> Sent: 28 August 2020 20:29
>
> On Wed, Aug 19, 2020 at 09:50:06AM -0500, Josh Poimboeuf wrote:
> > The x86 uaccess code uses barrier_nospec() in various places to prevent
> > speculative dereferencing of user-controlled pointers (which might be
> > combined with further gadg
On Wed, Aug 19, 2020 at 09:50:06AM -0500, Josh Poimboeuf wrote:
> The x86 uaccess code uses barrier_nospec() in various places to prevent
> speculative dereferencing of user-controlled pointers (which might be
> combined with further gadgets or CPU bugs to leak data).
>
> There are some issues wit
On Wed, Aug 19, 2020 at 10:02 AM Josh Poimboeuf wrote:
>
> On Wed, Aug 19, 2020 at 09:39:10AM -0700, Andy Lutomirski wrote:
> > On Wed, Aug 19, 2020 at 7:50 AM Josh Poimboeuf wrote:
> > > +/*
> > > + * Sanitize a uaccess pointer such that it becomes NULL if it's not a
> > > valid
> > > + * user
From: Josh Poimboeuf
> Sent: 19 August 2020 18:02
>
> On Wed, Aug 19, 2020 at 09:39:10AM -0700, Andy Lutomirski wrote:
> > On Wed, Aug 19, 2020 at 7:50 AM Josh Poimboeuf wrote:
> > > +/*
> > > + * Sanitize a uaccess pointer such that it becomes NULL if it's not a
> > > valid
> > > + * user point
On Wed, Aug 19, 2020 at 09:39:10AM -0700, Andy Lutomirski wrote:
> On Wed, Aug 19, 2020 at 7:50 AM Josh Poimboeuf wrote:
> > +/*
> > + * Sanitize a uaccess pointer such that it becomes NULL if it's not a valid
> > + * user pointer. This blocks speculative dereferences of user-controlled
> > + * p
On Wed, Aug 19, 2020 at 7:50 AM Josh Poimboeuf wrote:
> +/*
> + * Sanitize a uaccess pointer such that it becomes NULL if it's not a valid
> + * user pointer. This blocks speculative dereferences of user-controlled
> + * pointers.
> + */
> +#define uaccess_mask_ptr(ptr) \
> + (__typeof__(pt
The x86 uaccess code uses barrier_nospec() in various places to prevent
speculative dereferencing of user-controlled pointers (which might be
combined with further gadgets or CPU bugs to leak data).
There are some issues with the current implementation:
- The barrier_nospec() in copy_from_user()
25 matches
Mail list logo
