[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 62/65] x86/entry: Make IDT entrypoints CET-IBT compatible


  • To: Andrew Cooper <amc96@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 6 Dec 2021 10:42:38 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OIrDnTas8zwAPPDeyyTSIXpj1SlL3QBX2vGbydk8SGY=; b=D531wMv5ELd3+dB1yZv7vu6YYah6Oa6XAWaoZFTygxw4pLDscBzz0SBrZRKkfjL36FcQyzmJKp5ln2atiWM66bwIRrJdBJTdaFMvx1utm/hc06DeViBB5As4LrN2Uon9A9JlgpNMRrLhwIek43Tj2taFism95lFJxGolABJlpEeOHr0QJzErjyE0Npb7SvyIXKJC5KRTDzPipwjsSFZPXE0mVPbQSdVxUR+yrguef6zsN9DNSszqRcJdSFTTMEO19IzmKpYCtJl6v12uO89+y/Ev3JfjGAs6OofgS9qna5uXugHc3z2Ov9HB23f3XYJIWj8bTw72f3a32Wban8TNvw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LgmLJK/XSq6A9xO5arv/61CX8kQMEKM9NOlibOsv88l+lTHfRbd0u39rzGxGb7vrO/KPtpfJM9boL79ILGOd54oETqoe/JlPlK4zUytYGz7MBbA6V4U5mp17INQMEekMHqz6pOlTdAEodYo7JDZNT4q63Cqzt3gmRKLR7XrOJ8DuLBeXgVQEpc5ABMiwGe91cn5vIHZfiCcrtockIq1zlTvm59PMJbCH1X2GT43KE8OSn0NdmEmLfeQVocLxf02wAWxp/VT3ff79jMCQpY+C4U0Gf02Ht4t2klIARDWHNFcmbv+4AeYyrftSstrDtHsh5v0ejfzL/vz4g2q0rhGhoQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 06 Dec 2021 09:43:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.12.2021 16:30, Andrew Cooper wrote:
> On 03/12/2021 13:32, Jan Beulich wrote:
>> On 26.11.2021 13:34, Andrew Cooper wrote:
>>> Each IDT vector needs to land on an endbr64 instruction.  This is especially
>>> important for the #CP handler, which will escalate to #DF if the endbr64 is
>>> missing.
>> One question here: How does this work?
> 
> Honestly, I'm not sure.
> 
>>  I don't recall there being any "CET
>> shadow" along the lines of "STI shadow" and "SS shadow", yet there's
>> clearly an insn boundary here that gets "skipped" if the 2nd #CP gets
>> converted to #DF. And fetching of the first handler insn also isn't part
>> of exception delivery (and could cause other exceptions first, like #PF).
> 
> I can't make my observations of real hardware behaviour match the
> description in the spec.

I haven't been able to find a description at all of exception behavior
when the exception occurs in wait-for-endbr state. There is text saying
that #BP and #DB can occur this way, but I couldn't find anything about
the tracker state changes in such cases. While I could see the state to
remain engaged (requiring an ENDBR at the handler's entry point), I
cannot see how the state would get re-engaged upon IRET from the
exception handler, unless the return is back to CPL3.

> Given what a mess it all is, I wouldn't be surprised if the exception
> delivery microcode has a special case to escalate this to #DF.

I am meanwhile wondering whether any exception in wait-for-endbr state
at CPL < 3 would promote to #DF, for loss of state. Albeit there must
still be a distinction between CALL/JMP induced state and that
resulting from interrupt or exception delivery. Yet there's no
architectural (or shadow) state expressing "first insn of an exception
handler".

I'm not even convinced the aforementioned statements about #DB and #BP
are actually meant to cover more than just CPL3, or at best ENDBR at
normal CALL/JMP destinations.

While for Xen's own use we may get away without knowing how all of this
actually works (perhaps accepting the fact that one can't set breakpoints
at exception handler entry points, depending on whether their delivery
would promote to #DF), as soon as we were to support CET-IBT for guests
we'd definitely need to know.

Jan

> If it didn't escalate to #DF, then you'd end up with an infinite stream
> of #CP's, which will most likely cause a stack overflow because #CP
> needs to be not-IST for shadow stack reasons.
> 
> ~Andrew
> 




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.