On Tue, Jan 9, 2018 at 2:23 PM, Josh Poimboeuf wrote:
> On Tue, Jan 09, 2018 at 01:59:04PM -0800, Dan Williams wrote:
>> > Right, but what's the purpose of preventing speculation past
>> > access_ok()?
>>
>> Caution. It's the same rationale for the nospec_array_ptr() patches.
>> If we, kernel comm
On Tue, Jan 09, 2018 at 01:59:04PM -0800, Dan Williams wrote:
> > Right, but what's the purpose of preventing speculation past
> > access_ok()?
>
> Caution. It's the same rationale for the nospec_array_ptr() patches.
> If we, kernel community, can identify any possible speculation past a
> bounds
On Tue, Jan 9, 2018 at 1:49 PM, Josh Poimboeuf wrote:
> On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote:
>> On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote:
>> > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote:
>> >> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams
On Tue, Jan 09, 2018 at 01:47:09PM -0800, Dan Williams wrote:
> On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote:
> > On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote:
> >> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams
> >> wrote:
> >> > From: Andi Kleen
> >> >
> >> > When acce
On Tue, Jan 9, 2018 at 1:41 PM, Josh Poimboeuf wrote:
> On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote:
>> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams
>> wrote:
>> > From: Andi Kleen
>> >
>> > When access_ok fails we should always stop speculating.
>> > Add the required barrier
On Fri, Jan 05, 2018 at 06:52:07PM -0800, Linus Torvalds wrote:
> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote:
> > From: Andi Kleen
> >
> > When access_ok fails we should always stop speculating.
> > Add the required barriers to the x86 access_ok macro.
>
> Honestly, this seems completely
On Mon, Jan 8, 2018 at 3:53 PM, Dan Williams wrote:
>
> I've been thinking the "and" is only suitable for the array bounds
> check, for get_user() we're trying to block speculation past
> access_ok() at which point we can only do the lfence?
Well, we *could* do the "and", at least for the simple
On Mon, Jan 8, 2018 at 3:44 PM, Linus Torvalds
wrote:
> On Mon, Jan 8, 2018 at 1:09 PM, Dan Williams wrote:
>> On Sat, Jan 6, 2018 at 5:20 PM, Linus Torvalds
>> wrote:
>>> On Sat, Jan 6, 2018 at 3:31 PM, Dan Williams
>>> wrote:
I assume if we put this in uaccess_begin() we also need
On Mon, Jan 8, 2018 at 1:09 PM, Dan Williams wrote:
> On Sat, Jan 6, 2018 at 5:20 PM, Linus Torvalds
> wrote:
>> On Sat, Jan 6, 2018 at 3:31 PM, Dan Williams
>> wrote:
>>>
>>> I assume if we put this in uaccess_begin() we also need audit for
>>> paths that use access_ok but don't do on to call
On Sat, Jan 6, 2018 at 5:20 PM, Linus Torvalds
wrote:
> On Sat, Jan 6, 2018 at 3:31 PM, Dan Williams wrote:
>>
>> I assume if we put this in uaccess_begin() we also need audit for
>> paths that use access_ok but don't do on to call uaccess_begin()? A
>> quick glance shows a few places where we ar
* Peter Zijlstra wrote:
> On Sun, Jan 07, 2018 at 06:24:11PM -0800, Alexei Starovoitov wrote:
> > How about:
> > CONFIG_SPECTRE1_WORKAROUND_INDEX_MASK
> > CONFIG_SPECTRE1_WORKAROUND_LOAD_FENCE
>
> INSTRUCTION_FENCE if anything. LFENCE for Intel (and now also for AMD as
> per 0592b0bce169) is a
From: Alan Cox
> Sent: 08 January 2018 12:13
...
> > Try over 35% slowdown
> > Given that AWS instance runs known code (user and kernel) why do we
> > need to worry about any of these sideband attacks?
>
> You may not need to. Amazon themselves obviously need to worry that no
> other VM steals
On Mon, 8 Jan 2018 12:00:28 +
David Laight wrote:
> From: Linus Torvalds
> > Sent: 07 January 2018 19:47
> ...
> > Also, people definitely *are* noticing the performance issues with the
> > current set of patches, and they are causing real problems. Go search
> > for reports of Amazon AWS s
From: Linus Torvalds
> Sent: 07 January 2018 19:47
...
> Also, people definitely *are* noticing the performance issues with the
> current set of patches, and they are causing real problems. Go search
> for reports of Amazon AWS slowdowns.
Try over 35% slowdown
Given that AWS instance runs know
On Sat, Jan 06, 2018 at 08:41:34PM +0100, Thomas Gleixner wrote:
> optimized argumentation. We need to make sure that we have a solution which
> kills the problem safely and then take it from there. Correctness first,
> optimization later is the rule for this. Better safe than sorry.
Agreed, assum
On Sun, Jan 07, 2018 at 06:57:35PM -0800, Alexei Starovoitov wrote:
> On Sun, Jan 07, 2018 at 01:59:35PM +, Alan Cox wrote:
> > lfence timing is also heavily dependent upon what work has to be done to
> > retire previous live instructions.
> > BPF does not normally do a lot of writing so you'
On Sun, Jan 07, 2018 at 06:24:11PM -0800, Alexei Starovoitov wrote:
> How about:
> CONFIG_SPECTRE1_WORKAROUND_INDEX_MASK
> CONFIG_SPECTRE1_WORKAROUND_LOAD_FENCE
INSTRUCTION_FENCE if anything. LFENCE for Intel (and now also for AMD as
per 0592b0bce169) is a misnomer, IFENCE would be a better name f
On Sun, Jan 07, 2018 at 09:23:47PM -0500, David Miller wrote:
> From: Thomas Gleixner
> Date: Sun, 7 Jan 2018 21:56:39 +0100 (CET)
>
> > I surely agree, but we have gone the way of PTI without the ability of
> > exempting individual processes exactly for one reason:
> >
> > Lack of time
> >
>
On Sun, Jan 07, 2018 at 01:59:35PM +, Alan Cox wrote:
> > which means that POC is relying 64-bit address speculation.
> > In the places coverity found the user supplied value is 32-bit,
>
> People have 32bit computers as well as 64bit and in some cases 32bit is
> fine for an attack depending w
On Sun, Jan 07, 2018 at 12:15:40PM -0800, Dan Williams wrote:
>
> I'm thinking we should provide the option to at least build the
> hot-path nospec_array_ptr() usages without an lfence.
>
> CONFIG_SPECTRE1_PARANOIA_SAFE
> CONFIG_SPECTRE1_PARANOIA_PERF
SAFE vs PERF naming is problematic a
From: Thomas Gleixner
Date: Sun, 7 Jan 2018 21:56:39 +0100 (CET)
> I surely agree, but we have gone the way of PTI without the ability of
> exempting individual processes exactly for one reason:
>
> Lack of time
>
> It can be done on top of the PTI implementation and it won't take ages.
>
>
On Sun, Jan 07, 2018 at 11:08:24AM +0100, Thomas Gleixner wrote:
> On Sat, 6 Jan 2018, Alexei Starovoitov wrote:
> > which clearly states that bpf_tail_call() was used in the attack.
> > Yet none of the intel nor arm patches address speculation in
> > this bpf helper!
> > It means that:
> > - gpz d
From: Thomas Gleixner
Date: Sun, 7 Jan 2018 19:31:41 +0100 (CET)
> 2) Alexei's analyis is purely based on the public information of the google
>zero folks. If it would be complete and the only attack vector all fine.
>
>If not and I doubt it is, we're going to regret this decision faster
On Sun, Jan 07, 2018 at 12:17:11PM -0800, Linus Torvalds wrote:
> We need to fix the security problem, but we need to do it *without*
> these braindead arguments that performance is somehow secondary.
OK OK. At least we should have security by default and let people trade
it against performance if
On Sun, 7 Jan 2018, Linus Torvalds wrote:
> We need to fix the security problem, but we need to do it *without*
> these braindead arguments that performance is somehow secondary.
I surely agree, but we have gone the way of PTI without the ability of
exempting individual processes exactly for one r
On Sun, Jan 7, 2018 at 12:12 PM, Willy Tarreau wrote:
>
> Linus, no need to explain that to me, I'm precisely trying to see how
> to disable PTI for a specific process because I face up to 45% loss in
> certain circumstances, making it a no-go. But while a few of us have
> very specific workloads
On Sun, Jan 7, 2018 at 11:47 AM, Linus Torvalds
wrote:
> On Sat, Jan 6, 2018 at 10:33 PM, Willy Tarreau wrote:
>>
>> To be fair there's overreaction on both sides. The vast majority of
>> users need to get a 100% safe system and will never notice any
>> difference.
>
> There is no such thing as
On Sun, Jan 07, 2018 at 11:47:07AM -0800, Linus Torvalds wrote:
> And the whole "normal people won't even notice" is pure garbage too.
> Don't spread that bullshit when you see actual normal people
> complaining.
>
> Performance matters. A *LOT*.
Linus, no need to explain that to me, I'm precisel
On Sat, Jan 6, 2018 at 10:33 PM, Willy Tarreau wrote:
>
> To be fair there's overreaction on both sides. The vast majority of
> users need to get a 100% safe system and will never notice any
> difference.
There is no such thing as a "100% safe system". Never will be - unless
you make sure you ha
> everyone. I'm not saying this always happens, but it is reasonable to
> let the iterative pushback see if we can get to better code in this
> case rather than trying to cut it of with the "because *security*"
> argument.
>
I'm not arguing otherwise - I'd just prefer most users machines are
sec
On Sun, 7 Jan 2018, James Bottomley wrote:
> On Sat, 2018-01-06 at 20:36 -0500, David Miller wrote:
> > From: Willy Tarreau
> > Date: Sat, 6 Jan 2018 21:42:29 +0100
> >
> > > On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
> > >> Normally people who propose security fixes don't have to
On Sat, 2018-01-06 at 20:36 -0500, David Miller wrote:
> From: Willy Tarreau
> Date: Sat, 6 Jan 2018 21:42:29 +0100
>
> > On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
> >> Normally people who propose security fixes don't have to argue
> about the
> >> fact they added 30 clocks to avo
> > 2. It is very very complicated to answer a question like "is
> > sequence x safe on all of vendor's microprocessors" even for the vendor
>
> so far "is sequence x safe" was viewed by cpu vendors as
> "is sequence x going to stop speculative execution".
Incorrect. Modern processors are very
On Sat, 6 Jan 2018, Alexei Starovoitov wrote:
> which clearly states that bpf_tail_call() was used in the attack.
> Yet none of the intel nor arm patches address speculation in
> this bpf helper!
> It means that:
> - gpz didn't share neither exploit nor the detailed description
> of the POC with
On Sat, Jan 06, 2018 at 07:38:14PM -0800, Alexei Starovoitov wrote:
> yep. plenty of unknowns and what's happening now is an overreaction.
To be fair there's overreaction on both sides. The vast majority of
users need to get a 100% safe system and will never notice any
difference. A few of us are
On Sat, Jan 06, 2018 at 11:05:07PM +, Alan Cox wrote:
> > Even if it would be practical the speed probably going to be in bytes per
> > second,
> > so to read anything meaningful an attack detection techniques (that people
> > are actively working on) will be able to catch it.
> > At the end s
From: Willy Tarreau
Date: Sat, 6 Jan 2018 21:42:29 +0100
> On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
>> Normally people who propose security fixes don't have to argue about the
>> fact they added 30 clocks to avoid your box being 0wned.
>
> In fact it depends, because if a fix ma
On Sat, Jan 6, 2018 at 3:31 PM, Dan Williams wrote:
>
> I assume if we put this in uaccess_begin() we also need audit for
> paths that use access_ok but don't do on to call uaccess_begin()? A
> quick glance shows a few places where we are open coding the stac().
> Perhaps land the lfence in stac()
On Fri, Jan 5, 2018 at 7:09 PM, Linus Torvalds
wrote:
> On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds
> wrote:
>>
>> The fact is, we have to stop speculating when access_ok() does *not*
>> fail - because that's when we'll actually do the access. And it's that
>> access that needs to be non-specu
> Even if it would be practical the speed probably going to be in bytes per
> second,
> so to read anything meaningful an attack detection techniques (that people
> are actively working on) will be able to catch it.
> At the end security cannot be absolute.
> The current level of paranoia shouldn'
On Sat, 6 Jan 2018, Alexei Starovoitov wrote:
> So how about we do array_access() macro similar to above by default
> with extra CONFIG_ to convert it to lfence ?
> Why default to AND approach instead of lfence ?
> Because the kernel should still be usable. If security
> sacrifices performance so m
On Sat, Jan 06, 2018 at 08:22:13PM +, Alan Cox wrote:
> > "Value prediction consists of predicting entire 32- and 64-bit register
> > values
> > based on previously-seen values"
>
> For their implementation yes
>
> >
> > > In other words there are at least two problems with Linus proposal
On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
> Normally people who propose security fixes don't have to argue about the
> fact they added 30 clocks to avoid your box being 0wned.
In fact it depends, because if a fix makes the system unusable for its
initial purpose, this fix will simp
> "Value prediction consists of predicting entire 32- and 64-bit register values
> based on previously-seen values"
For their implementation yes
>
> > In other words there are at least two problems with Linus proposal
> >
> > 1. The / mask has to be generated and that has to involve
>
On Sat, Jan 06, 2018 at 07:55:51PM +, Alan Cox wrote:
> > cpus execute what they see. speculative execution does the same
> > except results are not committed to visible registers and stay
> > in renanmed/shadow set. There is no 'undo' of the speculative execution.
> > The whole issue is that c
> cpus execute what they see. speculative execution does the same
> except results are not committed to visible registers and stay
> in renanmed/shadow set. There is no 'undo' of the speculative execution.
> The whole issue is that cache and branch predictor don't have
> a shadow unlike registers.
On Sat, 6 Jan 2018, Alexei Starovoitov wrote:
> On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote:
> > On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
> > wrote:
> > [..]
> > >> retpoline is variant-2, this patch series is about variant-1.
> > >
> > > that's exactly the point. Don'
On Sat, Jan 6, 2018 at 11:25 AM, Alexei Starovoitov
wrote:
> On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote:
>> On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
>> wrote:
>> [..]
>> >> retpoline is variant-2, this patch series is about variant-1.
>> >
>> > that's exactly the poin
On Sat, Jan 06, 2018 at 10:54:27AM -0800, Dan Williams wrote:
> On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
> wrote:
> [..]
> >> retpoline is variant-2, this patch series is about variant-1.
> >
> > that's exactly the point. Don't slow down the kernel with lfences
> > to solve variant 1. r
On Sat, Jan 6, 2018 at 10:39 AM, Alexei Starovoitov
wrote:
[..]
>> retpoline is variant-2, this patch series is about variant-1.
>
> that's exactly the point. Don't slow down the kernel with lfences
> to solve variant 1. retpoline for 2 is ok from long term kernel
> viability perspective.
>
Setti
On Sat, Jan 06, 2018 at 06:38:59PM +, Alan Cox wrote:
> On Sat, 6 Jan 2018 10:13:33 -0800
> Alexei Starovoitov wrote:
>
> > On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote:
> > > On Fri, 5 Jan 2018 18:52:07 -0800
> > > Linus Torvalds wrote:
> > >
> > > > On Fri, Jan 5, 2018 at 5:
On Sat, Jan 06, 2018 at 10:29:49AM -0800, Dan Williams wrote:
> On Sat, Jan 6, 2018 at 10:13 AM, Alexei Starovoitov
> wrote:
> > On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote:
> >> On Fri, 5 Jan 2018 18:52:07 -0800
> >> Linus Torvalds wrote:
> >>
> >> > On Fri, Jan 5, 2018 at 5:10 PM,
On Sat, 6 Jan 2018 10:13:33 -0800
Alexei Starovoitov wrote:
> On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote:
> > On Fri, 5 Jan 2018 18:52:07 -0800
> > Linus Torvalds wrote:
> >
> > > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams
> > > wrote:
> > > > From: Andi Kleen
> > > >
> >
On Sat, Jan 6, 2018 at 10:13 AM, Alexei Starovoitov
wrote:
> On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote:
>> On Fri, 5 Jan 2018 18:52:07 -0800
>> Linus Torvalds wrote:
>>
>> > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams
>> > wrote:
>> > > From: Andi Kleen
>> > >
>> > > When acces
On Sat, Jan 06, 2018 at 12:32:42PM +, Alan Cox wrote:
> On Fri, 5 Jan 2018 18:52:07 -0800
> Linus Torvalds wrote:
>
> > On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams
> > wrote:
> > > From: Andi Kleen
> > >
> > > When access_ok fails we should always stop speculating.
> > > Add the required
On Sat, Jan 6, 2018 at 4:32 AM, Alan Cox wrote:
>
> Also for x86-64 if we are trusting that an AND with a constant won't get
> speculated into something else surely we can just and the address with ~(1
> << 63) before copying from/to user space ? The user will then just
> speculatively steal their
On Fri, 5 Jan 2018 18:52:07 -0800
Linus Torvalds wrote:
> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote:
> > From: Andi Kleen
> >
> > When access_ok fails we should always stop speculating.
> > Add the required barriers to the x86 access_ok macro.
>
> Honestly, this seems completely bog
On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds
wrote:
> On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote:
>> From: Andi Kleen
>>
>> When access_ok fails we should always stop speculating.
>> Add the required barriers to the x86 access_ok macro.
>
> Honestly, this seems completely bogus.
>
> Th
On Fri, Jan 5, 2018 at 6:52 PM, Linus Torvalds
wrote:
>
> The fact is, we have to stop speculating when access_ok() does *not*
> fail - because that's when we'll actually do the access. And it's that
> access that needs to be non-speculative.
I also suspect we should probably do this entirely dif
On Fri, Jan 5, 2018 at 5:10 PM, Dan Williams wrote:
> From: Andi Kleen
>
> When access_ok fails we should always stop speculating.
> Add the required barriers to the x86 access_ok macro.
Honestly, this seems completely bogus.
The description is pure garbage afaik.
The fact is, we have to stop
From: Andi Kleen
When access_ok fails we should always stop speculating.
Add the required barriers to the x86 access_ok macro.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Arnd Bergmann
Cc: x...@kernel.org
Signed-off-by: Andi Kleen
Signed-off-by: Dan Williams
---
arch/x86/
61 matches
Mail list logo
