provide support for VMM's GDT handling
As per SmartOS OS-7090:
"I ran a test program that attempted to deference a bunch of different segment selectors. Somewhat to my surprise, loading a selector of 0t4096 led to hitting "unexpected erratum 100" as per OS-6906.
It looks like the problem is due to running bhyve VMs. Let's read Intel vol 3 27.5.2, discussing VM exit behaviour:
The base addresses for GDTR and IDTR are loaded from the GDTR base-address field and the IDTR base-address field, respectively. If the processor supports the Intel 64 architecture and the processor supports N < 64 linear-address bits, each of bits 63:N of each base address is set to the value of bit N–1 of that base address. The GDTR and IDTR limits are each set to FFFFH.
And indeed, it looks like the GDT limit value is indeed 64Kb. So userspace will happily attempt to dereference past the end of the GDT page (in the debug_info as it happens). Due to KPTI, we'll fault as that page isn't mapped. Previously we could silently set the accessed bit, at least theoretically, which wouldn't be good.
We need to explicitly re-load the GDT on the way out of the VM."
This bug is for introducing the base OS support for this, as well as some related KMDB enhancements, and a test.
Updated by Electric Monk almost 4 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 309b04b88ca20521fb8141c40ad19b8528b37d7d Author: John Levon <firstname.lastname@example.org> Date: 2018-08-13T18:44:43.000Z 9723 provide support for VMM's GDT handling Reviewed by: Robert Mustacchi <email@example.com> Reviewed by: Patrick Mooney <firstname.lastname@example.org> Reviewed by: Yuri Pankov <email@example.com> Approved by: Dan McDonald <firstname.lastname@example.org>