Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Thu, 22 Nov 2018, Borislav Petkov wrote: > On Thu, Nov 22, 2018 at 11:30:04AM -0600, Josh Poimboeuf wrote: > > But it does describe its purpose, especially in relation to the > > 'spectre_v2=' option. > > Sure, but the thing I'm proposing > > spectre_v2_task_isol= > > describes it more precisely, IMHO. :) > > I.e., "enable/disable spectre v2 task isolation". > > > Previously 'spectre_v2=' might have been more appropriately named > > 'spectre_v2_kernel=' because it only protected the kernel from Spectre > > v2 attacks. Now with these new patches, 'spectre_v2=on' will protect > > the entire system. > > Hmmm, crazy idea: can we extend the options of spectre_v2= nstead? > > spectre_v2=user_isolation,... > spectre_v2=kernel,... > spectre_v2=task_isolation,... > > and so on? > > This way we can do a couple of option switches in one go. That's results in a huge parser state space and changes the existing interface. We stay with the separate option. Thanks, tglx
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Thu, 22 Nov 2018, Borislav Petkov wrote: > On Thu, Nov 22, 2018 at 11:30:04AM -0600, Josh Poimboeuf wrote: > > But it does describe its purpose, especially in relation to the > > 'spectre_v2=' option. > > Sure, but the thing I'm proposing > > spectre_v2_task_isol= > > describes it more precisely, IMHO. :) > > I.e., "enable/disable spectre v2 task isolation". > > > Previously 'spectre_v2=' might have been more appropriately named > > 'spectre_v2_kernel=' because it only protected the kernel from Spectre > > v2 attacks. Now with these new patches, 'spectre_v2=on' will protect > > the entire system. > > Hmmm, crazy idea: can we extend the options of spectre_v2= nstead? > > spectre_v2=user_isolation,... > spectre_v2=kernel,... > spectre_v2=task_isolation,... > > and so on? > > This way we can do a couple of option switches in one go. That's results in a huge parser state space and changes the existing interface. We stay with the separate option. Thanks, tglx
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Thu, Nov 22, 2018 at 11:30:04AM -0600, Josh Poimboeuf wrote: > But it does describe its purpose, especially in relation to the > 'spectre_v2=' option. Sure, but the thing I'm proposing spectre_v2_task_isol= describes it more precisely, IMHO. :) I.e., "enable/disable spectre v2 task isolation". > Previously 'spectre_v2=' might have been more appropriately named > 'spectre_v2_kernel=' because it only protected the kernel from Spectre > v2 attacks. Now with these new patches, 'spectre_v2=on' will protect > the entire system. Hmmm, crazy idea: can we extend the options of spectre_v2= nstead? spectre_v2=user_isolation,... spectre_v2=kernel,... spectre_v2=task_isolation,... and so on? This way we can do a couple of option switches in one go. Hmmm? > Now off to eat a giant turkey. Try not to fall into a turkey coma. :-P -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Thu, Nov 22, 2018 at 11:30:04AM -0600, Josh Poimboeuf wrote: > But it does describe its purpose, especially in relation to the > 'spectre_v2=' option. Sure, but the thing I'm proposing spectre_v2_task_isol= describes it more precisely, IMHO. :) I.e., "enable/disable spectre v2 task isolation". > Previously 'spectre_v2=' might have been more appropriately named > 'spectre_v2_kernel=' because it only protected the kernel from Spectre > v2 attacks. Now with these new patches, 'spectre_v2=on' will protect > the entire system. Hmmm, crazy idea: can we extend the options of spectre_v2= nstead? spectre_v2=user_isolation,... spectre_v2=kernel,... spectre_v2=task_isolation,... and so on? This way we can do a couple of option switches in one go. Hmmm? > Now off to eat a giant turkey. Try not to fall into a turkey coma. :-P -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Thu, Nov 22, 2018 at 12:08:54AM +0100, Borislav Petkov wrote: > On Wed, Nov 21, 2018 at 05:04:50PM -0600, Josh Poimboeuf wrote: > > Why not just 'user'? Like SPECTRE_V2_USER_*. > > Sure, a bit better except that it doesn't explain what it does, I'd say. But it does describe its purpose, especially in relation to the 'spectre_v2=' option. Previously 'spectre_v2=' might have been more appropriately named 'spectre_v2_kernel=' because it only protected the kernel from Spectre v2 attacks. Now with these new patches, 'spectre_v2=on' will protect the entire system. Whereas 'spectre_v2_user=' is a subset of that; it helps protect user space from itself. Appending "user" to the existing 'spectre_v2=' option helps to communicate that, IMO. Now off to eat a giant turkey. -- Josh
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Thu, Nov 22, 2018 at 12:08:54AM +0100, Borislav Petkov wrote: > On Wed, Nov 21, 2018 at 05:04:50PM -0600, Josh Poimboeuf wrote: > > Why not just 'user'? Like SPECTRE_V2_USER_*. > > Sure, a bit better except that it doesn't explain what it does, I'd say. But it does describe its purpose, especially in relation to the 'spectre_v2=' option. Previously 'spectre_v2=' might have been more appropriately named 'spectre_v2_kernel=' because it only protected the kernel from Spectre v2 attacks. Now with these new patches, 'spectre_v2=on' will protect the entire system. Whereas 'spectre_v2_user=' is a subset of that; it helps protect user space from itself. Appending "user" to the existing 'spectre_v2=' option helps to communicate that, IMO. Now off to eat a giant turkey. -- Josh
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 05:04:50PM -0600, Josh Poimboeuf wrote: > Why not just 'user'? Like SPECTRE_V2_USER_*. Sure, a bit better except that it doesn't explain what it does, I'd say. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 05:04:50PM -0600, Josh Poimboeuf wrote: > Why not just 'user'? Like SPECTRE_V2_USER_*. Sure, a bit better except that it doesn't explain what it does, I'd say. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 11:56:46PM +0100, Borislav Petkov wrote: > On Wed, Nov 21, 2018 at 02:55:20PM -0800, Arjan van de Ven wrote: > > part of the problem is that "sharing" has multiple dimensions: time > > and space (e.g. hyperthreading) which makes it hard to find a nice > > term for it other than describing who attacks whom > > Shared Hardware Isolation of Tasks ? Ok, srsly: spectre_v2_task_isol= to mean, task isolation and it not being an abbreviation. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 11:56:46PM +0100, Borislav Petkov wrote: > On Wed, Nov 21, 2018 at 02:55:20PM -0800, Arjan van de Ven wrote: > > part of the problem is that "sharing" has multiple dimensions: time > > and space (e.g. hyperthreading) which makes it hard to find a nice > > term for it other than describing who attacks whom > > Shared Hardware Isolation of Tasks ? Ok, srsly: spectre_v2_task_isol= to mean, task isolation and it not being an abbreviation. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: > On Wed, 21 Nov 2018, Linus Torvalds wrote: > > > On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds > > wrote: > > > > > > Ugh. Now you're using the broken quilt thing that makes a mush of emails > > > for me. > > > > Reading the series in alpine makes it look fine. No testing, but each > > patch seems sensible. > > > > And yes, triggering on seccomp makes more sense than dumpable to me. > > That's what we ended up with SSBD as well. We had the same discussion before. > > Btw, I really do not like the app2app wording. I'd rather go for usr2usr, > but that's kinda horrible as well. But then, all of this is horrible. Why not just 'user'? Like SPECTRE_V2_USER_*. -- Josh
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: > On Wed, 21 Nov 2018, Linus Torvalds wrote: > > > On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds > > wrote: > > > > > > Ugh. Now you're using the broken quilt thing that makes a mush of emails > > > for me. > > > > Reading the series in alpine makes it look fine. No testing, but each > > patch seems sensible. > > > > And yes, triggering on seccomp makes more sense than dumpable to me. > > That's what we ended up with SSBD as well. We had the same discussion before. > > Btw, I really do not like the app2app wording. I'd rather go for usr2usr, > but that's kinda horrible as well. But then, all of this is horrible. Why not just 'user'? Like SPECTRE_V2_USER_*. -- Josh
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 02:55:20PM -0800, Arjan van de Ven wrote: > part of the problem is that "sharing" has multiple dimensions: time > and space (e.g. hyperthreading) which makes it hard to find a nice > term for it other than describing who attacks whom Shared Hardware Isolation of Tasks ? :-))) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 02:55:20PM -0800, Arjan van de Ven wrote: > part of the problem is that "sharing" has multiple dimensions: time > and space (e.g. hyperthreading) which makes it hard to find a nice > term for it other than describing who attacks whom Shared Hardware Isolation of Tasks ? :-))) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, 21 Nov 2018, Borislav Petkov wrote: > On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: > > Btw, I really do not like the app2app wording. I'd rather go for usr2usr, > > but that's kinda horrible as well. But then, all of this is horrible. > > > > Any better ideas? > > It needs to have "task isolation" in there somewhere as this is what it > does, practically. But it needs to be more precise as in "isolates the > tasks from influence due to shared hardware." :) Not only shared hardware. IBPB is about tasks running back to back on the same CPU. Thanks, tglx
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On 11/21/2018 2:53 PM, Borislav Petkov wrote: On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: Btw, I really do not like the app2app wording. I'd rather go for usr2usr, but that's kinda horrible as well. But then, all of this is horrible. Any better ideas? It needs to have "task isolation" in there somewhere as this is what it does, practically. But it needs to be more precise as in "isolates the tasks from influence due to shared hardware." :) part of the problem is that "sharing" has multiple dimensions: time and space (e.g. hyperthreading) which makes it hard to find a nice term for it other than describing who attacks whom
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, 21 Nov 2018, Borislav Petkov wrote: > On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: > > Btw, I really do not like the app2app wording. I'd rather go for usr2usr, > > but that's kinda horrible as well. But then, all of this is horrible. > > > > Any better ideas? > > It needs to have "task isolation" in there somewhere as this is what it > does, practically. But it needs to be more precise as in "isolates the > tasks from influence due to shared hardware." :) Not only shared hardware. IBPB is about tasks running back to back on the same CPU. Thanks, tglx
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On 11/21/2018 2:53 PM, Borislav Petkov wrote: On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: Btw, I really do not like the app2app wording. I'd rather go for usr2usr, but that's kinda horrible as well. But then, all of this is horrible. Any better ideas? It needs to have "task isolation" in there somewhere as this is what it does, practically. But it needs to be more precise as in "isolates the tasks from influence due to shared hardware." :) part of the problem is that "sharing" has multiple dimensions: time and space (e.g. hyperthreading) which makes it hard to find a nice term for it other than describing who attacks whom
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: > Btw, I really do not like the app2app wording. I'd rather go for usr2usr, > but that's kinda horrible as well. But then, all of this is horrible. > > Any better ideas? It needs to have "task isolation" in there somewhere as this is what it does, practically. But it needs to be more precise as in "isolates the tasks from influence due to shared hardware." :) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote: > Btw, I really do not like the app2app wording. I'd rather go for usr2usr, > but that's kinda horrible as well. But then, all of this is horrible. > > Any better ideas? It needs to have "task isolation" in there somewhere as this is what it does, practically. But it needs to be more precise as in "isolates the tasks from influence due to shared hardware." :) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, 21 Nov 2018, Linus Torvalds wrote: > On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds > wrote: > > > > Ugh. Now you're using the broken quilt thing that makes a mush of emails > > for me. > > Reading the series in alpine makes it look fine. No testing, but each > patch seems sensible. > > And yes, triggering on seccomp makes more sense than dumpable to me. That's what we ended up with SSBD as well. We had the same discussion before. Btw, I really do not like the app2app wording. I'd rather go for usr2usr, but that's kinda horrible as well. But then, all of this is horrible. Any better ideas? Thanks, tglx
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, 21 Nov 2018, Linus Torvalds wrote: > On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds > wrote: > > > > Ugh. Now you're using the broken quilt thing that makes a mush of emails > > for me. > > Reading the series in alpine makes it look fine. No testing, but each > patch seems sensible. > > And yes, triggering on seccomp makes more sense than dumpable to me. That's what we ended up with SSBD as well. We had the same discussion before. Btw, I really do not like the app2app wording. I'd rather go for usr2usr, but that's kinda horrible as well. But then, all of this is horrible. Any better ideas? Thanks, tglx
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds wrote: > > Ugh. Now you're using the broken quilt thing that makes a mush of emails for > me. Reading the series in alpine makes it look fine. No testing, but each patch seems sensible. And yes, triggering on seccomp makes more sense than dumpable to me. Linus
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds wrote: > > Ugh. Now you're using the broken quilt thing that makes a mush of emails for > me. Reading the series in alpine makes it look fine. No testing, but each patch seems sensible. And yes, triggering on seccomp makes more sense than dumpable to me. Linus
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, 21 Nov 2018, Linus Torvalds wrote: > On Wed, Nov 21, 2018 at 12:18 PM Thomas Gleixner wrote: > > > > From: Tim Chen "Reduced Data Speculation" is an obsolete term. > > Ugh. Now you're using the broken quilt thing that makes a mush of emails for > me. Gah. Dammit, I forgot to disable this file inline thingy. Sorry about that. /me goes and fixes Thanks, tglx
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, 21 Nov 2018, Linus Torvalds wrote: > On Wed, Nov 21, 2018 at 12:18 PM Thomas Gleixner wrote: > > > > From: Tim Chen "Reduced Data Speculation" is an obsolete term. > > Ugh. Now you're using the broken quilt thing that makes a mush of emails for > me. Gah. Dammit, I forgot to disable this file inline thingy. Sorry about that. /me goes and fixes Thanks, tglx
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 12:18 PM Thomas Gleixner wrote: > > From: Tim Chen "Reduced Data Speculation" is an obsolete term. Ugh. Now you're using the broken quilt thing that makes a mush of emails for me. Linus
Re: [patch 01/24] x86/speculation: Update the TIF_SSBD comment
On Wed, Nov 21, 2018 at 12:18 PM Thomas Gleixner wrote: > > From: Tim Chen "Reduced Data Speculation" is an obsolete term. Ugh. Now you're using the broken quilt thing that makes a mush of emails for me. Linus
[patch 01/24] x86/speculation: Update the TIF_SSBD comment
From: Tim Chen
"Reduced Data Speculation" is an obsolete term. The correct new name is
"Speculative store bypass disable" - which is abbreviated into SSBD.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/thread_info.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -79,7 +79,7 @@ struct thread_info {
#define TIF_SIGPENDING 2 /* signal pending */
#define TIF_NEED_RESCHED 3 /* rescheduling necessary */
#define TIF_SINGLESTEP 4 /* reenable singlestep on user return*/
-#define TIF_SSBD 5 /* Reduced data speculation */
+#define TIF_SSBD 5 /* Speculative store bypass disable */
#define TIF_SYSCALL_EMU6 /* syscall emulation active */
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
[patch 01/24] x86/speculation: Update the TIF_SSBD comment
From: Tim Chen
"Reduced Data Speculation" is an obsolete term. The correct new name is
"Speculative store bypass disable" - which is abbreviated into SSBD.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/thread_info.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -79,7 +79,7 @@ struct thread_info {
#define TIF_SIGPENDING 2 /* signal pending */
#define TIF_NEED_RESCHED 3 /* rescheduling necessary */
#define TIF_SINGLESTEP 4 /* reenable singlestep on user return*/
-#define TIF_SSBD 5 /* Reduced data speculation */
+#define TIF_SSBD 5 /* Speculative store bypass disable */
#define TIF_SYSCALL_EMU6 /* syscall emulation active */
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
