I feel we ought to be having a serious discussion about the deeper implications of this commit into the Linux kernel:

git.kernel.org/pub/scm/linux/k

Not for Linux, of course, but for the feeling that the integration and implications of the HyperThreading fashion could have consequences which we are yet to see.

Today I was asking on the birdsite what just disabling it in the BIOS meant. What is disabled? How does a HT-capable processor boot given the subtle dependencies implied in this patch?

@cynicalsecurity It seems to me there is a need for research on how to kill HyperThreading for good either on bootup or alternatively with a blowtorch and some pliers.

@Kensan my question, which is perhaps more fundamental, is whether you *can* actually kill HT without redesigning the cores. As we previously discussed, with valuable insights, HT was meant as fast inexpensive context switches, Sun worked on that on the Niagara 1 & 2 cores, etc. But now, how does one *remove* HT from these designs? Can you really “disable it in BIOS” (answer: no, as shown by the Linux commit)?

Follow

@cynicalsecurity Unless somebody can explain in deep technical detail what “disabling HT in the BIOS” actually means (i.e. in what state are the threads and how can one still interact with them) the only sane thing to do seems to be to actually bring up *all* logical cores, enable MCE and explicitly park them with interrupts disabled. At least this way all cores are in a well defined state.
Disabling HT in the BIOS is rather hand-wavy until somebody explains what’s actually happening.

@Kensan so the HT is there but dormant… what does this imply? I am so curious as to whether you could leverage these dormant logical processors to do something to the primary core. If it is just sitting there then why not?

@cynicalsecurity If it is in Wait-for-SIPI, then you could bring it up without the BSP or other cores knowing about it, e.g. if no IOMMU with Interrupt Remapping is active a PCI device could send a INIT-SIPI-SIPI to that core with a vector that would let it jump to some code in low-mem. If you have DMA you are golden. Let’s call this scenario: Sleeping beauty attack ;)

@cynicalsecurity Obviously if you have DMA capability you are already far into the system. However with this you could leverage HyperThreading to attack SGX enclaves etc.

@Kensan Good Lord… I have just realised you used INIT-SIPI-SIPI ten years after I brought it up as a possible security concern "between friends" :D

Thank you for the memories…

Now, instead of DMA, what if we had DDIO and sent something from the NIC straight into L1? These days IOMMU is going to be around, probably activated by EFI at boot and VT-d might even be "in use" already (depends on how OS'd your EFI is) so we do DDIO instead, yes? "beyond DMA" our DDIO is the spindle (how ironic…).

@cynicalsecurity Yes, it’s very basic/old stuff. However it is tried and true ;)
As for IOMMU most BIOS and Linux distros do not enable it by default...

Sign in to participate in the conversation
Mastodon

Follow friends and discover new ones. Publish anything you want: links, pictures, text, video. This server is run by the main developers of the Mastodon project. Everyone is welcome as long as you follow our code of conduct!