My guess is that HPC systems which run applications whose performance strongly depends on efficient data scatter gather will immediately disable the mitigation.
Is that 50% overhead for "Gather" instructions? If that is the case, then if 10% of instructions are "gathers" in your workload then that would be 5% overall.
"Red Hat’s internal performance testing of a worst-case microbenchmark showed a significant slowdown. However, more realistic applications that utilize vector gathering showed only low single-digit percentage slowdowns."
The performance impact of the microcode mitigation is limited to applications that use the gather instructions provided by Intel Advanced Vector Extensions (AVX2 and AVX-512) and the CLWB instruction. Actual performance impact will depend on how heavily an application uses those instructions. Red Hat’s internal performance testing of a worst-case microbenchmark showed a significant slowdown. However, more realistic applications that utilize vector gathering showed only low single-digit percentage slowdowns.
If the user decides to disable the mitigation after doing a thorough risk analysis (for example the system isn’t multi-tenant and doesn’t execute untrusted code), the user can disable the mitigation. After applying the microcode and kernel updates, the user can disable the mitigation by adding gather_data_samping=off to the kernel command line.Alternatively, to disable all CPU speculative execution mitigations, including GDS, use mitigations=off.
It is kind of like thinking that it is a huge sale at a store when they say "Up to 70% off". And there are like two things in the whole store which are 70% off.
I always translate such weasel words to their more straightforward equivalent.
"Up to 70% off" means for me "Nothing in our store is discounted by more than 70%" :-)
In general, not really, but the most common string comparison instruction in x86_64 leaves the last character of one of the strings being compared with the other one just being a pointer into the C-style string.
I think you're asking this question because you're wondering if a container that uses environment variables for its configs would show up in this and I think the answer would be no because it's an operating system service that supplies the answers for the values, but every developer on Earth copies the values into variables where there is going to be a pointer put on a register at some point which then would make it vulnerable
It claims to also allow you to read any data loaded into a vector register, any data loaded from a {rep mov} (i.e. memcpy), any data used by crypto acceleration, and a bunch more. Basically, the only data it does not let you read is regular loads into the regular GPRs (i.e. what would be a register load in a RISC architecture) though if you save/restore during context switches using the special instructions you will leak the values at the time of the context switch.
This is about as close to a total cross-process data leak as can be imagined.
All a publication indicates is that a white/grey hat researcher has discovered the vulnerability. There is no way to know if or how many times the same flaw has been exploited by less scrupulous parties in the interim.
And information leak exploits are less likely to be detected than arbitrary code execution. If somebody is exploiting a buffer overflow, they need to get it exactly right, or they'll probably crash the process, which can be logged and noticed. The only sign of somebody attempting Downfall or similar attacks is increased CPU use, which has many benign causes.
Since it is in a class of other well known vulnerabilities, I'm going to assume that there has been quite a bit of active research by state-operated and state-sponsored labs. I think it's more likely than not that this has been exploited.
I'm getting annoyed with all of these yawning security holes in Intel's CPUs. I'm tempted to replace my Intel MacBook Pro with an Apple Silicon model sooner than I normally would.
I'm not sure what evidence there is to think that Apple's chips are any better. And that's not really a dig at Apple; these are just very complicated devices and especially with the optimizations that CPUs need to make to run today's software with acceptable performance, it can become very hard to foresee all possible attacks and vulnerabilities.
I'm not trying to suggest that Apple's ARM chips are magically better because they're designed by Apple. Rather that the x86 architecture is obviously very long in the tooth and now would be a great time to switch to a far more modern architecture especially in light of this steady stream of vulnerabilities and defects that keep being found in x86.
I'm sure ARM64 isn't perfect but I've yet to learn of something as severe as this, or Spectre, or Meltdown.
Almost all of these exploits are due to the out-of-order/speculative execution.. which is incredibly complicated. There is no reason to believe that an out of order architecture that has not been hardened is any better at defense here than x86 - Just that as a minority architecture, it's still less profitable to target for exploitation. I have very little faith that the Apple ARM chips do better here without extensive exploit attempts made...
Speculative vulnerabilities have virtually nothing to do with the instruction set. Changing the language of the processor has little to do with how the processor works under the hood, especially for fundamental technologies like speculative execution.
Also, as a corollary, speaking the same language doesn’t mean every vulnerability is shared. AMD does not seem affected by Downfall, for instance.
x86 architecture is now proven to be a minefield. It has too many instructions, being a CISC instruction set (something that was obsolete in the 90s but was keept for backward compatibility with older software). This means that to make efficient CPU the manufacturer has to do a ton of optimizations. These optimizations have resulted in most of the bugs we have seen.
Contrary ARM or other RISC instruction set are more simple. Being more simple they rely on compilers being more smart to generate optimized programs (something we have to this day). For this processors are more simple and straight forward, they don't need all the complexity of an x86 CPU. For this reason they are also more efficient since they don't waste resources doing useless operations.
Of course vulnerabilities can be everywhere (there were a few also on M1, tough not as impressive like these one, they were mostly stuff nearly impossible to exploit|). But recent times proved that particularly on x86 chips this is a real issue.
All high-performance processors have very complex optimizations. This has nothing to do with x86. The vulnerabilities found in other processors are similar in design and about as difficult to exploit.
That doesn't make any sense. You want to prep a fix for distribution ASAP, and release it so people can be protected from it as soon as possible.
Also many attacks are not really feasible to detect if it's happened - that's like trying to know if the mailman read your postcard.
You can develop executable scanning techniques, but people are a lot more concerned about preventing it in the first place than catching it in the act. Why would you leave people vulnerable so they can watch data get stolen - instead of just fixing the issue?
Not all systems are equally exposed, and while there is no universal low level fix many systems can be redesigned at a higher level to reduce exposure.
They probably concluded it wasn't possible in this case. From their FAQ:
[Q] Is there a way to detect Downfall attacks?
[A] It is not easy. Downfall execution looks mostly like benign applications. Theoretically, one could develop a detection system that uses hardware performance counters to detect abnormal behaviors like exessive cache misses. However, off-the-shelf Antivirus software cannot detect this attack.
I don't think so. This vulnerability is leaking data from a load-buffer, not directly from registers. It affects data that is loaded in bulk or to vector registers.
However, general purpose registers are also loaded passing through this buffer during context switches.
In modern CPUs registers are a high-level abstract concept (see register renaming), so writing to a register doesn't have any specific location to overwrite.
Recent Zenbleed vulnerability was an example of that — clearing of a register was setting a temporary boolean saying it's zeroed instead of writing actual zeros.
> [Q] Should other processor vendors and designers be concerned?
> [A] Other processors have shared SRAM memory inside the core, such as hardware register files and fill buffers. Manufacturers must design shared memory units with extra care to prevent data from leaking across different security domains and invest more in security validation and testing.
Not sure what to make of this wording. Thinly veiled threat? Hint that other embargoes are in place?
AMD had a similar vulnerability recently (Zenbleed) that used speculative evaluation misprediction to create an effective "use-after-free" bug that would reveal the contents of the internal SIMD register file https://lock.cmpxchg8b.com/zenbleed.html, that might be what is being referenced here.
Does anyone know what type of workloads this effects the performance of the most? Is this specialty-type of workloads or are general webserver/database/coding/compiling/gaming/desktop usages effected?
General caveats: are there many clouds that still run workloads from different users on the same physical core? I thought most had changed their schedulers years ago so you can't get cross-domain leaks between hyperthreads anymore. Claiming that it affects all users on the internet seems like a massive over-exaggeration, as he hasn't demonstrated any kind of browser based exploit and even if such a thing did exist, it'd affect only a tiny minority of targeted users, as AFAIK many years after the introduction of Spectre nobody has ever found a specex attack in the wild (or have they?)
I think the more interesting thing here is that it continues the long run of speculation bugs that always seem to be patchable in microcode. When this stuff first appeared there was the looming fear that we'd have to be regularly junking and replacing the physical chips en masse, but has that ever been necessary? AFAIK all of the bugs could be addressed via a mix of software and microcode changes, sometimes at the cost of some performance in some cases. But there's never been a bug that needed new physical silicon (except for the early versions of AMD SEV, which were genuinely jailbroken in unpatchable ways).
Yes, I think that's what I said? Every attack no matter how deep it seemed to be has been patchable in microcode, sometimes at a cost in performance. But so far nobody had to toss the physical silicon, at least not with Intel. The malleability of these chips is quite fascinating.
I think it was both. There were initial software only patches, but those were quickly superseded by microcode+kernel patches, where microcode added features the kernel enabled. IBRS or something like that.
On some Skylake CPUs to get full mitigations you are taking a 30% performance penalty _and_ you need to disable SMT which is often another double digit penalty. It's not a literal "toss the physical silicon", but it's getting there.
In fact my thesis is that it's never a literal "toss the physical silicon" because the kernel is able to take control when switching between tasks so (with help from the microcode) it's able to wipe all potential speculation vectors (at an arbitrarily expensive cost) before switching to the next task. This also explains why SMT is unfixably broken on some processors, since by design the kernel does not intervene in the task switching on the virtual cores.
What's interesting is that the FDIV bug from 1994 could also be worked around, but Intel recalled and wrote off those processors[1]. For their latest several problems, their response was more of a "sucks to be you". While they provided microcode updates and worked with OS vendors, there were performance impacts that materially affected the value of the chips.
The software workaround for the FDIV bug required the actual userspace software to be modified and recompiled. There was a decade of pre-existing software out there that would be hard to fix, especially in the days before most people had the internet.
There was nothing the OS could do to work around the bug, short of disabling the entire FPU and falling back to expensive software emulation of all floating point math.
The workarounds for all these speculation bugs can be mostly applied at the operating system and/or microcode level, and is comparably cheap.
> Claiming that it affects all users on the internet seems like a massive over-exaggeration, as he hasn't demonstrated any kind of browser based exploit and even if such a thing did exist
He's saying it likely affects "everyone on the Internet" because most servers are vulnerable.
> These are not the same thing. Afaik, most “vCPU” are hyperthreads, not physical cores.
OP didn't say otherwise. They are saying that public clouds do not let work from different tenants run on the same physical core (on different hyperthreads) at the same time.
This doesn't prevent you from selling 1 hyperthread as 1 vCPU, it just means there are some scheduling restrictions and your smallest instance type will probably have 2 vCPUs if you have SMT-2 hardware (and that's exactly what you see on AWS outside of the burstable instance types).
> General caveats: are there many clouds that still run workloads from different users on the same physical core? I thought most had changed their schedulers years ago so you can't get cross-domain leaks between hyperthreads anymore.
Isn't this the whole point of AWS' t instances? It's my understanding that they are "shared" at the core level, or else there wouldn't be a reason for the CPU credit balance thing.
They are definitely time-sliced among tenants and very possibly two tenants may run at the same time on two hardware threads on the same core: but you could have a viable burstable instance with time-slicing alone.
Nevermind, AWS explicitly documents that all instance types, including burstable, never co-locate different tenants on the same physical core at the same time:
It only seems to document that there's group scheduling for SMT cores. But that doesn't prevent issues due to switching between customers on the same physical core, no?
"It is possible, however, for two burstable performance EC2 instances to run sequentially (not simultaneously) on the same core. It is also possible for physical memory pages to be reused, remapped, and swapped in and out as virtual memory pages. However, even burstable instances never share the same core at the same time, and virtual memory pages are never shared across instances. "
I only started reading the paper - so I very well might be wrong here - but it doesn't look to me like you need victim/attacker to be scheduled simultaneously on two SMT threads, but that a single core sequentially executing victim / attacker code would be vulnerable. It's possible that the cross-customer "context switch" is larger than the the vulnerable window, but I'd not want to bet on it.
> But that doesn't prevent issues due to switching between customers on the same physical core, no?
Yes they are explicit that customers may be time-shared on a physical core ("burstable" instances don't really make sense without that). Most of these attacks aren't known to be possible in that scenario and in any case the mitigations are much easier since flushing sensitive state at group scheduling boundaries is much less costly than permanent dynamic changes to how concurrent SMT threads interact.
Yes, it's certainly easier to mitigate at a boundary that's already as costly as switching between VMs.
The paper documents that disabling SMT does not entirely mitigate the problem (In 9.1). They briefly mention trying instructions to avoid the microarchitectural leaks, but don't go into more detail than mentioning verw isn't sufficient.
They state that a switch to/from SGX, with SMT disabled, doesn't prevent the attacks. See 8.1. That's not the same as a cross-vm switch, but it's certainly interesting that the attempts at flushing microarchitectural state when exiting SGX don't provide protection.
Think of all the cloud resellers that are out there who really aren't segregating their tenants out or it's just a web shop with proxmox who recombined their own customers onto a core even though the cloud provider specifically segregated it
I think most if not all cloud VMs dedicate a core to you.
Well, there are some that share like the T series on AWS and I think other clouds have similar, but my bet is they can put in an extra "flush" between users to prevent cross tenant leakage.
Of course cross process leakage for a single tenant is an issue, in cloud or on prem, and folks will have to decide how much they trust the processes on their machine to not become evil...
This concern I also share and it's probably worth converting into layman's terms so that all computer users understand what it is. Basically the job scheduler Behavior in the OS needs to surface to the user with understandable language they can read so they can make the trade-off decision.
A lot of people on YC are enterprisey-brained and only think there are 3 possible clouds, and then there is the rest of the planet who can't afford to park their cash at AWS and set it on fire.
>are there many clouds that still run workloads from different users on the same physical core?
There are a vast number of VPS providers out there that aren’t AWS/GCP/Azure/etc where the answer is yes. Even the ones that sell ‘dedicated’ cores, which really just means unmetered cpu
What about burstable instances on AWS, and whatever is the equivalent in other clouds? Hard to imagine those having a dedicated core, would probably defeat the purpose.
My guess is there's likely less value in trying to target those kinds of environments... Just poking random data out of lambda or low end vps neighbors is a needle in a haystack the size of the moon in terms of finding anything useful.
It's more likely useful as part of a group of exploits to hit an individual, targeted system.
Per the paper, this looks like an attack against speculated instructions that modify the store forward buffer. The details aren't super clear, but that seems extremely unlikely to survive a context switch. In practice this is probably only an attack against hyperthread code running simultaneously on the same CPU, which I'd expect cloud hosts to have eliminated long ago.
Yeah, the way AWS has stock language like “AWS has designed and implemented its infrastructure with protections against this class of issues” supports the idea that you’re probably not getting anywhere with exploits of this class on a major cloud host any more.
Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it.
There are really only two common cases for this anyway. VMs and JavaScript.
For VMs we just need to give up on it. Dedicate specific cores to specific VMs or at least customers.
For JavaScript it’s a bit harder.
Either way, we need to not be giving up performance for the the normal case.
Agreed. Browsers are now nothing but an application platform of APIs (https://developer.mozilla.org/en-US/docs/Web/API). For some reason they still retain the vestigial HTML, CSS and JS, but really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API. Then we can finally ship apps to users without the shackles of how a browser wants to interpret and render some markup.
The idea of security "sandboxes" is quaint, but have been defeated pretty much since their inception. And the only reason we have "frontend developers" rather than just "developers" is HTML/CSS/JS/DOM/etc is a byzantine relic we refuse to let go of. Just let us deliver regular-old apps to users and control how they're displayed in regular programming languages. Let users can find any app in any online marketplace based on open standards.
IF GTK/Qt etc can render to canvas using WebGPU while compiled to assembly, I think game is almost over than too IF there's a way to lazy load application modules.
Think Autodesk products. Certain parts (wasm modules) only load when you hover over a menu while overall app loads within milliseconds because it just has the main window and such.
This has been possible for years. I actually got in the habit of porting my qt projects to the web target because they ran better than native compiled on some of my older machines.
That sounds awful. People would be jamming entire 10MB toolkits into WASM to do things that HTML could do, and performance would probably suffer.
HTML is declarative. The machine understands it. I like things machines can understand and optimize. Things that you can write automated tools to work with because it's not a full turing machine. If you want to make a screen reader, you can. If you want to reflow for mobile in a better way, you can, because you know what's text and what's an image.
Just giving people a programming environment and the ability to draw some pixels, the browser has no idea what the intent is. There's nothing to optimize unless the individual sites do, and I doubt they have Google and Mozilla's budget.
We already have too many unnecessary powerful imperative systems out there.
HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line.
It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform.
I'd rather we go the other way, and build the browser into the OS, so that desktop apps just serve a perfectly standard web server, with an API to launch a special OS client with slightly more native integration(Toolbar icons, closing the process when the browser closes, etc), to make native app dev easier and hopefully more popular.
Security sandboxes mostly work. People aren't constantly getting viruses from clicking the wrong link, at least not quite as much. They're not perfect, but they're better than having to completely trust 100 different sites unsandboxed, and they can be improved. I'd rather have crappy security than no security at all.
If by "highly standardized" you mean "you don't get a choice in what you can do or how it works", I agree.
Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads in 2022, generating billions in revenue. That's not a mistake or accident; that's a market filling a need.
If we really want an application platform that works everywhere, then let's stop dicking around with these stupid document hypertext viewers and build a real app platform that works everywhere.
> Native mobile apps thrive despite this magical web browser working everywhere
There’s also user behavior. Many users are conditioned to get software through the App Store. I’ve seen this be a driving factor for quite a few web native applications spinning up native dev teams and shipping native clients.
Many folks are surprised to see just how far you can push a browser app and how small the gap between web and browser has become for well built applications, including native-like things like Bluetooth, NFC, USB, etc. (see: https://youmightnotneedelectron.com/)
Have hacked with quite a few devs/companies that had a fully functioning offline capable web native application. The most requested feature they’d get? “I want to download it from the App Store.” (Usually in the form of “I can’t find your app in the App Store”)
I suspect this is why the PWA experience on mobile devices hasn’t been well paved and why some App Store policies call out “don’t just wrap a browser view in a native app” - they want to keep users coming in the front door of a marketplace where they collect a cut off the top of all transactions.
We really need to standardize "just wrapping a browser view". Why are we shipping a whole browser when we could be shipping a zip file of HTML with some metadata, and maybe a few tiny native helper utilities?
This is how PWAs work on smartphones. I recall coming across some electron alternatives that use the system webview and those are able to generate binaries hundreds of kilobytes in size. But you lose out on access to many of the modern APIs due to Safari there.
This is standardized for many years and called PWA. There are ways to interact with native helper utilities as well (simplest is just run http server on localhost), but not for mobile apps.
For mobile apps you can use webview component which will use system browser. You don't need to ship the entire browser (actually you can't even do that on iOS).
You are delusional and terribly out of your depth if you think even a sizable minority has any interest in getting rid of hypertext and the web. Networked native apps are useless without the web architecture as the glue to integrate between them. It is highly likely that URIs, HTTP and hyperlinks will still be a foundational elements of our technology world in a hundred years.
There are probably more website visits than that. People download games and bank apps and things like that, stuff they expect to use frequently, want fast access or offline ability, of they need hardware access.
There are still tons of things that don't need an app. Things that are inherently online and not accessed frequently work fine as sites.
The web doesn't limit what you can do that much, it limits how you can do it, which I think is a good thing. Less to break (Android API levels have the same effect) with fewer original lines of code. Less focus on clever and interesting code and more focus on UI and features (Although they try their best to reinvent the same js framework 1000 times).
A lot of the limitations are probably just Mozzilla hating anything that could be used for tracking, and not trusting users to manage permissions. The trend has been pretty strongly towards making the web very close to native apps, with all kinds of APIs.
Native apps fill a use case very well, that the web does not. That doesn't make the web obsolete.
> A lot of the limitations are probably just Mozzilla hating anything that could be used for tracking, and not trusting users to manage permissions.
Don't denigrate Mozilla for protecting users. There are a lot of privacy issues that can't be addressed by permissions models, Android serves as an example of that. Enumeration is not effective.
If Mozilla are standing in the way of invasive webpages, more power to them.
> really all you need is bytecode that calls an ABI, and a widget toolkit that talks to a rendering API
Browsers have a 2D renderer (canvas) and you can write your GUI code in C++, Rust, or whatever and compile it to WASM. Some widget toolkits for this even exist already. If this were a superior model it would have taken over by now? I guess you are after deeper integration with the desktop environment?
The challenge with toolkits confined to <canvas> rendering is their inability to effectively utilize the browser's integration with the OS. Key components like font rendering, input methods (including standard key shortcuts and behavior within input fields), selection handling, image decoding, network stack, native-like scrolling, and accessibility features need to be recreated from scratch. A web toolkit must use the DOM for optimal performance. (and therefore lower to HTML)
> In computer software, an application binary interface ( ABI) is an interface between two binary program modules. Often, one of these modules is a library or operating system facility, and the other is a program that is being run by a user.
But “regular old apps” don’t do all the same things.
The whole point of properly developing web apps is that html/css indicates a certain level of semantic understanding which allows for different interpretation in different contexts.
If you build a web app well, you build it to be a good experience on a computer for a power user with a huge screen and a keyboard for shortcuts, good for a user on a tiny touch screen, good for a blind person who doesn’t use a screen, and good for robots to parse and index. It should even be good for someone on an iPad with a mouse or a pencil which interprets the whole concept of the mouse differently from the desktop user’s mouse.
The agreed-upon semantics of HTML and the separation of visual styling into CSS is what allows you to take a step beyond just building an app and add a layer of “say what you mean” such that human and non-human users can re-interpret it into their own devices, use cases, and specific needs.
Web frontends are at their best when you don’t expect to perfectly control the end user experience, but try to convey the semantic meaning as perfectly as you can so it can be interpreted into good experiences even in situations where the display is wildly different than originally intended.
The mitigation here can incur a whopping 50% performance penalty. At what point can customers return these CPUs for either being defective or sue for false advertising? If they can't safely meet the target performance they shouldn't be doing these tricks at all.
Did processor companies ever advertise that processors guaranteed certain security properties of the software they execute?
Aren't system designers at fault for coming up with the idea of a context switch and assuming that we can trust a processor not to leak details across artificial software constructed boundaries?
> But wait, how is it even considered a processor bug ?
These side channel attacks allow an attacker to read registers from other processes before any context switching has occurred, or independently of any context switching (even if the OS has been written to correctly clear state).
AMD has the same problem (Inception). Predictive instruction pipelining makes timing and context separation harder. Even if you are on s390x or M1 it's not like you are safe either. This is a whole field of study.
In my mind the better mitigation is to put control over trusted code back to the user and to do that you have to add less-performant cores onto the die and force the operator to elevate (or not) to SMT.
Right now it's an all-or-nothing proposition for the whole board. I would like to think that you can take your untrusted code and stick it on the less-performy cores with the safer instruction pipelining scheme so an actual physical barrier exists.
If that was in the chip architecture, then it's up to OS vendors to surface it in a way that developers understand, and then down to the operator to decide upon configuration.
You are never going to get a perfect-solve from the chipmakers on this where the consumer has to do nothing.
The problem is that cycle-speed boosts left the industry cic. 2012-or-so. All the perf boost we get these days is by optimizing the instruction sequencing and multiprocessing. This is why languages like Go popped up (making the advanced programming topic of multiprogramming an entry-level accomplishment) and you now see the 'async' decorator plastered everywhere in C#, and so-on.
Keeping the security context intact and separated is a gargantuan task.
To me it makes more sense to add "lousy cores" to the die and force the operator to declare the launching threads are safe for SMT, else the job gets scheduled to the less-performing core where the pipelining is safer. It delegates responsibility to the chip-gobbler, forces them to understand the tradeoff for performance, until some elegant solution is found for side channel attacks like this.
> Did processor companies ever advertise that processors guaranteed certain security properties
It's not the guaranteed security as much as the advertised speed that's the issue. If they put out a chip which could only be used at half the advertised speed or else it would catch on fire, nobody would argue that they should be let off the hook because they didn't guarantee that the chips were fireproof in their ads.
If the chips can't perform at advertised speeds safely during typical use they're not delivering what was advertised.
Vulnerabilities are like unreliable cars. It doesn't matter so much if they can be fixed, it's the very, very high opportunity cost of needing to be fixed, when you were busy doing something else of high value.
Responsible people tend to pick the small consequence now over the unknowable distribution of consequences later.
> This is an unreasonable position. Vulnerabilities can be fixed
That's a highly optimistic position, to the point of being almost wishful thinking.
The vulnerability being talked about today has been around since 2014 according to the report. Possibly being exploited for unknown number of years since. Sure, maybe we can workaround this one, now.
Other similar ones to be published years into the future are also there today being likely exploited as we speak.
Running untrusted code on the same silicon as sensitive code (data), is unlikely to ever actually be truly safe.
The real problem here is the x86 architecture. We should stop using it. It's too complex, it's full of stuff made for backward compatibility purposes, it has too many instructions that may have unpredictable results, and for that exact reason it's extremely difficult to get things right. Somewhere in the thousands of instructions that it has you will surely find a bug.
We should move forward. Apple did a great job with the M{1,2} processors. Not only they are fantastic in terms of performance and energy usage, but also (to this moment) they don't seem to suffer from these issues. The reason is that the CPU is simpler, and a simpler thing is easy to design right in the first place.
Performance sorta hinges on it. It could be that the cheaper way the chipmakers deal with it is to phase out the 4core set and push the cores on a die higher, and to do that--incorporate an older core design into dedicated cores for untrusted code.
This would also require changes at the OS-makers to tag thread forks for trusted and untrusted behavior.
Essentially: instead of shutting down SMT for the entire machine, make the customer "prove" the code is safe for elevation or else it gets scheduled as non-SMT.
Even if we could say for sure that x86 has been disproportionately affected by speculative execution bugs (which already seems dubious), that could easily be due to a kind of selection bias. Presumably security researchers as a group more or less focus on the most popular and relevant ISAs/microarchitectures.
I've wondered if we can't give a dedicated core to the browser. Of course, then web pages can steal from other web pages. Maybe task switching needs to erect much higher barriers between security contexts, a complete flush or so?
It probably would be possible to add a new instruction that causes the processor to flush all state in exchange for sacrificing task switching speed. Of course it might still have bugs, but you could imagine that it would be easier to get right.
Of course, it’s not doing much for the billions of devices that exist.
I would hope that we could find a software solution that web browsers can implement so that devices can be patched.
Either way, I would want such a solution to not compromise performance in the case where code is running in the same security context.
This is what I don’t like about existing mitigations. It’s making computers slower in many contexts where they don’t need to be.
Software can choose to invalidate all cache, fence access, and the like today. It may not be a single instruction but it's not far off. Usually something like "just don't JIT 3rd party JS to native code" is "secure enough" most don't want to go down that route though. For cloud (reputable) providers just don't allow more than 1 VM to be assigned to a core at the same time and flush everything between if they are time shared. The mitigations are the way to keep the most overall performance outside those who are most concerned with maximum security, so they are the most popular.
I wish chips would come with a core devoted to running this kind of untrusted code; maybe they could take something like an old bonnell atom core, strip out the hyper threading, and run JavaScript on that.
If a script can’t run happily on a core like that, it should really be a program anyway, and I don’t want to run it.
I’m not saying you’re wrong, but I have a hard time believing web developers would be capable of writing code efficient enough to share a single core. LinkedIn was slamming my CPU so much that I isolated it in a separate browser
I think you are right, my wish involves living in a slightly different universe where the web has taken a slightly less silly direction of development.
Normally only one tab is in view at a time. Probably a bunch of use cases would hate this, but what if all background tabs just got very sparse time-share of a core and the foreground tab a dedicated core?
Vector is found to get untrusted code C to run in the user area on Z via exploit in X that Y has not acknowledged, so researchers publish a CVE with an example.
C starts trying to read memory from threads shared on same vCPU, revealing db connection string used by X, the nonce and salt for hashing.
It is sort of like the second law of thermodynamics (before statistical mechanics came around and cleared things up): sure, maybe not well founded in some analytical or philosophical sense, but experimentally bulletproof to the point where anyone who tries to sell you otherwise would be regarded very suspiciously. The idea that any two programs running on a computer can be prevented from snooping on each other.
> Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it.
Yes. This has had its heyday: the era of the time-shared systems, from the 1960's, right into the 1990's (Unix systems with multiple users having "shell accounts", at universities and ISP's and such). These CPU attacks show us that secure time-shared systems where users run arbitrary machine code is no longer feasible.
There will still be time sharing where users trust each other, like workers on the same projects accessing a build machine and whatnot.
Once you "dedicate cores to specific VMs" you will find that chip designers can also screw that up, just like they can screw up protection within a core. So you might as well proclaim that "impossible to get right" preemptively.
They said physical processor. I took this to mean chip. Of course you can't trust chips on the same mother board (there could be a bug where they can read the same memory), so you need a network boundary. So different rack on the server, for each [boundary, however you define that...]
A number of vexing CPU security vulnerabilities have resulted from a general class of optimizations that share cache resources (memory, TLBs, branch prediction tables, etc.) across different domains, which enables cross-domain attacks.
There is a potential for vulnerabilities even when the domains are separated by a network boundary ... if those domains view the world through some shared cache at the network layer.
There’s a marketing opportunity here to put multi-core back in the spotlight. Most workloads have reached the point of diminishing returns for adding more cores to a CPU, but if it turns out we need more cores just so we can run more concurrent processes (or browser tabs) securely, then here come the 128-core laptop chips…
From a user’s perspective I often think that applications which run multiple processes, demand multiple threads and large chunks of memory are too entitled.
I know it’s a (not even) half baked thought. But there’s something to that. We never really think of “how many resources is this application allowed to demand?”
Software would be orders of magnitudes faster if there was some standard, sensible way of giving applications fixed resource buckets.
Sacrifice IPC/core to reduce gates per core, stuff more cores into a square centimeter, pin processes to cores or groups of cores, keep thread preemption cheap, but let thread migration take as long as it takes.
Arm already has asymmetric multiprocessing, which I feel like is halfway there. Or maybe a third. Fifteen years ago asynchrony primitives weren’t what they are today. I think there’s more flexibility to design a core around current or emerging primitives instead of the old ways. And then there are kernel primitives like io_uring meant to reduce system call overhead, amortizing over multiple calls. If you split the difference, you could afford to allow individual calls to get several times more expensive, while juggling five or ten at once for the cost of two.
> Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it.
I believe this is why OpenBSD disabled SMT by default in June of 2018. [0]
It can still be enabled with a simple 'sysctl', though.
Do you really think that giving up on getting things done right is the way to progress computing? While AMD has it's own spectrum of problems and not-quite-there security features, most of their vulnyerabilities have been fixed in microcode shortly after disclosure.
We as an industry should stop excusing chipmakers from doing their jobs and reject broken products. It's brand loyalty all over again, like when Apple does something retarded like losing the headphone jack and the whole industry follows, breaking years of interoperability.
When the products/services we buy break, we should demand better, not lower our expectations.
I've wondered for a while whether it would make sense to split the CPU into a "IOPU" and a "SPU"
- The IOPU would be responsible for directing other hardware on the system. It doesn't need to be very performant.
- The SPU would be optimized for scalar and branch-heavy code that needs to run fast.
The SPU could have minimal security, just enough so it can't read arbitrary memory when fetching from RAM. It would only run one program at a time, so speculation shouldn't be an issue.
At least on my system few programs need a lot of processing power (and even then only intermittently), so little task switching should occur on an SPU.
This is one of many similar previous attacks, and more of these attacks will continue to come out and be increasingly weaponized. From now on the assumption must be that same-core computing is not secure.
I've only done a quick read through the link, but I think the model they imply is that a malicious user could rent a Cloud VM in AWS/Azure/GCP/etc and then sniff the contents of SIMD registers, similar to the Zenbleed attack which was also disclosed recently[1]. This is a big deal because optimized implementations of strcpy, strlen, and memcpy in glibc all use SIMD registers, and glibc is everywhere.
How do they know what data is in the registers? In the linked article, the person running the attack code knows what is running on the target. The target is also conveniently waiting for the attack code to run without doing anything other than referencing the target data.
I'm gonna get put on a list for typing this out but I'll clarify:
1. Bad guy creates cloud account and spawns 10 of the cheapest VMs across different data centers, let's say this costs a total of, what... $50 a month?
2. Bad guy reads this paper, and makes a program that frequently samples SIMD registers. Contents get dumped to stdout and then streamed over an encrypted line to a RAID array hosted in $COUNTRY_WITHOUT_US_EXTRADITION.
3. Bad guy writes program to sift through data dumps on RAID array for passwords, encryption keys, etc.
If you create a cloud instance right now that has an SSH login on port 22, you stream the SSH login logs and see a steady stream of attempted logins to your device. While the marginal cost of brute forcing SSH logins is free (no cloud VM needed) and my proposed scenario isn't, I think this is a very real scenario that needs monitoring.
A VM cloud provider can't block you from running at least one thread, which is all the malicious threads required for this attack.
However none of the big cloud providers share CPU cores between users to combat exactly this kind of thing. I really wish the people that did these disclosures were more up-front about this, instead of saying vague things like "frequently happens on modern-day computers". Though I guess you can assume that if an attack would work on AWS the researcher would definitely mention it, so the lack of such an explicit claim almost ensures the attack is not viable on major clouds.
AFAIK none of the cloud vendors run multiple customer's VMs at the same time on the same core; even the "shared-core" virtual machines don't share timeslices (AWS goes into detail about this here[1]).
I am a little unclear on the attack. What data in the temporal buffer is being forwarded to the attacking vpgather?
Is the content of the temporal buffer just being blindly forwarded during speculative execution even if the indexed address of the attacking vpgather does not match?
Otherwise how is the speculative vpgather allowed to load the values of the temporal buffer?
If it is not blind is it a virtual address match? I guess it could also be a not-Present mapping physical match as well? I can not think of any other possibility off the top of my head.
If it is a blind forward that is pretty amazingly bad.
In the victim process, the following instructions leak information towards the attacker (because they share internal hidden buffers with the gather instructions executed by the attacker) (the following are quoted from the paper):
• SIMD read. All SIMD operations that read wide data (128/256/512 bits) from memory are affected regardless of their function: e.g., vmov* only read, vpxor* read and compute the xor. These general-purpose instructions are used everywhere, e.g., compilers spread wide data reads to optimize memory access routines.
• SIMD write. The only SIMD write operations that are affected are the compress ((v)(vp)compress*) instructions.
• Cryptographic extensions. Cryptographic extensions, including AES-NI and SHA-NI (SHA1 and SHA256), when accepting a memory operand, are affected. Data leaks from these instructions expose plaintext data and the secret key, e.g., AES or HMAC-SHA.
• Fast memory copy. Fast memory copies of various data types: byte, word, dword, qword using rep movs* instructions are affected. These are widely used to speed up common memory operations such as memcpy and memove.
• Register context restore. Special instructions to more efficiently store/restore the register context (e.g., xsave/xrstor) are affected. GDS leaks the register context of both standard registers due to xsave/xrstor and wide registers due to fxsave/fxrstor.
• Direct store The direct store is affected. Intel has recently added support for a direct store instruction that can copy a 64 bytes cache line from a source to a destination address.
I do not doubt the severity of the flaw, but most practical attacks end up being far more mundane. Consider SolarWinds, for example. No dazzling tricks needed, whatever gets the job done.
Are state actors subject to different economics? Their budgets are finite, too. Why opt for a complex less reliable exploit if a simple more reliable one is available?
The OS job scheduler informs the CPU when it's ideal to swap jobs. But the OS is not doing the work of moving the register and stack pointers, the microcode is. These timing attacks take advantage of shared information in the cache (where it's likely the context of the thread you are not supposed to be able to read is).
SMT (hyperthreading) introduces some ambiguity when the context change is going to happen, and it appears there's instructions that are callable where registers/mem can be read that were outside the calling context.
The only 100% reliable way is to turn off branch prediction completely, and yes, this would make the processors at least 2 times slower, perhaps more.
Too bad that apparently nothing came out of the Mill architecture. My limited understanding is that this architecture would not have such vulnerabilities.
Of course it's possible it would have others :-) but being much simpler, at least conceptually, perhaps it would have less and easier to mitigate. Oh well.
Given the classic stack overflow branch predictor question, you are underselling things quite a lot - a factor of 6 on those older processors in question, and who knows on modern processors.
It seems to me like most don't have a fundamental gut feel for what speculative execution actually is and the implications of "not getting it". At some level we need to fight for performance. My operating systems are only getting slower and shittier. I cannot fathom my CPUs going backwards too. Security must take a back seat at some point. You can't put bubble wrap and warning labels over everything or it becomes useless. The most dangerous tools are typically the most effective.
The CPUs are vulnerable because of the exact way in which they are being applied to a problem. Speculative execution is not inherently unsafe. Whatever future predicted memory prefetching shenanigans are going on in my CPU over here have absolutely ZERO impact on your CPU over there. Certainly someone could figure out a protocol/system/architecture that capitalizes on this notion that "2 different CPUs are indeed different CPUs".
One can see how any perspective here still causes trouble for Amazon, Microsoft, et. al., but that was a business risk they signed up for the moment they intended to squeeze every last drop of subscriber revenue out of the hardware. Why should everyone else on earth have to suffer crappier performance by default because of the business/software practices of a select few?
> Why should everyone else on earth have to suffer crappier performance by default because of the business/software practices of a select few?
The author states in the article that they believe this may be exploitable from javascript in a browser. Just to hammer the point home, any web page could steal anything in memory on your computer. Spectre was also browser-exploitable, and was mitigated there partly by making access to high precision timers privileged. This is very much not a problem that only impacts cloud providers.
These vulnerabilities have a lot less to do with cloud providers, and a lot to do with networked computers in general. It's not unreasonable to expect this exploit to be done via web browser, as was demonstrated with prior speculative execution exploits.
Fundamentally, the only reason we need speculative execution is that we haven't updated our software to be more concurrent (reflecting how chips have kept pace with Moore's law for 15+ years), we still program as if we're in the 1970s.
This may turn into a great opportunity to force a rebuild a lot of ancient code.
Agreed, and I wonder if we'll see the adoption of "security hardened" CPUs which sacrifice performance features for non-exploitability. You can have one or the other, but not both.
348 comments
[ 2.9 ms ] story [ 72.5 ms ] threadThey word there are "some workloads", I suspect that performance hit is rare.
https://access.redhat.com/solutions/7027704
Performance Impact
The performance impact of the microcode mitigation is limited to applications that use the gather instructions provided by Intel Advanced Vector Extensions (AVX2 and AVX-512) and the CLWB instruction. Actual performance impact will depend on how heavily an application uses those instructions. Red Hat’s internal performance testing of a worst-case microbenchmark showed a significant slowdown. However, more realistic applications that utilize vector gathering showed only low single-digit percentage slowdowns.
If the user decides to disable the mitigation after doing a thorough risk analysis (for example the system isn’t multi-tenant and doesn’t execute untrusted code), the user can disable the mitigation. After applying the microcode and kernel updates, the user can disable the mitigation by adding gather_data_samping=off to the kernel command line.Alternatively, to disable all CPU speculative execution mitigations, including GDS, use mitigations=off.
I am always suspicious of "up to" claims.
So, in order to extract data, that data must be in constant active use (i.e. loaded in a register) at the time of the attack.
This is about as close to a total cross-process data leak as can be imagined.
Amazing how these vulnerabilities sit around unnoticed for years and then it takes two weeks for someone to code up an exploit.
I'm sure ARM64 isn't perfect but I've yet to learn of something as severe as this, or Spectre, or Meltdown.
ARM has suffered from Spectre too: https://developer.arm.com/Arm%20Security%20Center/Spectre-BH...
There was also PACMAN: https://appleinsider.com/articles/22/06/10/new-pacman-flaw-i...
Speculative vulnerabilities have virtually nothing to do with the instruction set. Changing the language of the processor has little to do with how the processor works under the hood, especially for fundamental technologies like speculative execution.
Also, as a corollary, speaking the same language doesn’t mean every vulnerability is shared. AMD does not seem affected by Downfall, for instance.
Contrary ARM or other RISC instruction set are more simple. Being more simple they rely on compilers being more smart to generate optimized programs (something we have to this day). For this processors are more simple and straight forward, they don't need all the complexity of an x86 CPU. For this reason they are also more efficient since they don't waste resources doing useless operations.
Of course vulnerabilities can be everywhere (there were a few also on M1, tough not as impressive like these one, they were mostly stuff nearly impossible to exploit|). But recent times proved that particularly on x86 chips this is a real issue.
[1] - https://lock.cmpxchg8b.com/zenbleed.html
[2] - https://comsec.ethz.ch/research/microarch/inception/
Edit: they released the fix today, I was mislead by the current tense "is releasing" in the OP.
Also many attacks are not really feasible to detect if it's happened - that's like trying to know if the mailman read your postcard.
You can develop executable scanning techniques, but people are a lot more concerned about preventing it in the first place than catching it in the act. Why would you leave people vulnerable so they can watch data get stolen - instead of just fixing the issue?
[Q] Is there a way to detect Downfall attacks?
[A] It is not easy. Downfall execution looks mostly like benign applications. Theoretically, one could develop a detection system that uses hardware performance counters to detect abnormal behaviors like exessive cache misses. However, off-the-shelf Antivirus software cannot detect this attack.
However, general purpose registers are also loaded passing through this buffer during context switches.
Recent Zenbleed vulnerability was an example of that — clearing of a register was setting a temporary boolean saying it's zeroed instead of writing actual zeros.
> [A] Other processors have shared SRAM memory inside the core, such as hardware register files and fill buffers. Manufacturers must design shared memory units with extra care to prevent data from leaking across different security domains and invest more in security validation and testing.
Not sure what to make of this wording. Thinly veiled threat? Hint that other embargoes are in place?
https://www.intel.com/content/www/us/en/developer/articles/t...
General caveats: are there many clouds that still run workloads from different users on the same physical core? I thought most had changed their schedulers years ago so you can't get cross-domain leaks between hyperthreads anymore. Claiming that it affects all users on the internet seems like a massive over-exaggeration, as he hasn't demonstrated any kind of browser based exploit and even if such a thing did exist, it'd affect only a tiny minority of targeted users, as AFAIK many years after the introduction of Spectre nobody has ever found a specex attack in the wild (or have they?)
I think the more interesting thing here is that it continues the long run of speculation bugs that always seem to be patchable in microcode. When this stuff first appeared there was the looming fear that we'd have to be regularly junking and replacing the physical chips en masse, but has that ever been necessary? AFAIK all of the bugs could be addressed via a mix of software and microcode changes, sometimes at the cost of some performance in some cases. But there's never been a bug that needed new physical silicon (except for the early versions of AMD SEV, which were genuinely jailbroken in unpatchable ways).
In fact my thesis is that it's never a literal "toss the physical silicon" because the kernel is able to take control when switching between tasks so (with help from the microcode) it's able to wipe all potential speculation vectors (at an arbitrarily expensive cost) before switching to the next task. This also explains why SMT is unfixably broken on some processors, since by design the kernel does not intervene in the task switching on the virtual cores.
1. https://www.intel.com/content/www/us/en/history/history-1994...
There was nothing the OS could do to work around the bug, short of disabling the entire FPU and falling back to expensive software emulation of all floating point math.
The workarounds for all these speculation bugs can be mostly applied at the operating system and/or microcode level, and is comparably cheap.
He's saying it likely affects "everyone on the Internet" because most servers are vulnerable.
These are not the same thing. Afaik, most “vCPU” are hyperthreads, not physical cores.
> I thought most had changed their schedulers years ago so you can't get cross-domain leaks between hyperthreads anymore
It would be great to have a source on this.
OP didn't say otherwise. They are saying that public clouds do not let work from different tenants run on the same physical core (on different hyperthreads) at the same time.
This doesn't prevent you from selling 1 hyperthread as 1 vCPU, it just means there are some scheduling restrictions and your smallest instance type will probably have 2 vCPUs if you have SMT-2 hardware (and that's exactly what you see on AWS outside of the burstable instance types).
Isn't this the whole point of AWS' t instances? It's my understanding that they are "shared" at the core level, or else there wouldn't be a reason for the CPU credit balance thing.
https://docs.aws.amazon.com/whitepapers/latest/security-desi...
"It is possible, however, for two burstable performance EC2 instances to run sequentially (not simultaneously) on the same core. It is also possible for physical memory pages to be reused, remapped, and swapped in and out as virtual memory pages. However, even burstable instances never share the same core at the same time, and virtual memory pages are never shared across instances. "
I only started reading the paper - so I very well might be wrong here - but it doesn't look to me like you need victim/attacker to be scheduled simultaneously on two SMT threads, but that a single core sequentially executing victim / attacker code would be vulnerable. It's possible that the cross-customer "context switch" is larger than the the vulnerable window, but I'd not want to bet on it.
Yes they are explicit that customers may be time-shared on a physical core ("burstable" instances don't really make sense without that). Most of these attacks aren't known to be possible in that scenario and in any case the mitigations are much easier since flushing sensitive state at group scheduling boundaries is much less costly than permanent dynamic changes to how concurrent SMT threads interact.
The paper documents that disabling SMT does not entirely mitigate the problem (In 9.1). They briefly mention trying instructions to avoid the microarchitectural leaks, but don't go into more detail than mentioning verw isn't sufficient.
They state that a switch to/from SGX, with SMT disabled, doesn't prevent the attacks. See 8.1. That's not the same as a cross-vm switch, but it's certainly interesting that the attempts at flushing microarchitectural state when exiting SGX don't provide protection.
Of course cross process leakage for a single tenant is an issue, in cloud or on prem, and folks will have to decide how much they trust the processes on their machine to not become evil...
A lot of people on YC are enterprisey-brained and only think there are 3 possible clouds, and then there is the rest of the planet who can't afford to park their cash at AWS and set it on fire.
There are a vast number of VPS providers out there that aren’t AWS/GCP/Azure/etc where the answer is yes. Even the ones that sell ‘dedicated’ cores, which really just means unmetered cpu
AWS Fargate, container as a service, allows specifying 0.25 or 0.5 CPU, and I would be surprised if those weren't shared.
Same probably? also applies to AWS Lambda.
It's more likely useful as part of a group of exploits to hit an individual, targeted system.
LLM's might change that. getting a firehouse of data and asking it to classify controls against NIST 53- rev5 produces interesting results.
There are really only two common cases for this anyway. VMs and JavaScript.
For VMs we just need to give up on it. Dedicate specific cores to specific VMs or at least customers.
For JavaScript it’s a bit harder.
Either way, we need to not be giving up performance for the the normal case.
"We should probably just stop doing it" works for me.
The idea of security "sandboxes" is quaint, but have been defeated pretty much since their inception. And the only reason we have "frontend developers" rather than just "developers" is HTML/CSS/JS/DOM/etc is a byzantine relic we refuse to let go of. Just let us deliver regular-old apps to users and control how they're displayed in regular programming languages. Let users can find any app in any online marketplace based on open standards.
Think Autodesk products. Certain parts (wasm modules) only load when you hover over a menu while overall app loads within milliseconds because it just has the main window and such.
HTML is declarative. The machine understands it. I like things machines can understand and optimize. Things that you can write automated tools to work with because it's not a full turing machine. If you want to make a screen reader, you can. If you want to reflow for mobile in a better way, you can, because you know what's text and what's an image.
Just giving people a programming environment and the ability to draw some pixels, the browser has no idea what the intent is. There's nothing to optimize unless the individual sites do, and I doubt they have Google and Mozilla's budget.
We already have too many unnecessary powerful imperative systems out there.
For example, picking up more elements of semantic web and distributed systems and leveraging interconnected devices.
It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform.
I'd rather we go the other way, and build the browser into the OS, so that desktop apps just serve a perfectly standard web server, with an API to launch a special OS client with slightly more native integration(Toolbar icons, closing the process when the browser closes, etc), to make native app dev easier and hopefully more popular.
Security sandboxes mostly work. People aren't constantly getting viruses from clicking the wrong link, at least not quite as much. They're not perfect, but they're better than having to completely trust 100 different sites unsandboxed, and they can be improved. I'd rather have crappy security than no security at all.
Native mobile apps thrive despite this magical web browser working everywhere, because the web browser simply doesn't do what native apps do. You may enjoy that, but a million businesses and billions of users out there don't agree, because they use native apps. There were 255 billion native mobile app downloads in 2022, generating billions in revenue. That's not a mistake or accident; that's a market filling a need.
If we really want an application platform that works everywhere, then let's stop dicking around with these stupid document hypertext viewers and build a real app platform that works everywhere.
There’s also user behavior. Many users are conditioned to get software through the App Store. I’ve seen this be a driving factor for quite a few web native applications spinning up native dev teams and shipping native clients.
Many folks are surprised to see just how far you can push a browser app and how small the gap between web and browser has become for well built applications, including native-like things like Bluetooth, NFC, USB, etc. (see: https://youmightnotneedelectron.com/)
Have hacked with quite a few devs/companies that had a fully functioning offline capable web native application. The most requested feature they’d get? “I want to download it from the App Store.” (Usually in the form of “I can’t find your app in the App Store”)
I suspect this is why the PWA experience on mobile devices hasn’t been well paved and why some App Store policies call out “don’t just wrap a browser view in a native app” - they want to keep users coming in the front door of a marketplace where they collect a cut off the top of all transactions.
For mobile apps you can use webview component which will use system browser. You don't need to ship the entire browser (actually you can't even do that on iOS).
But you're not allowed to for iOS: https://developer.apple.com/app-store/review/guidelines/#min...
There are still tons of things that don't need an app. Things that are inherently online and not accessed frequently work fine as sites.
The web doesn't limit what you can do that much, it limits how you can do it, which I think is a good thing. Less to break (Android API levels have the same effect) with fewer original lines of code. Less focus on clever and interesting code and more focus on UI and features (Although they try their best to reinvent the same js framework 1000 times).
A lot of the limitations are probably just Mozzilla hating anything that could be used for tracking, and not trusting users to manage permissions. The trend has been pretty strongly towards making the web very close to native apps, with all kinds of APIs.
Native apps fill a use case very well, that the web does not. That doesn't make the web obsolete.
Don't denigrate Mozilla for protecting users. There are a lot of privacy issues that can't be addressed by permissions models, Android serves as an example of that. Enumeration is not effective.
If Mozilla are standing in the way of invasive webpages, more power to them.
That is exactly what standardization means, by definition, both dictionary and colloquially.
This didn't work out that great with MSIE.
But it seems to have worked great for years for Chromebooks!
Browsers have a 2D renderer (canvas) and you can write your GUI code in C++, Rust, or whatever and compile it to WASM. Some widget toolkits for this even exist already. If this were a superior model it would have taken over by now? I guess you are after deeper integration with the desktop environment?
https://en.wikipedia.org/wiki/Application_binary_interface
The whole point of properly developing web apps is that html/css indicates a certain level of semantic understanding which allows for different interpretation in different contexts.
If you build a web app well, you build it to be a good experience on a computer for a power user with a huge screen and a keyboard for shortcuts, good for a user on a tiny touch screen, good for a blind person who doesn’t use a screen, and good for robots to parse and index. It should even be good for someone on an iPad with a mouse or a pencil which interprets the whole concept of the mouse differently from the desktop user’s mouse.
The agreed-upon semantics of HTML and the separation of visual styling into CSS is what allows you to take a step beyond just building an app and add a layer of “say what you mean” such that human and non-human users can re-interpret it into their own devices, use cases, and specific needs.
Web frontends are at their best when you don’t expect to perfectly control the end user experience, but try to convey the semantic meaning as perfectly as you can so it can be interpreted into good experiences even in situations where the display is wildly different than originally intended.
Aren't system designers at fault for coming up with the idea of a context switch and assuming that we can trust a processor not to leak details across artificial software constructed boundaries?
You write data inside the registers, yes, other processes can read these registers.
It always been like this, and is absolutely normal.
It's the responsibility of the operating system to clear the registers if it is switching context.
These side channel attacks allow an attacker to read registers from other processes before any context switching has occurred, or independently of any context switching (even if the OS has been written to correctly clear state).
In my mind the better mitigation is to put control over trusted code back to the user and to do that you have to add less-performant cores onto the die and force the operator to elevate (or not) to SMT.
Right now it's an all-or-nothing proposition for the whole board. I would like to think that you can take your untrusted code and stick it on the less-performy cores with the safer instruction pipelining scheme so an actual physical barrier exists.
If that was in the chip architecture, then it's up to OS vendors to surface it in a way that developers understand, and then down to the operator to decide upon configuration.
You are never going to get a perfect-solve from the chipmakers on this where the consumer has to do nothing.
Context switching was in the Apollo 11 guidance computer https://www.youtube.com/watch?v=xx7Lfh5SKUQ
The problem is that cycle-speed boosts left the industry cic. 2012-or-so. All the perf boost we get these days is by optimizing the instruction sequencing and multiprocessing. This is why languages like Go popped up (making the advanced programming topic of multiprogramming an entry-level accomplishment) and you now see the 'async' decorator plastered everywhere in C#, and so-on.
Keeping the security context intact and separated is a gargantuan task.
To me it makes more sense to add "lousy cores" to the die and force the operator to declare the launching threads are safe for SMT, else the job gets scheduled to the less-performing core where the pipelining is safer. It delegates responsibility to the chip-gobbler, forces them to understand the tradeoff for performance, until some elegant solution is found for side channel attacks like this.
It's not the guaranteed security as much as the advertised speed that's the issue. If they put out a chip which could only be used at half the advertised speed or else it would catch on fire, nobody would argue that they should be let off the hook because they didn't guarantee that the chips were fireproof in their ads.
If the chips can't perform at advertised speeds safely during typical use they're not delivering what was advertised.
Responsible people tend to pick the small consequence now over the unknowable distribution of consequences later.
Not always the damage.
That's a highly optimistic position, to the point of being almost wishful thinking.
The vulnerability being talked about today has been around since 2014 according to the report. Possibly being exploited for unknown number of years since. Sure, maybe we can workaround this one, now.
Other similar ones to be published years into the future are also there today being likely exploited as we speak.
Running untrusted code on the same silicon as sensitive code (data), is unlikely to ever actually be truly safe.
We should move forward. Apple did a great job with the M{1,2} processors. Not only they are fantastic in terms of performance and energy usage, but also (to this moment) they don't seem to suffer from these issues. The reason is that the CPU is simpler, and a simpler thing is easy to design right in the first place.
This would also require changes at the OS-makers to tag thread forks for trusted and untrusted behavior.
Essentially: instead of shutting down SMT for the entire machine, make the customer "prove" the code is safe for elevation or else it gets scheduled as non-SMT.
Yes. I did not mean to imply the real problem had a simple solution.
Even if we could say for sure that x86 has been disproportionately affected by speculative execution bugs (which already seems dubious), that could easily be due to a kind of selection bias. Presumably security researchers as a group more or less focus on the most popular and relevant ISAs/microarchitectures.
Of course, it’s not doing much for the billions of devices that exist.
I would hope that we could find a software solution that web browsers can implement so that devices can be patched.
Either way, I would want such a solution to not compromise performance in the case where code is running in the same security context.
This is what I don’t like about existing mitigations. It’s making computers slower in many contexts where they don’t need to be.
If a script can’t run happily on a core like that, it should really be a program anyway, and I don’t want to run it.
Partitioning tabs according to trust would be ~fine, but laborious and error-prone.
Vector is found to get untrusted code C to run in the user area on Z via exploit in X that Y has not acknowledged, so researchers publish a CVE with an example.
C starts trying to read memory from threads shared on same vCPU, revealing db connection string used by X, the nonce and salt for hashing.
Attacker now has the keys to the entire kingdom.
Yes. This has had its heyday: the era of the time-shared systems, from the 1960's, right into the 1990's (Unix systems with multiple users having "shell accounts", at universities and ISP's and such). These CPU attacks show us that secure time-shared systems where users run arbitrary machine code is no longer feasible.
There will still be time sharing where users trust each other, like workers on the same projects accessing a build machine and whatnot.
A number of vexing CPU security vulnerabilities have resulted from a general class of optimizations that share cache resources (memory, TLBs, branch prediction tables, etc.) across different domains, which enables cross-domain attacks.
There is a potential for vulnerabilities even when the domains are separated by a network boundary ... if those domains view the world through some shared cache at the network layer.
I know it’s a (not even) half baked thought. But there’s something to that. We never really think of “how many resources is this application allowed to demand?”
Software would be orders of magnitudes faster if there was some standard, sensible way of giving applications fixed resource buckets.
Sacrifice IPC/core to reduce gates per core, stuff more cores into a square centimeter, pin processes to cores or groups of cores, keep thread preemption cheap, but let thread migration take as long as it takes.
Arm already has asymmetric multiprocessing, which I feel like is halfway there. Or maybe a third. Fifteen years ago asynchrony primitives weren’t what they are today. I think there’s more flexibility to design a core around current or emerging primitives instead of the old ways. And then there are kernel primitives like io_uring meant to reduce system call overhead, amortizing over multiple calls. If you split the difference, you could afford to allow individual calls to get several times more expensive, while juggling five or ten at once for the cost of two.
I believe this is why OpenBSD disabled SMT by default in June of 2018. [0]
It can still be enabled with a simple 'sysctl', though.
[0] https://www.mail-archive.com/source-changes@openbsd.org/msg9...
We as an industry should stop excusing chipmakers from doing their jobs and reject broken products. It's brand loyalty all over again, like when Apple does something retarded like losing the headphone jack and the whole industry follows, breaking years of interoperability.
When the products/services we buy break, we should demand better, not lower our expectations.
- The IOPU would be responsible for directing other hardware on the system. It doesn't need to be very performant.
- The SPU would be optimized for scalar and branch-heavy code that needs to run fast.
The SPU could have minimal security, just enough so it can't read arbitrary memory when fetching from RAM. It would only run one program at a time, so speculation shouldn't be an issue.
At least on my system few programs need a lot of processing power (and even then only intermittently), so little task switching should occur on an SPU.
1: https://lock.cmpxchg8b.com/zenbleed.html
1. Bad guy creates cloud account and spawns 10 of the cheapest VMs across different data centers, let's say this costs a total of, what... $50 a month?
2. Bad guy reads this paper, and makes a program that frequently samples SIMD registers. Contents get dumped to stdout and then streamed over an encrypted line to a RAID array hosted in $COUNTRY_WITHOUT_US_EXTRADITION.
3. Bad guy writes program to sift through data dumps on RAID array for passwords, encryption keys, etc.
If you create a cloud instance right now that has an SSH login on port 22, you stream the SSH login logs and see a steady stream of attempted logins to your device. While the marginal cost of brute forcing SSH logins is free (no cloud VM needed) and my proposed scenario isn't, I think this is a very real scenario that needs monitoring.
And can‘t the cloud provider simply block access to the cpu api? Like they don’t allow you to create your own threads?
Just trying to understand this.
However none of the big cloud providers share CPU cores between users to combat exactly this kind of thing. I really wish the people that did these disclosures were more up-front about this, instead of saying vague things like "frequently happens on modern-day computers". Though I guess you can assume that if an attack would work on AWS the researcher would definitely mention it, so the lack of such an explicit claim almost ensures the attack is not viable on major clouds.
[1]: https://docs.aws.amazon.com/whitepapers/latest/security-desi...
Is the content of the temporal buffer just being blindly forwarded during speculative execution even if the indexed address of the attacking vpgather does not match?
Otherwise how is the speculative vpgather allowed to load the values of the temporal buffer?
If it is not blind is it a virtual address match? I guess it could also be a not-Present mapping physical match as well? I can not think of any other possibility off the top of my head.
If it is a blind forward that is pretty amazingly bad.
• SIMD read. All SIMD operations that read wide data (128/256/512 bits) from memory are affected regardless of their function: e.g., vmov* only read, vpxor* read and compute the xor. These general-purpose instructions are used everywhere, e.g., compilers spread wide data reads to optimize memory access routines.
• SIMD write. The only SIMD write operations that are affected are the compress ((v)(vp)compress*) instructions.
• Cryptographic extensions. Cryptographic extensions, including AES-NI and SHA-NI (SHA1 and SHA256), when accepting a memory operand, are affected. Data leaks from these instructions expose plaintext data and the secret key, e.g., AES or HMAC-SHA.
• Fast memory copy. Fast memory copies of various data types: byte, word, dword, qword using rep movs* instructions are affected. These are widely used to speed up common memory operations such as memcpy and memove.
• Register context restore. Special instructions to more efficiently store/restore the register context (e.g., xsave/xrstor) are affected. GDS leaks the register context of both standard registers due to xsave/xrstor and wide registers due to fxsave/fxrstor.
• Direct store The direct store is affected. Intel has recently added support for a direct store instruction that can copy a 64 bytes cache line from a source to a destination address.
Linux Kernel merge: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
SMT (hyperthreading) introduces some ambiguity when the context change is going to happen, and it appears there's instructions that are callable where registers/mem can be read that were outside the calling context.
Too bad that apparently nothing came out of the Mill architecture. My limited understanding is that this architecture would not have such vulnerabilities.
Of course it's possible it would have others :-) but being much simpler, at least conceptually, perhaps it would have less and easier to mitigate. Oh well.
https://stackoverflow.com/questions/11227809/why-is-processi...
The CPUs are vulnerable because of the exact way in which they are being applied to a problem. Speculative execution is not inherently unsafe. Whatever future predicted memory prefetching shenanigans are going on in my CPU over here have absolutely ZERO impact on your CPU over there. Certainly someone could figure out a protocol/system/architecture that capitalizes on this notion that "2 different CPUs are indeed different CPUs".
One can see how any perspective here still causes trouble for Amazon, Microsoft, et. al., but that was a business risk they signed up for the moment they intended to squeeze every last drop of subscriber revenue out of the hardware. Why should everyone else on earth have to suffer crappier performance by default because of the business/software practices of a select few?
You could hijack a user that has SAPGUI open, then push code updates to SE38 that spread everywhere.
Fundamentally, the only reason we need speculative execution is that we haven't updated our software to be more concurrent (reflecting how chips have kept pace with Moore's law for 15+ years), we still program as if we're in the 1970s.
This may turn into a great opportunity to force a rebuild a lot of ancient code.
For more information: C is not a Low Level Language https://queue.acm.org/detail.cfm?id=3212479
EDIT: Maybe not? That linked table is very esoteric.