-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, Nov 22, 2016 at 01:30:31PM -0500, Steve Coleman wrote: > I know the developers at ITL have their hands busy with this right issue > right now, but I have a (long winded) curiosity question in hope to gain > some context when you get a chance to think about it. > > I can see that in this particular potential exploit one might use a client > vm's PCI device to exploit an emulated instruction, then used to generate a > memory offset that potentially could be used as a pointer to break out of > the Xen hypervisor jail. Correct? > > My question here would be whether the Xen FLASK subsystem might have given > some level of protections against this kind of "emulated" instruction > exploit, given that labeling of virtual devices and memory is supported > (e.g. flask-label-pci). I realize you may need to give client VMs access to > pci devices in general, and this particular pci label does not protect > against use of pointers to memory, but could the client call then be > restricted to just the necessary IO memory in this case, and thus forcing an > AVC denial fault when that generated pointer is actually used outside that > range? Or are these emulated instructions running in a hypervisor context > that would ignore its own FLASK policy?
The later case. Additionally I don't think XSM is plugged in x86_emulate anywhere. If domain is given permission to access some resource (and the policy allow it at this stage), it isn't re-checked later. At least this is my understanding of quick grep results. Generally XSM/FLASK policy can be used only to limit what operations can be triggered by a VM. If implementation of particular operation is buggy, and the operation itself is allowed by XSM, that's over. None of last Xen critical bugs affecting Qubes OS could be stopped by proper XSM/FLASK policy. Exactly for the same reason. On the other hand, our architecture (for example having qemu sandboxed in stub domain, not using pygrub, etc) make most of Xen vulnerabilities harmless for Qubes OS. XSM could help if the buggy operation would not be needed at all - in this case it could be blocked by the policy, so would be out of reach for the attacker. But if the operation isn't needed, maybe it shouldn't be in the hypervisor at all? This is why we're advocating for having as much as (reasonably) possible code disabled compile time using Kconfig. Not supporting non-SLAT/EPT hardware in Qubes 4.0 is one of those things - - we do not include shadow page table code at all there. It isn't possible to compile-time disable all the PV handling code, at least not yet. But work towards PVHv2 might make it possible (in Xen 4.9 perhaps...). But still - instruction emulation in some cases still would be needed... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYNM1zAAoJENuP0xzK19csOIEH/jE05gE1u7BaqZLoQ7RX0iWt KSHKoyWV4xR0pWSMxob4bhGBj2Ktyh5m9CARg36XiwDLaDNgrD1NmH8ouIak6yqW 1MFL2FM4MaNDukYdUbPdR5I1jSFynAS+dD4wD6WH5IzKSiWWh3avreMEXn173pyr lKPu5VevjoXkIYAhW2Q8QVKePKHYiXO25HaaeQ4urOqk3e9VgV4mqcW/c/rgZJfs mkIfn1O3hXo5aZmFYVMnCJcIYggh6bGqZy6GO/Btlg8VTacB5eoriAXKi8zghFBy lGRdswSXCaSPnR8QFdxj2HYH1mOfoZdntOTT6X3CKM4Gntvil7at/XwDU3dUrYE= =hTm6 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20161122225754.GH1145%40mail-itl. For more options, visit https://groups.google.com/d/optout.
