Re: [PATCH v2] x86/hvm: Disallow CR0.PG 1->0 transitions when CS.L=1

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 17/04/2023 9:05 am, Jan Beulich wrote:
> 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 ...

Outside of 64bit mode, all address generation is truncated to 32 bits.

So when %rip happens to be above 2^32, the fetch of the next instruction
ought to be from a truncated %eip, but my attempts to set up such an
experiment still crashed.

I didn't spend too long investigating.  I've got too many other things
to do.

~Andrew