First post, by DosFreak
- Rank
- l33t++
https://www.phoronix.com/news/Intel-X86-S-64-bit-Only
https://www.intel.com/content/www/us/en/devel … chitecture.html
https://cdrdv2.intel.com/v1/dl/getContent/776648
https://www.vmware.com/content/dam/digitalmar … tualization.pdf
Supposedly this doesn't affect 32bit software running on a 64bit OS, haven't reviewed it yet.
It'll be interesting to see how this affects virtualization of 16 and 32bit operating systems since IIRC binary translation was removed from virtualbox (6.1.0+) and vmware (14+) (even though the processor still supported it) since they didn't want to support that and only wanted to support VT so with this new standard they would have to emulate these missing functions which is work they have already shown they aren't going to do so expect Virtualbox and Vmware to drop those operating systems when/if this processor is a thing.
QEMU TCG, DOSBox, pcem, bochs will work. Don't know about dosemu.
More work needs to be done for 32bit/64bit (non-UEFI) operating systems pass through (it's ridiculous how piss poor this is), emulation and wrapping of OGL/GDI/ddraw/D3D1-9 to the host on Linux/macOS and Windows that's for damn sure.
2020 – Intel firmware dropped support for running 16-bit/32-bit or non-UEFI operating systems natively.
X86-S ISA External Architectural Specification Document Number 351407-001, Revision 1.0 10 2 Introduction X86-S is a legacy-redu […]
X86-S ISA
External Architectural Specification
Document Number 351407-001, Revision 1.0 10
2 Introduction
X86-S is a legacy-reduced-OS ISA that removes outdated execution modes and operating system
ISA.
The presence of the X86-S ISA is enumerated by a single, main CPUID feature bit
LEGACY_REDUCED_OS_ISA in a future CPUID field. The bit implies all the ISA removals described
in this document. Some of the additional features, like 64bit SIPI or the 5 Level page table switch,
have separate CPUID feature flags and can be implemented independently of X86-S.
Changes in X86-S ISA consist of:
restricting the CPU to be always in paged mode
removing 32-bit ring 0, as well as vm86 mode.
removing ring 1 and ring 2
removing 16-bit real and protected modes
removing 16-bit addressing
removing fixed MTRRs
removing user-level I/O and string I/O
removing CR0 Write-Through mode
removing legacy FPU control bits in CR0
removing ring 3 interrupt flag control
removing obsolete CR access instruction
rearchitecting INIT/SIPI
adding a new mechanism to switch between 4- and 5-level page tables
removing XAPIC and only supporting x2APIC
removing APIC support for 8529
removing the disabling of NX or SYSCALL or long mode in the EFER MSR
removing the #SS and #NP exceptions
supporting a subset of segmentation architecture, with the following conditions:
o restricted to a subset of IDT event delivery
o base only for FS, GS
o base and limit for GDT, IDT, and TSS
o no limit on data or code fetches in 32-bit mode (similar to 64-bit)
o no AR or unusable selector checking on CS, DS, ES, FS, and GS on data or code
fetches in any mode
o restricted support for far call, far return, far jump, and IRET (like FRED).
A VMM can choose to emulate legacy functionality as required: 1. VMM changes required for mainstream Intel64 guest using legacy […]
A VMM can choose to emulate legacy functionality as required:
1. VMM changes required for mainstream Intel64 guest using legacy SIPI or non-64-bit boot
a. Emulate 16-bit modes (real mode, virtual 8086 mode)
b. Emulate unpaged modes
c. Emulate legacy INIT/SIPI
2. Optional VMM changes for handling uncommon cases
a. IOPL != 0 (if guest wants ring 3 I/O port access or ring 3 CLI/STI)
i. Catch CLI #GP in CPL3 and emulate
ii. Catch STI #GP in CPL3 and emulate
iii. Catch IN/OUT #GP in CPL3 and emulate
iv. IRET in CPL0 will #GP if attempting to change IOPL, catch and emulate
v. Note that that are un-virtualizable aspects of non-zero IOPL in the next
section.
b. INS/OUTS instructions are removed: Catch #UD and emulate
c. Call gates: VMM needs to catch relevant #GPs and emulate
d. #SS removal: VMM can catch relevant #GPs and report #SS back to guest
e. #NP removal: VMM can catch relevant #GPs and report #NP back to guest
f. CR4.PVI catch and emulate associated #GPs
g. Emulate 16-bit addressing by catching #GPs/#UDs
h. CR4.VME, RFLAGS.VM: Emulate v8086 mode
i. Emulate 32-bit ring 0 and run 32-bit ring 3 with shadow paging in legacy paging
modes
j. Support for unsupported obscure segmentation features like expand down or non
conforming code segments: Can be emulated by catching #GPs
3. Uncommon cases with expensive SW solutions:
a. CPL1/2 requires partial emulation
b. Non-flat CS/DS/ES/SS segments or setting access bits in descriptors in memory
requires full emulation trigged by Descriptor Table Exiting and then setting
GDT/LDT limit to zero (or read/write protect GDT/LDT) to catch segmentation
instructions
c. When EFER.NXE is cleared, a set NX bit in PTE requires shadow paging
d. Segmentation permission checking on load/store/execute: Would require full
emulation
4. Cases that are un-virtualizable
X86-S ISA
External Architectural Specification
Document Number 351407-001, Revision 1.0 28
a. RFLAGS.IOPL != 0: When IOPL is non-zero most cases where behavior would
typically change will instead #GP, which the VMM can catch/emulate (i.e., many
cases are virtualizable). The problematic Intel64 cases are as follows.
i. Ring 0 privileged SW sets IOPL to 3 and changes to ring 3. If ring 3 SW
runs PUSHF or SYSCALL, the value with IOPL=3 should go into the
memory or register destination. When this sequence runs in a VM, the ring
0 instruction that sets IOPL to 3 would cause #GP and trigger a VMExit. If
the VMM resumes the VM with the “wrong” IOPL, i.e., IOPL==0, the ring 3
PUSHF or SYSCALL would expose this incorrect IOPL through memory or
the register. Also, ring3 POPF will not update IF. The preferred scheme is
for VMM to emulate the guest till IOPL is changed back to 0. This case is
not expected on a modern OS.
ii. If the guest attempts to set IOPL to a value greater than zero using a
POPF instruction in ring 0, this will be silently ignored. The IOPL value will
not be updated and the VMM will be unaware that this occurred. Some
subsequent consumers of this value will #GP (e.g., CLI/STI/IN/OUT) but
others will silently continue with different semantics (e.g., IF updating
POPF, memory written by PUSHF, flags stored by SYSCALL, etc.)
b. #UD behavior on SYSCALL/SYSEXIT when EFER.SCE is cleared.