[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] x86/hvm: Disallow CR0.PG 1->0 transitions when CS.L=1
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 17 Apr 2023 10:05:49 +0200
- 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=o/X4BUZEw9PGWHmf8kbHNWsoPJEyrQ8Kr2jYHU5jiag=; b=MPEVJb/OkykpnF6Rb/O4uDDBDlMcVcWCjySH2whm+zPe6U1bFWCpx+j3/NC3I0+KG1BSsT8uJDMC621rlLj2mCRnFKMbxbkw4OPPbIAHeoGwqcIAKZAF/3CGEJrA7QS4fBG2L7UuP8uXF1S7R77sshBNFkq9qxDAHyh7kPFJ569bTaqrnmpZOmt+0MLcw8MJq6nR1Od8KDB/eduaL9Rg0cQF4CwqBqzCauB/mQKVeZUp1vp4IK2I/cd2hLkOwujV9HpJLQRep9QPNr5UP0MxKs+8QzM8NERJ2r85YM3h7SpCYnUCCZEWGHXjJEvkKezGdLCxW1NRu6m0bZGvkiAfJw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AEvsNM3CCIiOpxaes4zA9P3dGeExGNJv2llEGfU5Dpl+vHgPnYAj1lk43SSpK4CFkswvEGT1hk7Pv/rCclCVWIbm9yPqa0IMrqHeO73a+DksxOWjRvMLkRQusSB7iSTWCPuUCBTS1h/wDEUUqxNDb6t18ib0C1WSukcB0VXzdv6Emo+XmURByJ4BFQ1JC4RDWNm4wuZH1M+qerMEaoWriGtrNiAf6IbRYNMMzWl9KXcBjg2Sg00tj6Uws1zqfo5BSwKShA4w7vSKR0gX9+exTP4zfKgL/bLRIqOnmrljymSx1JT7+dTYP1G+kfw8YA/qZbJ4+xa/YrF1H7+th6VSfA==
- 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, 17 Apr 2023 08:06:42 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 13.04.2023 17:00, Andrew Cooper wrote:
> The Long Mode consistency checks exist to "ensure that the processor does not
> enter an undefined mode or state that results in unpredictable behavior". APM
> Vol2 Table 14-5 "Long-Mode Consistency Checks" lists them, but there is no row
> preventing the OS from trying to exit Long mode while in 64bit mode. This
> could leave the CPU in Protected Mode with an %rip above the 4G boundary.
>
> Experimentally, AMD CPUs really do permit this state transition. An OS which
> tries it hits an instant SHUTDOWN, even in cases where the truncation I expect
> to be going on behind the scenes ought to result in sane continued execution.
For my own understanding, which truncation are you referring to here?
As you're in 1:1 mapped code, %rip can't really be meant. Clearly IDT
and GDT would need to be (re)loaded to point to 32-bit-style tables, so
the only thing left would seem to be %rsp. It's not clear to me whether
after such an illegal mode switch its upper bits would be cleared or
ignored ...
Jan
|
