Project

General

Profile

Actions

Bug #9723

closed

provide support for VMM's GDT handling

Added by John Levon almost 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2018-08-10
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

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.

Actions

Also available in: Atom PDF