On 05/01/18 18:16, Rich Persaud wrote: >> On Jan 5, 2018, at 06:35, Lars Kurth <lars.kurth....@gmail.com >> <mailto:lars.kurth....@gmail.com>> wrote: >> SP2 can be mitigated in two ways, both of which essentially prevent >> speculative execution of indirect branches. The first is to flush the >> branch prediction logic on entry into the hypervisor. This requires >> microcode updates, which Intel and AMD are in the process of >> preparing, as well as patches to the hypervisor which are also in >> process and should be available soon. > > The Linux kernel's IBRS patchset has a doc link which compares > retpoline, IBRS Dynamic ("opt-in") and IBRS Always On ("opt-in if more > paranoid"). > > https://lkml.org/lkml/2018/1/4/615 > > https://docs.google.com/document/d/e/2PACX-1vSMrwkaoSUBAFc6Fjd19F18c1O9pudkfAY-7lGYGOTN8mc9ul-J6pWadcAaBJZcVA7W_3jlLKRtKRbd/pub > > Would be nice to have that comparison for other CPU vendors. Some > information is aggregated at https://github.com/marcan/speculation-bugs: > > "This repo is an attempt to collect information on the class of > information disclosure vulnerabilities caused by CPU speculative > execution that were disclosed on January 3rd, 2018. Existing > nomenclature is inconsistent and there is no agreed-upon name for the > entire class of bugs, but the names Spectre and Meltdown have been > used for subclasses of attacks. This is a combination of publicly > available information and educated guesses/ speculation based on the > nature of the attacks. Pull requests with corrections or discussion > are welcome."
Prefer the google names. Spectre in particular is a mix of two quite different attack techniques. > >> Linux’s KPTI series is designed to address SP3 only. For Xen guests, >> only 64-bit PV guests are affected by SP3. A KPTI-like approach was >> explored initially, but required significant ABI changes. Instead >> we’ve decided to go with an alternate approach, which is less >> disruptive and less complex to implement. The chosen approach runs PV >> guests in a PVH container, which ensures that PV guests continue to >> behave as before, while providing the isolation that protects the >> hypervisor from SP3. This works well for Xen 4.8 to Xen 4.10, which >> is currently our priority. > > Since PVH does not yet support PCI passthrough, are there other > recommended SP3 mitigations for 64-bit PV driver domains? Lock them down? Device driver domains, even if not fully trusted, are going to be part of the system and therefore at least semi-TCB. If an attacker can't run code in your driver domain (and be aware of things like server side processing, JIT of SQL, etc as "running code" methods), they aren't in a position to mount an SP3 attack. > Would CPU pinning of an untrusted guest driver domain reduce its > ability to attack the host? All of SP1/2/3 can in principle be used to attack Xen, at which point you have to presume that the entire system is readable. CPU pinning can be used to prevent certain guests from sharing branch prediction resources, and thus prevent them from directly attacking each other using SP1 or SP2. However, you can't isolate Xen away from the guest, so pinning is no mitigation against attacks targeting Xen. > Since 32-bit PV guests are not affected by SP3, will they continue to > run without a PVH container, so that PCI passthrough continues to > function? 32bit PV guests are unable to use SP3 to attack Xen, but 32bit PV guest userspace can still use SP3 to attack the guest kernel. ~Andrew
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
