From: Tim Chen <[email protected]>
"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 <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
---
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_EMU 6 /* syscall emulation active */
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP 8 /* secure computing */
On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds
<[email protected]> 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
On Wed, Nov 21, 2018 at 12:18 PM Thomas Gleixner <[email protected]> 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
On Wed, 21 Nov 2018, Linus Torvalds wrote:
> On Wed, Nov 21, 2018 at 12:18 PM Thomas Gleixner <[email protected]> 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
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.
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
> > <[email protected]> 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
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
On Wed, 21 Nov 2018, Linus Torvalds wrote:
> On Wed, Nov 21, 2018 at 12:28 PM Linus Torvalds
> <[email protected]> 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
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
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.
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.
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.
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
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.
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