I think that would fall under "Even if it's desirable to run some risky code as well" and using hard core affinity wouldn't it? For performance oriented use cases 8-core and higher systems are not exactly super rare at this point, and AMD at least has been pushing the physical core counts pretty hard even on non-super high end chips. In a single owner/trusted dedicated metal case it's a lot easier to just say "core 1 is for running web code and that's it, if every core is needed for something else the web stuff will all be evicted and slept until that's over" which on a percentage basis doesn't incur that big a hit in a high core system. It's not like a IaaS system that's devoted to running dozens/hundreds of commercial client VMs and needs to be able to perform dynamic allocation with no manual intervention and untrusted code is the rule not the exception. IaaS is all about scaling, and that's a hard and interesting problem. But sometimes for individual instances it works fine to just pick a completely non-scalable solution that gets the job done and brute force it.
I'm just thinking that it's worth remembering that most security is an economic equation, and sometimes performance is in fact worth it, or the security issue can be soft mitigated sufficiently in a restricted case. "Only trusted signed code may use SMT" for example, that won't work everywhere and it doesn't mitigate SMT still being a dangerous feature, but it may be plenty good enough in some instances. Or perhaps there is a server where the only truly sensitive piece is the private key, and that simply gets offloaded into an HSM blackbox and thus isn't available to be compromised anyway. Or the auth/signing servers disable it but other boxes do not.
Basically, it just seems like it's too valuable a feature and the threat scenario not universal enough for it to be simply abandoned entirely as the authors suggest given the physical and economic realities we're facing right now with silicon.
There's a very simple solution here. Don't schedule two threads with different trust domains on different SMT threads on the same core. No need to change any hardware, no need to disable anything, just accept (as has been known for at least a decade) that there is very likely to be a side channel attack if you look hard enough when SMT is involved.
A single thread already has two different trust domains (user mode and kernel mode), so any pair of threads will have different trust domains when one of them is running a system call or an interrupt. So this solution would also have to either pause the SMT sibling while entering the kernel, or run the kernel code in a separate core (an idea like this was briefly suggested on the RISC-V isa-dev mailing list a few months ago: to have a separate core which handles interrupts and kernel mode for a group of user-mode-only cores).
If it was clearly outlined as 8 cores that support hyperthreads or 10 cores that don't for around the same price, what do we suppose most people would choose?
Part of the reason for the current status quo might be that hyperthreads are a big differentiator beteen AMD and Intel, and play towards Intel's strength (higher clock speeds at fewer cores).
We have something close to the proposed scenario starting to play out with AMD's offerings that support more cores and no hyperthreading, but it's not a perfect experiment because AMD's cores are also lower clock speed, and there's a lot of brand name loyalty currently.
Ah, that's what I was looking for. I'm aware that most the resources are shared, but I also assume there have been design choices in other components to make SMT easier or faster, and possibly that increases their die size a small amount, or in general just complicates their design.
The question (which is ultimately unanswerable) is what would we have had Intel not chosen SMT as the path to pursue? If they had instead invested those resource into other areas (e.g. more cores) and never let SMT concerns enter into the discussion, how would those (theoretical) CPUs compare?
That's the CPU comparison I was alluding to in the prior comment, and why I noted AMD vs Intel (even with all it's other differences) may be the closest match up of that idea we'll see.
It wasn't meant as a rebuttal to anything, it was more a "wondering out loud" type of comment spurred by yours, about what could have been had different paths been taken.
Separate cores are more like completely separate kitchens. Sure, the grocery delivery service might take shorter or longer some times, but it's hard to tell much beyond general area business from that. What's in your fridge is what you put there.
I suspect this issue is completely impossible to resolve in anything except very constrained situations that negate the benefit of SMT entirely.
Its different than say, a timing attack on the OS scheduler for two reasons
1. OS scheduling is very coarse (A process gets exclusive use of a core for tens of thousands or hundreds of thousands of cycles), with SMT you get a very fine grained near cycle-by-cycle view of core utilization by the other process.
2. you don't get much of a view into what precisely the other thread is doing such as is it doing lots of integer operations, floating point, memory fetches etc, which can be derived in SMT attacks based on how fast such things occur for the evil monitoring thread.
-----
>"This is the main reason we released the exploit -- to show how reproducible it is," Brumley told us, "and help to kill off the SMT trend in chips."
>"Security and SMT are mutually exclusive concepts," he added. "I hope our work encourages users to disable SMT in the BIOS or choose to spend their money on architectures not featuring SMT."
I don't blame them for being security focused about all else at any cost and any layer, that's their gig. But I think the real response here is likely to be a lot more subtle and interesting. Of course perhaps SMT can in fact be fixed for this without a wholesale tossing in which case it'll just be a universal hardware revision somewhere down the line. This increasing level of public research and awareness of this specific class is still relatively early days after all. But taking it as a given for argument that there really is a fundamental conflict, the fact would remain that SMT can provide significant performance gains, and furthermore that we're still far from the point where SaaS/IaaS is everywhere. Lots of systems are still under single user local control, and in turn attackers being able to co-run their own arbitrary code on the same physical core isn't necessarily part of the threat model at all (and more specifically if attackers get that far least common denominator kicks in, they've already owned what's important). Even if it's desirable to run some risky code as well, hard core affinity for non-secure processes is a brute force solution in a local system context that seems like it shouldn't be a big deal given the a surfeit of physical/logical cores for many work loads.
But perhaps this could be a leading edge of true processor level physical differentiation required between IaaS and more traditional deployments, and that might make for an interesting change to the competitive landscape there. It'd change the cost/benefit in some scenarios, or require more custom processor work to enact harder (and performance costing) boundaries that a traditional setup might take care of with machine isolation. I wonder if that could shift things back away from the Cloud and centralization trend in some instances, or at least create and more dynamic market?