lkml.org 
[lkml]   [2018]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation
On Wed, 12 Sep 2018, Tim Chen wrote:

> I'm working on a patch for choosing the Spectre v2 app to app
> mitigation option.
>
> Something like the following:
>
> enum spectre_v2_app2app_mitigation {
> SPECTRE_V2_APP2APP_NONE,
> SPECTRE_V2_APP2APP_LITE,
> SPECTRE_V2_APP2APP_IBPB,
> SPECTRE_V2_APP2APP_STIBP,
> SPECTRE_V2_APP2APP_STRICT,
> };
>
> static const char *spectre_v2_app2app_strings[] = {
> [SPECTRE_V2_APP2APP_NONE] = "App-App Vulnerable",
> [SPECTRE_V2_APP2APP_LITE] = "App-App Mitigation: Protect only non-dumpable process",
> [SPECTRE_V2_APP2APP_IBPB] = "App-App Mitigation: Protect app against attack from same cpu",
> [SPECTRE_V2_APP2APP_STIBP] = "App-App Mitigation: Protect app against attack from sibling cpu",
> [SPECTRE_V2_APP2APP_STRICT] = "App-App Mitigation: Full app to app attack protection",
> };
>
> So the APP2APP_LITE protection's intention is to turn on STIBP and IBPB for non-dumpable
> process. But in my first version I may limit it to IBPB as choosing
> STIBP based on process characteristics will require some frobbing of
> the flags as what we've done in SSBD. That will require more careful
> work and tests.
>
> The STRICT option will turn STIBP on always and IBPB always on
> non-ptraceable context switches.
>
> Is this something reasonable?

It's probably 100% correct, but it's also 100% super-complex at the same
time if you ask me.

Try to imagine you're a very advanced senior sysadmin, who has heard that
spectre and meltdown existed of course, but figured out that updating to
latest kernel/distro vendor update fixes all the security issues (and it
actually indeed did).

Now, all of a sudden, this new option pops up, and the poor sysadmin has
to make a decision again.

"Do you care only about security across non-dumpable process
boundaries?"

"Scheduled to same CPU at the time of attack? Can you guarantee that this
is (not) happening?"

"If the processess can actually ptrace/debug each other, are you okay with
them attacking each other?"

"Shared HT siblings return target buffer, do you want it or
not?"

These are the questions that even an excellent sysadmin might not have
qualified answers to so far. Now, all of a sudden, he/her has to make
these decisions?

I don't think that's how it should work. It all should be digestible by
"linux end-users" (where users are also super-advanced sysadmins) easily.

We currently have "I do care about spectrev2 / I don't care about
spectrev2" boot-time switch, and I don't see us going any deeper / more
fine-grained without sacrificing clarity and sanity.

Or do you see a way how to do that nicely?

Thanks,

--
Jiri Kosina
SUSE Labs

\
 
 \ /
  Last update: 2018-09-12 23:46    [W:0.118 / U:8.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site