4 ms·

The article (and its predecessor) makes a big deal out of "they turned BIOS into a hypervisor!!1!". What exactly does the author think a hypervisor is, other th

The article (and its predecessor) makes a big deal out of "they turned BIOS into a hypervisor!!1!". What exactly does the author think a hypervisor is, other than code running at a heightened privilege level that interposes the running OS's communication with the hardware. Most of what's happening here is pretty standard that's-how-a-minimal-hypervisor-works. The Outlook-data-migration part is interestingly janky, but not technically complex.

danparsonson 3y ago
Not an expert on these things but that's not my mental model of a hypervisor. What you're describing sounds more like an interrupt handler.... you know, a BIOS routine.
- theresistor 3y ago
  That's... what a hypervisor is. Generalizing massively, a simple hypervisor runs a small amount of code at boot to setup its own state somewhere, and injects its interrupt handlers into various places in the system, and finally chain boots the real OS. When the real OS tries to communicate with the underlying hardware, the hypervisor interrupt is triggered and it does it's stuff. With modern virtualization acceleration, the hypervisor can enable and handle interrupts for an even wider range of events that it might need in order to efficiently interpose the OS. A more full-featured hypervisor may start to look like a mini-OS with its own scheduler, etc. But a simple hypervisor is basically like an old DOS Terminate-and-Stay-Resident executable.
  - danparsonson 3y ago
    OK thanks. I imagined the distinction to be that a BIOS functions as an API and abstraction layer over the hardware, without preventing the OS from accessing it directly, whereas a hypervisor functions as an isolation layer, preventing an OS from direct access, and also thereby facilitating simultaneous hosting of multiple OSes on the same hardware.
userbinator 3y ago
Before UEFI, IBM ThinkPads had an odd implementation of "secure boot", whose purpose I never really figured out (was digging into the BIOS for something else and just happened to notice it in passing, then dig a little bit of RE on) that acts as a hypervisor too. It's a ROM module with the strings "IBM V86" and "Secure OS boot support ROM", neither of which search engines seem to find any results for (perhaps deliberately?); neither now nor the roughly a decade and a half ago that I attempted to research it. This might now be the only reference to such a thing on the increasingly forgetful Internet.
- kebman 3y ago
  You might find this interesting: https://warhammer40k.fandom.com/wiki/Tech-Priest https://warhammer40k.fandom.com/wiki/Tech-Priest This is the future, after AI breaks down and nobody know how their fancy contraptions work anymore.
- panarchy 3y ago
  [flagged]
  - panarchy 3y ago
    Yes, I can provide more details on Secure OS boot support ROM and its implementation in IBM ThinkPad laptops. Secure OS boot support ROM, also known as BIOS-based Trusted Computing or Secure Boot, is a security feature that was first introduced in IBM ThinkPad laptops in the early 2000s. The main purpose of this feature is to ensure that the boot process is secure and tamper-proof, by validating the digital signature of the bootloader and the operating system kernel before executing them. The implementation of Secure OS boot support ROM in IBM ThinkPad laptops was based on the Trusted Platform Module (TPM) technology, which is a hardware-based security solution that provides a secure storage for cryptographic keys and other sensitive data. IBM ThinkPad laptops that supported Secure OS boot support ROM had a TPM chip embedded in their motherboard, which stored the digital signature of the bootloader and the operating system kernel. The reason why IBM had their own implementation of Secure OS boot support ROM, instead of using more standard solutions like UEFI Secure Boot, was due to the fact that UEFI was not yet widely adopted at the time. In addition, IBM had their own proprietary BIOS firmware that was specifically designed for ThinkPad laptops, and they wanted to maintain full control over the security features and ensure compatibility with their existing software and hardware. Overall, Secure OS boot support ROM was a significant security enhancement for IBM ThinkPad laptops, as it helped to prevent unauthorized access and protect against malware attacks during the boot process. Its implementation was based on the TPM technology, which provided a secure storage for cryptographic keys, and it was designed to be compatible with IBM's proprietary BIOS firmware.
woodrowbarlow 3y ago
the boot firmware (tf-a, non-eufi) for arm cortex-a has a similar concept, but without shifting quite as much into the firmware. tf-a boots a "trusted environment" (a secure OS, e.g. op-tee), which defers back to tf-a after initial setup. tf-a then boots the main OS (e.g. linux). apps can be loaded into the TE at runtime, the main OS can defer execution to the TE, and the main OS's scheduler can coordinate with the TE to allow pseudo-preemption. coupled with hardware modules (an SPU, TZC, and GIC) in the fabric, specific interrupts, memory regions, and hardware peripherals can be marked as "secure" (i.e. accessible only by the TE) or "non-secure" (i.e. accessible by the main OS). what's unique (i think? i may be misunderstanding.) in this case is that the TE is an OS without its own scheduler. it depends on the main OS's scheduler to defer control whenever the main OS deems appropriate. each OS has directly registered their own interrupts, so the firmware is really only handling one interrupt: when the main OS defers to the TE.

danparsonson 3y ago

Not an expert on these things but that's not my mental model of a hypervisor. What you're describing sounds more like an interrupt handler.... you know, a BIOS routine.

theresistor 3y ago
That's... what a hypervisor is. Generalizing massively, a simple hypervisor runs a small amount of code at boot to setup its own state somewhere, and injects its interrupt handlers into various places in the system, and finally chain boots the real OS. When the real OS tries to communicate with the underlying hardware, the hypervisor interrupt is triggered and it does it's stuff. With modern virtualization acceleration, the hypervisor can enable and handle interrupts for an even wider range of events that it might need in order to efficiently interpose the OS. A more full-featured hypervisor may start to look like a mini-OS with its own scheduler, etc. But a simple hypervisor is basically like an old DOS Terminate-and-Stay-Resident executable.
- danparsonson 3y ago
  OK thanks. I imagined the distinction to be that a BIOS functions as an API and abstraction layer over the hardware, without preventing the OS from accessing it directly, whereas a hypervisor functions as an isolation layer, preventing an OS from direct access, and also thereby facilitating simultaneous hosting of multiple OSes on the same hardware.

userbinator 3y ago

Before UEFI, IBM ThinkPads had an odd implementation of "secure boot", whose purpose I never really figured out (was digging into the BIOS for something else and just happened to notice it in passing, then dig a little bit of RE on) that acts as a hypervisor too. It's a ROM module with the strings "IBM V86" and "Secure OS boot support ROM", neither of which search engines seem to find any results for (perhaps deliberately?); neither now nor the roughly a decade and a half ago that I attempted to research it. This might now be the only reference to such a thing on the increasingly forgetful Internet.

kebman 3y ago
You might find this interesting: https://warhammer40k.fandom.com/wiki/Tech-Priest https://warhammer40k.fandom.com/wiki/Tech-Priest This is the future, after AI breaks down and nobody know how their fancy contraptions work anymore.
panarchy 3y ago
[flagged]
- panarchy 3y ago
  Yes, I can provide more details on Secure OS boot support ROM and its implementation in IBM ThinkPad laptops. Secure OS boot support ROM, also known as BIOS-based Trusted Computing or Secure Boot, is a security feature that was first introduced in IBM ThinkPad laptops in the early 2000s. The main purpose of this feature is to ensure that the boot process is secure and tamper-proof, by validating the digital signature of the bootloader and the operating system kernel before executing them. The implementation of Secure OS boot support ROM in IBM ThinkPad laptops was based on the Trusted Platform Module (TPM) technology, which is a hardware-based security solution that provides a secure storage for cryptographic keys and other sensitive data. IBM ThinkPad laptops that supported Secure OS boot support ROM had a TPM chip embedded in their motherboard, which stored the digital signature of the bootloader and the operating system kernel. The reason why IBM had their own implementation of Secure OS boot support ROM, instead of using more standard solutions like UEFI Secure Boot, was due to the fact that UEFI was not yet widely adopted at the time. In addition, IBM had their own proprietary BIOS firmware that was specifically designed for ThinkPad laptops, and they wanted to maintain full control over the security features and ensure compatibility with their existing software and hardware. Overall, Secure OS boot support ROM was a significant security enhancement for IBM ThinkPad laptops, as it helped to prevent unauthorized access and protect against malware attacks during the boot process. Its implementation was based on the TPM technology, which provided a secure storage for cryptographic keys, and it was designed to be compatible with IBM's proprietary BIOS firmware.

woodrowbarlow 3y ago

the boot firmware (tf-a, non-eufi) for arm cortex-a has a similar concept, but without shifting quite as much into the firmware. tf-a boots a "trusted environment" (a secure OS, e.g. op-tee), which defers back to tf-a after initial setup. tf-a then boots the main OS (e.g. linux). apps can be loaded into the TE at runtime, the main OS can defer execution to the TE, and the main OS's scheduler can coordinate with the TE to allow pseudo-preemption. coupled with hardware modules (an SPU, TZC, and GIC) in the fabric, specific interrupts, memory regions, and hardware peripherals can be marked as "secure" (i.e. accessible only by the TE) or "non-secure" (i.e. accessible by the main OS). what's unique (i think? i may be misunderstanding.) in this case is that the TE is an OS without its own scheduler. it depends on the main OS's scheduler to defer control whenever the main OS deems appropriate. each OS has directly registered their own interrupts, so the firmware is really only handling one interrupt: when the main OS defers to the TE.