Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 6 Jun 2023 09:50:26 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     "Gupta, Pankaj" <pankaj.gupta@amd.com>
Cc:     Tom Lendacky <thomas.lendacky@amd.com>,
        Tianyu Lan <ltykernel@gmail.com>, luto@kernel.org,
        tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        seanjc@google.com, pbonzini@redhat.com, jgross@suse.com,
        tiala@microsoft.com, kirill@shutemov.name,
        jiangshan.ljs@antgroup.com, ashish.kalra@amd.com,
        srutherford@google.com, akpm@linux-foundation.org,
        anshuman.khandual@arm.com, pawan.kumar.gupta@linux.intel.com,
        adrian.hunter@intel.com, daniel.sneddon@linux.intel.com,
        alexander.shishkin@linux.intel.com, sandipan.das@amd.com,
        ray.huang@amd.com, brijesh.singh@amd.com, michael.roth@amd.com,
        venu.busireddy@oracle.com, sterritt@google.com,
        tony.luck@intel.com, samitolvanen@google.com, fenghua.yu@intel.com,
        pangupta@amd.com, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org, linux-hyperv@vger.kernel.org,
        linux-arch@vger.kernel.org
Subject: Re: [RFC PATCH V6 01/14] x86/sev: Add a #HV exception handler
Message-ID: <20230606075026.GA905437@hirez.programming.kicks-ass.net>
References: <20230515165917.1306922-1-ltykernel@gmail.com>
 <20230515165917.1306922-2-ltykernel@gmail.com>
 <20230516093010.GC2587705@hirez.programming.kicks-ass.net>
 <d43c14d9-a149-860c-71d6-e5c62b7c356f@amd.com>
 <20230530143504.GA200197@hirez.programming.kicks-ass.net>
 <0f0ab135-cdd0-0691-e0c1-42645671fe15@amd.com>
 <20230530185232.GA211927@hirez.programming.kicks-ass.net>
 <54fa0a4f-9b3e-50d7-57cb-e0d2d39b7761@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54fa0a4f-9b3e-50d7-57cb-e0d2d39b7761@amd.com>
Precedence: bulk

On Tue, Jun 06, 2023 at 08:00:32AM +0200, Gupta, Pankaj wrote:
> 
> > > That should really say that a nested #HV should never be raised by the
> > > hypervisor, but if it is, then the guest should detect that and
> > > self-terminate knowing that the hypervisor is possibly being malicious.
> > 
> > I've yet to see code that can do that reliably.
> 
> - Currently, we are detecting the direct nested #HV with below check and
>   guest self terminate.
> 
>   <snip>
> 	if (get_stack_info_noinstr(stack, current, &info) &&
> 	    (info.type == (STACK_TYPE_EXCEPTION + ESTACK_HV) ||
> 	     info.type == (STACK_TYPE_EXCEPTION + ESTACK_HV2)))
> 		panic("Nested #HV exception, HV IST corrupted, stack
>                 type = %d\n", info.type);
>   </snip>
> 
> - Thinking about below solution to detect the nested
>   #HV reliably:
> 
>   -- Make reliable IST stack switching for #VC -> #HV -> #VC case
>      (similar to done in __sev_es_ist_enter/__sev_es_ist_exit for NMI
>      IST stack).

I'm not convinced any of that is actually correct; there is a *huge*
window between NMI hitting and calling __sev_es_ist_enter(), idem on the
exit side.

>   -- In addition to this, we can make nested #HV detection (with another
>      exception type) more reliable with refcounting (percpu?).

There is also #DB and the MOVSS shadow.

And no, I don't think any of that is what you'd call 'robust'. This is
what I call a trainwreck :/

And I'm more than willing to say no until the hardware is more sane.

Supervisor Shadow Stack support is in the same boat, that's on hold
until FRED makes things workable.