Kernel Address Space Isolation Aims To Prevent Leaking Data From Hyper Threading Attacks

[phoronix]

Phoronix: Kernel Address Space Isolation Aims To Prevent Leaking Data From Hyper Threading Attacks

Kernel Address Space Isolation is an experimental feature in development by Oracle in aiming to prevent leaking sensitive data from Intel Hyper Threading due to speculative execution attacks like L1TF...

http://www.phoronix.com/scan.php?page=news_item&px=Kernel-Address-Space-Isolation

[tildearrow]

Has this been done by Windows already? (if I remember correctly on 32-bit Windows maps 0x00000000 to 0x7fffffff to user-space and 0x80000000 to 0xffffffff to kernel space)

[Michael]

Has this been done by Windows already? (if I remember correctly on 32-bit Windows maps 0x00000000 to 0x7fffffff to user-space and 0x80000000 to 0xffffffff to kernel space)

This is about even isolating different areas of the kernel, e.g. KVM.

[Milan Kerslager]

They mean to have fixed physical address (for kernel, process/KVM), not virtual. In normal conditions, when memory space is requested, kernel/process gets random pool of memory which used to be a part of another process in the past and this is a problem as it may contain sensitive information.

[scoobs]

Wonder how much the licence will cost.

[nivedita]

They mean to have fixed physical address (for kernel, process/KVM), not virtual. In normal conditions, when memory space is requested, kernel/process gets random pool of memory which used to be a part of another process in the past and this is a problem as it may contain sensitive information.

What does that even mean? Whatever it is, it’s nothing to do with this proposal, which as Michael says is meant to allow bits of the kernel (specifically kvm) to run in a separate address space that does not map most of the kernel, and as such prevents any leaks of the rest of kernel memory via side-channel leaks. It is meant as a mitigation for some of the side-channel issues that at present can only be fully mitigated by turning off hyperthreading.

[coder]

Can anyone explain why the HT-related side channel attacks can't be foiled by simply refusing to concurrently run tasks from different processes on the same physical core? In other words, if both hyper-threads sharing a core always belong to the same process, then you pretty much eliminate that attack vector.

[JEBjames]

Can anyone explain why the HT-related side channel attacks can't be foiled by simply refusing to concurrently run tasks from different processes on the same physical core? In other words, if both hyper-threads sharing a core always belong to the same process, then you pretty much eliminate that attack vector.

The performance down side is the paired hyper-thread may sit idle. Not because there is no threads to run, but because there's no threads we trust to run at the same time.

i.e. should a kernel thread and any user-thread run on the matched hyper-threaded pairs? Probably not.

It's looking like "just disable hyper-threading on Intel" may be the way.

[nivedita]

Can anyone explain why the HT-related side channel attacks can't be foiled by simply refusing to concurrently run tasks from different processes on the same physical core? In other words, if both hyper-threads sharing a core always belong to the same process, then you pretty much eliminate that attack vector.

You still have the problem that one thread might go into kernel mode, or one thread might switch from guest to hypervisor. An alternative to the proposed feature mentioned in the mail thread is exactly that though (for VM's), and in addition stop any SMT siblings if one thread switches to hypervisor.

[coder]

The performance down side is the paired hyper-thread may sit idle. Not because there is no threads to run, but because there's no threads we trust to run at the same time.

Well, of course there'd be a performance cost, but at least it should be better than completely disabling HT!