5 ms·

> You'd lose things like hardware acceleration. This is increasingly less true. SR-IOV and S-IOV are becoming increasingly common even in consumer hardware and

> You'd lose things like hardware acceleration. This is increasingly less true. SR-IOV and S-IOV are becoming increasingly common even in consumer hardware and OS manufacturers are increasingly leaning on virtualisation as a means to protect users or provide conveniences. WSL has helped with virtualisation support quite a bit as a means of getting hardware manufacturers to finally play nice with consumer virtualisation. And Microsoft is even now provides full ephemeral Windows VM "sandboxes". The feature that came with them that surprised me was that they support enabling proper GPU virtualisation as well.

AshamedCaptain 1y ago
But then you have your "VMs" accessing the real hardware, so the benefits of the VM reduce if not disappear. You literally can't have the cake and eat it too.
- OneDeuxTriSeiGo 1y ago
  Not entirely? The virtualised PCIE frameworks (SIOV, SRIOV, etc) don't actually give direct access to the hardware but rather create a virtualised device inside the PCIE device akin to how modern PCs virtualise CPUs and memory.
  - AshamedCaptain 1y ago
    Well, that's precisely the point of these frameworks. They give direct access to the hardware in order to gain the speed advantages of ... directly accessing the hardware. The PCIe aspect of this is just (very high level description) a way to let the hardware know what VM is making the request. You're now at the mercy of the hardware manufacturer on whether there's isolation between the different "partitions" or ... nothing at all. Your attack surface expands in a way that's difficult to imagine.
    - 0points 1y ago
      > They give direct access to the hardware > You're now at the mercy of the hardware manufacturer No! Read up on SR-IOV before you continue posting more misleading nonsense. https://en.wikipedia.org/wiki/Single-root_input/output_virtualization https://en.wikipedia.org/wiki/Single-root_input/output_virtu...
      - AshamedCaptain 1y ago
        And why don't you explain what exactly you think the nonsense is rather than violating the HN guidelines with a contentless RTFM message? Your one link literally says the same thing I have said (a way to multiplex access to the bus). This is ALL about giving VMs direct access to hardware. It makes no sense to even discuss features like this otherwise. What do you think this is for if not real hardware acess? Giving VM hosts an easier time emulating Intel PRO1000 ethernet cards?
        OneDeuxTriSeiGo 1y ago
        This is a better description of what it's doing: SR-IOV: https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer-sr-iov-technology-paper.pdf https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer... S-IOV: https://cdrdv2-public.intel.com/671403/intel-scalable-io-virtualization-technical-specification.pdf https://cdrdv2-public.intel.com/671403/intel-scalable-io-vir... What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything. This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU. And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions) and all of the context associated, the registers, the BAR, etc. This is akin to how VT-x and similar instructions virtualise the CPU (and registers, etc). And notably these virtual functions can be restricted via access controls, quotas, etc in hardware. So your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general). Now SR-IOV and S-IOV virtualise the PCI-E bus w/ access control over the lanes. And now SR-IOV and S-IOV virtualise the PCI-E device hardware and their functions/interface on the bus (akin to VT-x and VT-d). Now notably S-IOV should be seen as a "SR-IOV 2.0" rather than an accompanying feature. It essentially moves the virtual function to physical function translation from the CPU or hardware in the chipset directly into the PCI-E device itself.

AshamedCaptain 1y ago

But then you have your "VMs" accessing the real hardware, so the benefits of the VM reduce if not disappear. You literally can't have the cake and eat it too.

OneDeuxTriSeiGo 1y ago
Not entirely? The virtualised PCIE frameworks (SIOV, SRIOV, etc) don't actually give direct access to the hardware but rather create a virtualised device inside the PCIE device akin to how modern PCs virtualise CPUs and memory.
- AshamedCaptain 1y ago
  Well, that's precisely the point of these frameworks. They give direct access to the hardware in order to gain the speed advantages of ... directly accessing the hardware. The PCIe aspect of this is just (very high level description) a way to let the hardware know what VM is making the request. You're now at the mercy of the hardware manufacturer on whether there's isolation between the different "partitions" or ... nothing at all. Your attack surface expands in a way that's difficult to imagine.
  - 0points 1y ago
    > They give direct access to the hardware > You're now at the mercy of the hardware manufacturer No! Read up on SR-IOV before you continue posting more misleading nonsense. https://en.wikipedia.org/wiki/Single-root_input/output_virtualization https://en.wikipedia.org/wiki/Single-root_input/output_virtu...
    - AshamedCaptain 1y ago
      And why don't you explain what exactly you think the nonsense is rather than violating the HN guidelines with a contentless RTFM message? Your one link literally says the same thing I have said (a way to multiplex access to the bus). This is ALL about giving VMs direct access to hardware. It makes no sense to even discuss features like this otherwise. What do you think this is for if not real hardware acess? Giving VM hosts an easier time emulating Intel PRO1000 ethernet cards?
      - OneDeuxTriSeiGo 1y ago
        This is a better description of what it's doing: SR-IOV: https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer-sr-iov-technology-paper.pdf https://cdrdv2-public.intel.com/321211/pci-sig-sr-iov-primer... S-IOV: https://cdrdv2-public.intel.com/671403/intel-scalable-io-virtualization-technical-specification.pdf https://cdrdv2-public.intel.com/671403/intel-scalable-io-vir... What they are doing is "technically" giving direct bus access, however the bus access they are giving is restricted such that the VM's accesses are all tagged and if they access anything outside the bounds they are permitted (as defined by access controls on the hardware during configuration), then you get a fault instead of the VM successfully touching anything. This is similar to how VT-d and other CPU virt extensions allow direct access to RAM but with permissioning and access control through the IOMMU. And then the other major component of SR-IOV and S-IOV is that they virtualise the interface on the PCI-E hardware itself (called virtual functions) and all of the context associated, the registers, the BAR, etc. This is akin to how VT-x and similar instructions virtualise the CPU (and registers, etc). And notably these virtual functions can be restricted via access controls, quotas, etc in hardware. So your existing VT-x extension virtualises the CPU, your existing VT-d extension virtualises the IOMMU and RAM, your existing VT-c virtualises network interfaces (but not PCI-E in general). Now SR-IOV and S-IOV virtualise the PCI-E bus w/ access control over the lanes. And now SR-IOV and S-IOV virtualise the PCI-E device hardware and their functions/interface on the bus (akin to VT-x and VT-d). Now notably S-IOV should be seen as a "SR-IOV 2.0" rather than an accompanying feature. It essentially moves the virtual function to physical function translation from the CPU or hardware in the chipset directly into the PCI-E device itself.