linux-kernel - Re: [RFC PATCH V6 02/14] x86/sev: Add Check of #HV event in path

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]

Message-ID: <20230531154832.GA428966@hirez.programming.kicks-ass.net>
Date:   Wed, 31 May 2023 17:48:32 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
Cc:     Tianyu Lan <ltykernel@...il.com>,
        "luto@...nel.org" <luto@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "jgross@...e.com" <jgross@...e.com>,
        Tianyu Lan <Tianyu.Lan@...rosoft.com>,
        "kirill@...temov.name" <kirill@...temov.name>,
        "jiangshan.ljs@...group.com" <jiangshan.ljs@...group.com>,
        "ashish.kalra@....com" <ashish.kalra@....com>,
        "srutherford@...gle.com" <srutherford@...gle.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "anshuman.khandual@....com" <anshuman.khandual@....com>,
        "pawan.kumar.gupta@...ux.intel.com" 
        <pawan.kumar.gupta@...ux.intel.com>,
        "adrian.hunter@...el.com" <adrian.hunter@...el.com>,
        "daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
        "alexander.shishkin@...ux.intel.com" 
        <alexander.shishkin@...ux.intel.com>,
        "sandipan.das@....com" <sandipan.das@....com>,
        "ray.huang@....com" <ray.huang@....com>,
        "brijesh.singh@....com" <brijesh.singh@....com>,
        "michael.roth@....com" <michael.roth@....com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "venu.busireddy@...cle.com" <venu.busireddy@...cle.com>,
        "sterritt@...gle.com" <sterritt@...gle.com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "samitolvanen@...gle.com" <samitolvanen@...gle.com>,
        "fenghua.yu@...el.com" <fenghua.yu@...el.com>,
        "pangupta@....com" <pangupta@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: Re: [RFC PATCH V6 02/14] x86/sev: Add Check of #HV event in path

On Wed, May 31, 2023 at 02:50:50PM +0000, Michael Kelley (LINUX) wrote:

> I'm jumping in to answer some of the basic questions here.  Yesterday,
> there was a discussion about nested #HV exceptions, so maybe some of
> this is already understood, but let me recap at a higher level, provide some
> references, and suggest the path forward.

> 2) For the Restricted Interrupt Injection code, Tianyu will look at
> how to absolutely minimize the impact in the hot code paths,
> particularly when SEV-SNP is not active.  Hopefully the impact can
> be a couple of instructions at most, or even less with the use of
> other existing kernel techniques.  He'll look at the other things you've
> commented on and get the code into a better state.  I'll work with
> him on writing commit messages and comments that explain what's
> going on.

So from what I understand of all this SEV-SNP/#HV muck is that it is
near impossible to get right without ucode/hw changes. Hence my request
to Tom to look into that.

The feature as specified in the AMD documentation seems fundamentally
buggered.

Specifically #HV needs to be IST because hypervisor can inject at any
moment, irrespective of IF or anything else -- even #HV itself. This
means also in the syscall gap.

Since it is IST, a nested #HV is instant stack corruption -- #HV can
attempt to play stack games as per the copied #VC crap (which I'm not at
all convinced about being correct itself), but this doesn't actually fix
anything, all you need is a single instruction window to wreck things.

Because as stated, the whole premise is that the hypervisor is out to
get you, you must not leave it room to wiggle. As is, this is security
through prayer, and we don't do that.

In short; I really want a solid proof that what you propose to implement
is correct and not wishful thinking.