[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Konrad Rzeszutek Wilk]

> This patch:
> * enables administrator to configure the mitigation off when desired
>   using either mitigations=off or srbds=off.
> * exports vulnerability status via sysfs

I think you also need a Documentation patch, that is a new file in
Documentation/x86/srbds.rst
and changes in 
Documentation/admin-guide/kernel-parameters.txt

to document the srbds=..

[MODERATED] Re: Re: [PATCH 2/2] more sampling fun 2

[Borislav Petkov]

On Mon, Feb 24, 2020 at 12:31:21PM -0500, speck for Konrad Rzeszutek Wilk wrote:
> > This patch:
> > * enables administrator to configure the mitigation off when desired
> >   using either mitigations=off or srbds=off.
> > * exports vulnerability status via sysfs
> 
> I think you also need a Documentation patch, that is a new file in
> Documentation/x86/srbds.rst
> and changes in 
> Documentation/admin-guide/kernel-parameters.txt
> 
> to document the srbds=..

That "srbds" string better be something more human-readable like

"srb_sampling="

or so.

Thx.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

[MODERATED] Re: Re: [PATCH 2/2] more sampling fun 2

[mark gross]

On Mon, Feb 24, 2020 at 07:17:34PM +0100, speck for Borislav Petkov wrote:
> On Mon, Feb 24, 2020 at 12:31:21PM -0500, speck for Konrad Rzeszutek Wilk wrote:
> > > This patch:
> > > * enables administrator to configure the mitigation off when desired
> > >   using either mitigations=off or srbds=off.
> > > * exports vulnerability status via sysfs
> > 
> > I think you also need a Documentation patch, that is a new file in
> > Documentation/x86/srbds.rst
> > and changes in 
> > Documentation/admin-guide/kernel-parameters.txt
> > 
> > to document the srbds=..
> 
> That "srbds" string better be something more human-readable like
> 
> "srb_sampling="

The implementation uses srbds_mitigation=..  (the commit comment now updated to
reflect this)

I've been holding on getting the finished white paper to be sure both documents
are are in sync.

--mark

> 
> or so.
> 
> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
> -- 

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Borislav Petkov]

On Mon, Feb 24, 2020 at 01:39:29PM -0800, speck for mark gross wrote:
> The implementation uses srbds_mitigation=..  (the commit comment now updated to
> reflect this)

Certainly not with "mitigation" in the name. All those switches control
mitigations so there's no need to tautologically have it in the name
too.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Josh Poimboeuf]

On Tue, Feb 25, 2020 at 12:10:34AM +0100, speck for Borislav Petkov wrote:
> On Mon, Feb 24, 2020 at 01:39:29PM -0800, speck for mark gross wrote:
> > The implementation uses srbds_mitigation=..  (the commit comment now updated to
> > reflect this)
> 
> Certainly not with "mitigation" in the name. All those switches control
> mitigations so there's no need to tautologically have it in the name
> too.

Why not just srbds= ?  That's what Intel calls it, and it would be
consistent with some of the other options like mds= and l1tf=.

-- 
Josh

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Borislav Petkov]

On Mon, Feb 24, 2020 at 07:26:41PM -0600, speck for Josh Poimboeuf wrote:
> Why not just srbds= ?  That's what Intel calls it, and it would be
> consistent with some of the other options like mds= and l1tf=.

For the same reason we did "spec_store_bypass_disable=" and not "ssbd=".
Although former is a bit longish for my taste, it doesn't make you go
look it up as "ssbd" does. And with "mds" and "l1tf" we dropped the ball
again. :-\

Over time, they would all become a letters jumble which we all would
have to go look up.

So I think at least *trying* to make them a bit more
understandable/parseable for humans, would be beneficial in the long
run.

So, for example, when I see "srb_sampling=off" at least I know, oh, ok,
it disables sampling of that SRB thing. "srbds" tells me exactly nothing
and the potential for flipping those letters' position is high.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Josh Poimboeuf]

On Tue, Feb 25, 2020 at 11:46:58AM +0100, speck for Borislav Petkov wrote:
> On Mon, Feb 24, 2020 at 07:26:41PM -0600, speck for Josh Poimboeuf wrote:
> > Why not just srbds= ?  That's what Intel calls it, and it would be
> > consistent with some of the other options like mds= and l1tf=.
> 
> For the same reason we did "spec_store_bypass_disable=" and not "ssbd=".
> Although former is a bit longish for my taste, it doesn't make you go
> look it up as "ssbd" does. And with "mds" and "l1tf" we dropped the ball
> again. :-\
> 
> Over time, they would all become a letters jumble which we all would
> have to go look up.
> 
> So I think at least *trying* to make them a bit more
> understandable/parseable for humans, would be beneficial in the long
> run.
> 
> So, for example, when I see "srb_sampling=off" at least I know, oh, ok,
> it disables sampling of that SRB thing. "srbds" tells me exactly nothing
> and the potential for flipping those letters' position is high.

Well, I see it the opposite way.  Those jumbles of letters do actually
mean something.  I still call them "MDS", "L1TF", "SSBD".  If you google
for "l1tf" or "mds vulnerability" they show up.  I'd expect to call this
one "SRBDS" a year from now.  I find "srb_sampling" to be confusing and
hard to remember because it renames something that already has an
industry standard name.

-- 
Josh

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Jiri Kosina]

On Tue, 25 Feb 2020, speck for Josh Poimboeuf wrote:

> Well, I see it the opposite way.  Those jumbles of letters do actually
> mean something.  I still call them "MDS", "L1TF", "SSBD".  If you google

BTW as a sidenote -- I think you actually nicely demonstrated all the 
confusion coming from all these crazy acronyms.

While MDS and L1TF are the names of the actual vulnerability, SSBD is 
acronym for the mitigation.

-- 
Jiri Kosina
SUSE Labs

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Josh Poimboeuf]

On Tue, Feb 25, 2020 at 03:23:31PM +0100, speck for Jiri Kosina wrote:
> On Tue, 25 Feb 2020, speck for Josh Poimboeuf wrote:
> 
> > Well, I see it the opposite way.  Those jumbles of letters do actually
> > mean something.  I still call them "MDS", "L1TF", "SSBD".  If you google
> 
> BTW as a sidenote -- I think you actually nicely demonstrated all the 
> confusion coming from all these crazy acronyms.
> 
> While MDS and L1TF are the names of the actual vulnerability, SSBD is 
> acronym for the mitigation.

Right - we should have just called it "ssb=", to match the Intel
acronym, instead of creating our own.

-- 
Josh

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Borislav Petkov]

On Tue, Feb 25, 2020 at 08:18:52AM -0600, speck for Josh Poimboeuf wrote:
> Well, I see it the opposite way.  Those jumbles of letters do actually
> mean something.  I still call them "MDS", "L1TF", "SSBD".  If you google
> for "l1tf" or "mds vulnerability" they show up.

If I gurgle "spec store bypass" it gets me straight to the wikipedia page:

"Speculative Store Bypass (SSB) (CVE-2018-3639) is the name... "

> I'd expect to call this one "SRBDS" a year from now. I find
> "srb_sampling" to be confusing and hard to remember because it renames
> something that already has an industry standard name.

srb_sampling *is* srbds - just more readable.

We are not giving any new names to the vulns - we're simply making our command
line options more readable so that when you have to type them, you either have
to remember "srbds" - in that order - or "srb sampling".

Latter is easier for me.

And yes, spec_store_bypass_disable= should've been
spec_store_bypass=<switches...>

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Josh Poimboeuf]

On Tue, Feb 25, 2020 at 03:59:06PM +0100, speck for Borislav Petkov wrote:
> > I'd expect to call this one "SRBDS" a year from now. I find
> > "srb_sampling" to be confusing and hard to remember because it renames
> > something that already has an industry standard name.
> 
> srb_sampling *is* srbds - just more readable.
> 
> We are not giving any new names to the vulns - we're simply making our command
> line options more readable so that when you have to type them, you either have
> to remember "srbds" - in that order - or "srb sampling".
> 
> Latter is easier for me.

But you're leaving out the "data" portion of the acronym/name.

Either call it "srbds" or "special_register_buffer_data_sampling" -- but
*please* don't give it a new name.  It will just create more confusion.

If you can't remember what srbds stands for, that's why we have
documentation and search engines.

-- 
Josh

Re: [PATCH 2/2] more sampling fun 2

[Thomas Gleixner]

speck for Josh Poimboeuf <speck@linutronix.de> writes:
> On Tue, Feb 25, 2020 at 03:59:06PM +0100, speck for Borislav Petkov wrote:
>> > I'd expect to call this one "SRBDS" a year from now. I find
>> > "srb_sampling" to be confusing and hard to remember because it renames
>> > something that already has an industry standard name.
>> 
>> srb_sampling *is* srbds - just more readable.
>> 
>> We are not giving any new names to the vulns - we're simply making our command
>> line options more readable so that when you have to type them, you either have
>> to remember "srbds" - in that order - or "srb sampling".
>> 
>> Latter is easier for me.
>
> But you're leaving out the "data" portion of the acronym/name.
>
> Either call it "srbds" or "special_register_buffer_data_sampling" -- but
> *please* don't give it a new name.  It will just create more confusion.
>
> If you can't remember what srbds stands for, that's why we have
> documentation and search engines.

Our command line options for this mess are inconsistent already, but for
most of them we have actual acronyms used, so lets just go with srbds.

Having a half correct, but more elaborate one does not really help. If
at all you want to come up with a snarky one like:

   super_random_but_data_stolen = [hell_no, shrug, nsa]

Thanks,

        tglx

[MODERATED] Re: [PATCH 2/2] more sampling fun 2

[Konrad Rzeszutek Wilk]

On Wed, Feb 26, 2020 at 10:16:46PM +0100, speck for Thomas Gleixner wrote:
> speck for Josh Poimboeuf <speck@linutronix.de> writes:
> > On Tue, Feb 25, 2020 at 03:59:06PM +0100, speck for Borislav Petkov wrote:
> >> > I'd expect to call this one "SRBDS" a year from now. I find
> >> > "srb_sampling" to be confusing and hard to remember because it renames
> >> > something that already has an industry standard name.
> >> 
> >> srb_sampling *is* srbds - just more readable.
> >> 
> >> We are not giving any new names to the vulns - we're simply making our command
> >> line options more readable so that when you have to type them, you either have
> >> to remember "srbds" - in that order - or "srb sampling".
> >> 
> >> Latter is easier for me.
> >
> > But you're leaving out the "data" portion of the acronym/name.
> >
> > Either call it "srbds" or "special_register_buffer_data_sampling" -- but
> > *please* don't give it a new name.  It will just create more confusion.
> >
> > If you can't remember what srbds stands for, that's why we have
> > documentation and search engines.
> 
> Our command line options for this mess are inconsistent already, but for
> most of them we have actual acronyms used, so lets just go with srbds.

Sounds like shruberryds.  I wonder if Google will autocorrect 'srbds' to
shrubbery or shrubs.
> 
> Having a half correct, but more elaborate one does not really help. If
> at all you want to come up with a snarky one like:
> 
>    super_random_but_data_stolen = [hell_no, shrug, nsa]

Nah,

the_knights_of_ni=?

:-)

How about

rng_secure=on,off

Since that is all folks will care about.

And 
mitigation=off will tweak it to off too.
> 
> Thanks,
> 
>         tglx
>