6 ms·

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
        I do not understand what results in this confusion. > 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 This is exactly what I know and what I said in my original post: a way to identify which VM is accessing what. For... giving that VM access to the hardware. > 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. Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from. This is entirely the definition of giving the VM direct access to the hardware. There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface. For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise. > 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. Not at all. Usually IOMMU is for constraining hardware that already has direct access to the RAM in the first place. > 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) Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view). > 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 This is meaningless because it mixes and matches everything. What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c). But the entire point of this is again to give the VM direct access to hardware! What is it exactly that you want to refute from this?

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
        I do not understand what results in this confusion. > 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 This is exactly what I know and what I said in my original post: a way to identify which VM is accessing what. For... giving that VM access to the hardware. > 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. Again, this is exactly what I said: you are now at the mercy of the hardware manufacturer whether there is any partitioning whatsoever. To think otherwise is wishful thinking that I do not know where it comes from. This is entirely the definition of giving the VM direct access to the hardware. There is no software-controlled emulation whatsoever going on, so you explicitly lose containment and increase your attack surface. For everything except the simplest of ethernet cards, your hardware is likely implementing this multiplexing in closed source firmware done by hardware engineers. Very likely the worst type of code ever written security-wise. > 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. Not at all. Usually IOMMU is for constraining hardware that already has direct access to the RAM in the first place. > 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) Is this the source of the confusion? That because it is called virtual you think this virtualized somehow? It is the reason I call it partition because it is much closer to what it is (from a hw point of view). > 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 This is meaningless because it mixes and matches everything. What does it mean to "virtualize the RAM"? RAM is already virtualized by the normal MMU, no VT-d needed at all. Hardware is the one who may require to also have its RAM access virtualized so its idea of memory matches that of the VM directly accessing hardware (instead of through a software emulation layer), and that is what benefits from an IOMMU (but does not generally require it, see GART and VT-c). But the entire point of this is again to give the VM direct access to hardware! What is it exactly that you want to refute from this?