linux-kernel - Re: [PATCH v5 2/2] x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Sep 2018 23:45:54 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Tim Chen <tim.c.chen@...ux.intel.com>
cc:     Tom Lendacky <thomas.lendacky@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        "Schaufler, Casey" <casey.schaufler@...el.com>,
        linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [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