Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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.

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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:

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

* 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 >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

* 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

RE: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

RE: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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 > >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

RE: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

RE: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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,

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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,

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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: > > > >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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 > >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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. > >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> 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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> 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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> > 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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> > 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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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,

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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(). >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> 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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> 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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> "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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> "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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> 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.

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

> 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.

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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. > > > > > >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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.

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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.

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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 >

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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. >

  1   2   >