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

[fedora-user]

Wonder how much the licence will cost.

he he he Oracle becomes friendly EVIL.

[coder]

I read an article (I think on Phoronix) were some hyper-threading mitigations attempts were worse than just disabling hyper threading.

AFAIK, none of those mitigations involved the sort of simple scheduling constraint that I described.

One beef I have with thread scheduling is that I'm not aware of an API for telling the kernel which threads are involved in high-bandwidth or require low-latency communication with each other. That, and I should be able to define thread sets with different compute characteristics, so the scheduler can know which threads it can pair up nicely. I've been down the road of manually setting thread affinity, but that places too much burden on the programmer and really over-specifies the constraints.

I'm a fan of the way OpenCL's approach to the first problem, although the second problem doesn't apply so much to OpenCL.

[JEBjames]

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

I'm not disagreeing with you. It's definitely is a case where it sounds like it "should".

I read an article (I think on Phoronix) were some hyper-threading mitigations attempts were worse than just disabling hyper threading.

It's a crazy world where programmers intentionally throw out CPU cache and pile extra work into context switching.

[coder]

You still have the problem that one thread might go into kernel mode, or one thread might switch from guest to hypervisor.

Thanks. I'm used to thinking of those cases as basically synonymous with context switches, but thanks for reminding me that they're not.

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.

It's what I'd do!

[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!

[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.

[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.

[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.

[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.

[scoobs]

Wonder how much the licence will cost.