Intel CPUs impacted by new PortSmash side-channel vulnerability

It should be possible to do the same thing on anything that supports CPU frequency scaling. Tell the OS that the core the browser is running on should only run at the lowest supported frequency. Or only allow it to run at higher frequency if it hasn't been active for more than 15 of the last 60 seconds.

FYI Apple didn't come up with the idea of having differing cores: https://en.wikipedia.org/wiki/ARM_big.LITTLE

Under optimal conditions (rendering) enabling SMT on Intel gives just ~30% extra performance, ~40% on AMD (usually much less), so of course you can't compare the additional thread provided by SMT to a thread running on another, otherwise idle core.

Scheduling only threads of the same process on a SMT group at a time is the easiest portsmash mitigation while still retaining some of the SMT peformance benefit.

I don't need to be in the 1990s, I just wished websites wouldn't need to draw from ~200 untrusted sources and possibly worlds largest malware distribution channel to show some ads from even less trusted sources right next to badly formatted text.

With Noscript enabled I have the power to chose what to trust and not to trust. That means I have gradual control over what runs and doesn't run, and can chose to only allow the bare minimum for getting a specific page to run. It's that simple.

JS is fine as a technology, but blindly executing every single piece of code on every single web page is simply not a good way of doing things.

In what ways could JS be limited to preclude such attacks? (E.g. no JIT compilation, cache flush after every opcode, etc.).

>For example, your web browser probably by default runs Javascript, NaCl, or WebAsm code, which is supposedly sandboxed sufficiently to no longer be a threat to the other stuff running on your machine.

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.

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

At what point does the extra complexity and cost of including SMT in the design outweigh the gains is provides if you can only use it in specific situations, and if you don't err on the side of caution is may be a security problem?

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.

SMT is like a shared kitchen. Even if you're unable to see the other person in it, if you go to use the sink, oven, or microwave and have to wait because it's in use, you know some small bit about the other occupant. Knowing how long you have to wait tells you more. Knowing what is already stocked in the fridge from the other occupant that you can immediately use tells you a lot.

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.

Basically timing attacks are completely unavoidable on SMT because SMT fundamentally depends on what the other thread is doing on the core, if the thread is using few core resources the attack thread gets more, or vice versa. This gives you a very fine grained view into what the other thread is doing timing wise, and is inherent to the concept of SMT (two threads running on a core at once, using resources not utilized by the other).

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.

Sure, but OpenBSD has a very specific project goal and use cases (which is absolutely as it should be!) and their stance thus makes sense in context. But it doesn't mean their stance is universally applicable either, anymore then best practices for IaaS all apply everywhere. For an alternate feature example: some OpenBSD committers for years have reasonably rejected OpenZFS [1] requests because it was considered to be just plain too big, and in turn presented more threat surface and higher system resource consumption (big issue for embedded/firewall appliance applications) then was desirable for them. All of which is true and makes total sense there. But not for a lot of big servers and end user systems where I think automatic full data consistency/checks/regeneration, easy full replication, trivial cheap atomic snapshots, portability between many OS, and so on, address much more important threats then the extra load or any unknown potential vulns. No need for a monoculture ecosystem here rather then using the right specific tool for the job right?

-----

1: https://www.tedunangst.com/flak/post/ZFS-on-OpenBSD

Welcome to the hive mind.

Any number of possible reasons.

OpenSSL shipped a patch for it in that interval. Intel isn't going to fix it faster than OpenSSL ships a patch revealing it unless they already had a convenient killbit for the affected things.

I have no idea what the relevant researcher's policies are, but I would assume we'll hear about it if somebody requested a longer embargo and they refused.

(It also appears to be much harder to reproduce in the presence of dynamic clock speeds, so the impact in most smaller environments is going to be low unless someone does further work to make it reproduce well with that.)

Bad experience in the past probably. Also this probably just leads to the official recommendation to disable Hyper-Threading "for security critical applications" or some PR blurb.

As much fun as a 4 GHz Tualatin 4- or 8-core CPU sounds, it would probably take several years of development to make something usable by today's standards.

The i9 is their "performance at any cost, even security" chip. It's for people who want/need the absolute fastest chip and damn the torpedoes. It's so far past the optimal point on the price/performance curve that nobody sensible will be buying it unless they have a very specific need.