I love that this is a toggle like this, having control of my system is why I love Linux.
But I must caution desktop users against doing this for performance, it's _much_ better to have some kind of build server somewhere else with this kernel flag than to run it on your desktop.
Why? because your desktop executes untrusted and rather arbitrary code pretty often, not just in the form of Javascript but that's the largest example I can think of.
Right now there's a kind of herd immunity for these things, nobody would really attack spectre because everyone is running mitigations, but if you make the target large enough there will be working exploits.
For isolated machines running trusted workloads (thinking: databases or webservers serving static content) then it's a really nice flag to have on-hand.
I'd like some more technical details on what exactly InSpectre does (specifically for the Meltdown patch). e.g. Does it just flip a registry key? Rewrite a microcode patch somewhere? Couldn't find an explanation in the software (even under Show Tech Details) or on their site; could you point me to it?
Also, do all the major browsers now have their own mitigations built in?
Answering my own Question #1: Looks like it sets values for FeatureSettingsOverride and FeatureSettingsOverrideMask under the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" registry key.
FeatureSettingsOverride is a bit field where bit 0 controls the mitigation for CVE-2017-5715 (Spectre) and bit 1 controls it for CVE-2017-5754 (Meltdown). If the bit value is 0 the corresponding mitigation is enabled, if 1 it's disabled. FeatureSettingsOverrideMask is simply a mask to control which bits of FeatureSettingsOverride to apply. So, for example, FeatureSettingsOverride = 2 and FeatureSettingsOverrideMask = 3 would enable the Spectre mitigation (if available) and disable the Meltdown one.
For anyone considering whether to disable these for desktop performance, I tried to do some research on how much it helps, at least for my workload. From what I was able to read, for gaming, the performance differences are negligible. There also seems to be some indication that disabling mitigations is also harmful to performance on more recent CPUs, since more and more of the mitigations are being baked into the silicon.
>desktop executes untrusted and rather arbitrary code pretty often
Aren’t the most affected group of users cloud users (and providers), not desktop users? I thought the biggest risk of specter attacks is the ability to glean information on other server residents who should be segmented off. There are many more concerns in user space which make attacking a desktop with specter pretty cumbersome for low reward wrt opportunity cost.
The performance savings of speculative execution do seem to be worth the risk on a desktop IMO.
I was under the impression that spectre is is much more limited in scope than Meltdown. I think you have to be in a position to influence the execution of the program you are trying to extract information from. Like JavaScript engines running in browsers. One example is your JS can be used to get the browser to speculatively execute something that leaks data. I think that it’d be pretty hard for one VM to set up a spectre attack on another arbitrary VM. Meltdown however does expose everything.
At least on AWS EC2, malicious neighbors won't be an issue. "This issue has been addressed for AWS hypervisors, and no instance can read the memory of another instance, nor can any instance read AWS hypervisor memory. We have not observed meaningful performance impact for the overwhelming majority of EC2 workloads."[1]
Phoronix has comprehensive benchmarks on the impact of spectre mitigations if you want to find out how much of a difference it will actually make before exposing your system:
I don't want to go into this topic because frontend developers are very defensive of their capability to Javascript on people, they often cite javascript adoption numbers as proof that it's fine to make it mandatory or cite complex web applications as a reason for it to be mandatory for all sites, which I personally find to be a false dichotomy.
I tend to agree with what you're saying but the ship has sailed very much and running without javascript is a losing proposition these days.
(my web browser starts up with javascript disabled except for some whitelisted sites and it usually only takes 15 minutes for me to find something completely broken on the internet and re-enable javascript entirely).
/second NoScript. Instead of whitelisting whole sites, you can whitelist links to JavaScript imports across all sites, temporarily or permanently.
So for example, you can whitelist urls to all the major JavaScript frontend frameworks’ CDNs, like bootstrap, etc. while leaving known trackers and spyware blacklisted by default.
Anecdotally it seems most websites still work with their trackers disabled, as long as they have their frontend framework/s loaded.
I disagree. There are way too many sites that require javascript that you'll eventually get into the habit of blindly enabling scripts when a site breaks, negating any security benefits.
I disagree. I'm not just pulling this out of my ass, I've been doing exactly this for years, I can't remember how long. It works fine.
>you'll eventually get into the habit of blindly enabling scripts when a site breaks, negating any security benefits.
The key here is that when you're deciding whether to whitelist a JS import, and you don't know what it is and don't want to take the time to look it up, then whitelist it temporarily not permanently. It will be moved back to the blacklist the next time you restart the browser.
Only permanently whitelist JS that you know for sure isn't a tracker or malware or sketchy.
> Only permanently whitelist JS that you know for sure isn't a tracker or malware or sketchy.
What’s the whitelist based on? URI? Or file content hash? Because today’s “criticalsitefunctunality.js” is tomorrow’s “upstream got p0wned and there’s a Bitcoin miner in there too now”.
Sites churn so often that “permanently” whitelisting hashes is probably a never ending chore, and you’re unlikely to want to constantly re-inspect minimized JS, so this eventually turns into semi-blind faith.
And permanently whitelisting URIs is pure security theatre; that file could contain anything, next request.
I'm aware of all that, but it's not theater, it's just part of a defense in depth strategy. Reduces attack surface area, doesn't eliminate it, while maintaining usability of the web.
If you have a better approach that accomplishes both of those objectives, do tell.
I'm sure it adds some amount of security. I'm just skeptical it adds enough security to be worth the hassle. I discussed the threat model here: https://news.ycombinator.com/item?id=27564457 and came to the conclusion that it wouldn't prevent much attacks in practice.
> If you have a better approach that accomplishes both of those objectives, do tell.
Use a browser that isolates the JS engine in its own process and leave spectre mitigations enabled rather than try to play kid-plugging-holes-in-dike-with-finger by auditing all the world’s constantly-changing JS for spectre/meltdown gadgets?
>Use a browser that isolates the JS engine in its own process
Definitely. All for that.
>and leave spectre mitigations enabled
I do that anyway. The performance cost is unnoticeable to my normal workloads.
>rather than try to play kid-plugging-holes-in-dike-with-finger by auditing all the world’s constantly-changing JS for spectre/meltdown gadgets?
I'll continue doing this too, largely because I want to see what's going on behind the scenes on all the websites I visit. Useful for me to see it all, especially as it changes over time as you observe.
That said, Easylist and Privacylist are also great if you'd rather crowd-source the finger-in-dike-hole-plugging.
I used to do this. It broke too often when doing credit card purchases though... it would take multiple attempts to complete a purchase and figure out which domains needed to be enabled. Sometimes the status would be left ambiguous. Once I double-spent, but fortunately it was a cancellable reservation. I suppose you can do better if you just spend at a few key sites.
I do it with uMatrix. I usually go up to the "all sites" level and enable most everything before going through a credit card payment flow, for this reason.
Security is only part of my motivation, though, and not the main part -- I mostly do it because it protects me by default from all the pop-up type crap that so many websites foist on you. Yes, it's a pain to un-break sites sometimes. But I resent it less than going through the equivalent pain in "privacy settings" popups, wriggling chat widgets, "ate you sure you don't want to sign up for our newsletter?" nags, etc. Websites are already broken; as long as that's true, I'd rather be in control of why.
>it would take multiple attempts to complete a purchase and figure out which domains needed to be enabled.
Yeah I went through this too, figuring out all the CC purchase redirects. Some are just idiotic to the point I wish govts would pass a law mandating zero redirects for online purchases. Stripe, Paypal, Square, Braintree and a few others do payments just fine without the redirects so it's clearly possible.
But eventually even that gets solved and the redirects get whitelisted. Haven't encountered this problem for a long time.
I have used NoScript for over a decade and I've been bitten by this too, but I've noticed that it has gotten better. CC processors seem to have encountered enough crappy browsers and broken JS implimentations that they've improved their services in the last half dozen years or so.
That said, when there's something old, important, and/or dumb looking, I usually spawn a new Firefox container (using Multi-Account Container plugin) and use NoScript's temporary bypass function.
You probably misunderstood : allmost all websites require javascript, yes - but you can selectivly allow only the javascript of that site, their framework etc. and block all the tracker/ads javascript with NoScript/UBlock - and then it is working and probably quite safe. But to mitigate, more and more websites find ways to sneak in the tracker/ads/analytics into the main sites js. So it is not as easy, either.
Which is why I just use basic ublock origin and regulary wipe the browser cache.
>but you can selectivly allow only the javascript of that site, their framework etc. and block all the tracker/ads javascript with NoScript/UBlock
What's the difference between that and just using the standard easylist/easyprivacy filter? I suppose there's a small chance that a third party site went rogue and isn't on the default lists, but I'm skeptical how many attacks that would thrawt in reality. The attacks I heard of tend to be first party/supply chain (would be white listed by you), or delivered through an ad network (probably already be on a blacklist).
Easylist and Privacylist are great. I suppose the main reasons for doing it manually are seeing firsthand what all the sites you visit are doing behind the scenes, and getting a sense of what is legitimately needed functionality, what isn't, and what is just downright sketchy.
I feel that is a bit like driving blindfolded because you might get distracted at some point anyway. Sure that one script you have to enable might be the one to exploit your system, but it might also be one of the dozens that didn't do anything useful.
So what happens if you go to a site and see a blank/broken page? Do you just go back and abandon the page? Do you do a full risk assessment of each of the domains? What does that assessment entail?
First I curse JavaScript developers (sorry). Then I use a heuristic like is this a real website for a real thing that I heard of before today, then temp trust; if it’s click baity or new, don’t trust or try adding in one at a time or mostly just give up. Very little shortage of content.
Depends. Sometimes I leave immediately, other times that blank is just a cover on top of content. And finally, I sometimes have to enable a domain/subdomain using common sense.
It's not that hard, nor time consuming. Again, my wife can do it and she's not a developer.
Still though. There are sites that would not work at all until everything is enabled, including ads. Imagine not being able to buy a plane ticket because wizzair wants to serve you ads
I use a browser called Qutebrowser which doesn't have a noscript addon; but I can disable javascript loading on a domain level.
However, overall I can tell you for absolute certain: if you have JS partially disabled things break in non-obvious ways and I find myself playing whack-a-mole with allowing various domains to load javascript to get the page working.
I'm pretty certain you do also, because it's basically impossible to tell why certain damned sites are broken and the most obvious thing to do is just enable JS temporarily to see if it works at all.
This is especially annoying on some part of a site such as checkout- where reloading the page causes a form resubmission.
If the actual payment is via Paypal I think it usually works without JavaScript in the merchant. And like content, there is no shortage of places to buy stuff.
For banking i use their phone app or else visit them in person. But I use a credit union not a bank as I want to trust the people holding my money.
idk about this, my anecdotal experience suggests otherwise - irrelevant things (i.e., monitor resolutions, mouse acceleration curves, and I think DNS settings at one point) can be thrown around by updates a bit too frequently in my experience.
I have a tablet that was unusable before I installed WuMgr and blocked auto-updates because every 24 hours Windows Update would force-install a broken touchscreen driver. Windows Update is the single most embarrassing, half-assed software project of the 21st century.
And teams. And all that software that you used to be able to use that you have to make exceptions for so that in the end you end up forgetting to re-enable some critical part of the windows scareware implementation.
Seriously: try installing Firefox on Windows 10 (I had to do this recently, I have now one computer in the house on Win 10 due to a hard requirement for some software/hardware combo), and you'll see Microsoft learned next to nothing from the browser wars lawsuit. They're simply asking to have this done to them again, they now actively discourage Firefox to be installed by claiming it can 'damage your computer' and is insecure. Incredible this stuff.
Oh, and Google will return a link for Chrome as the first item when you search for Adblock for Firefox. You can't make this stuff up.
Has there ever been a large company in IT that didn't turn absolutely evil as soon as the opportunity presented itself?
> You never sent me a response on the question of what things an app would do that would make it run with MS-DOS and not run with DR-DOS. Is there [a] feature they have that might get in our way?
Bill Gates
> What the [user] is supposed to do is feel uncomfortable, and when he has bugs, suspect that the problem is DR-DOS and then go out to buy MS-DOS.
MS SVP Brad silverberg
> If you're going to kill someone there isn't much reason to get all worked up about it and angry. Any discussions beforehand are a waste of time. We need to smile at Novell while we pull the trigger.
MS VP Jim alchin
What has changed? Nothing, of course. Settling and paying fines for blatant abuses of dominant market positions has been Microsoft’s MO for decades.
The behaviors described here are intrinsic to capitalism, and are not peculiar to any individual company. The executives quoted here are simply describing the waters they swim in. But they are only one fish in the sea that is liberal governance. The system is the problem, not Microsoft.
This system will cause any publicly traded company to behave like a sociopath and limit career paths for non-sociopaths who are unwilling to break (or bend) the law to further their agendas.
I run Windows 10 (Home) since years and the OS has so far, never tried to warn me about Firefox. It does however reset default browser back to Edge after biannual major OS upgrades. Also searching 'adblock for Firefox' on Google returns several results from Mozilla addons for me. Chrome is not linked anywhere on the first page of results.
What is personally more annoying is Edge keeps randomly popping up a banner asking if I'm sure it shouldn't be the default browser. When a user declines once, the OS shouldn't nag repeatedly.
"When a user declines once, the OS shouldn't nag repeatedly. "
Haha, ... when you apply that standard to the modern world - you sometimed wish the stoneage back.
Seriously, there is something deeply wrong with society, when all this shit just gets accepted by everyone.
"Telemetry" such a innocent word. If they would write we record allmost everything you do on your computer and send that data to wherever we want to .. I doubt much would actually change, as MS office software is still mandatory in many places, but maybe there would be more awareness of it.
Give it time; it's a trickle campaign. Just this morning I updated my Win 10 Pro desktop, and on reboot I got a full screen wizard prompting me to "use recommended browser settings" which is doublespeak for changing my default browser to Edge.
The SmartScreen stuff is a plague that applies to all software developers in varying degrees. Chrome does this with their safe browsing stuff too, I hate it - essentially everyone gets told your exe is "malicious" until enough people have downloaded it without it being flagged as malware.
The idea that it applies to trusted vendors like Mozilla shipping code-signed executables is bonkers to me.
Nice way to promote further centralization into services like app stores that don't suffer from this!
> Give it time; it's a trickle campaign. Just this morning I updated my Win 10 Pro desktop, and on reboot I got a full screen wizard prompting me to "use recommended browser settings" which is doublespeak for changing my default browser to Edge.
Yeah, I actually think this is a case of "don't explain by malice that which could be adequately explained by stupidity" or something.
I'm only a casual Windows user (only use for it games) and never bother to install another browser, Edge works well enough to download Steam and occasionally look up something on the internet.
Earlier this week when it installed the new update I also got the same "use recommended browser settings" dialog box. I think I had disabled 3rd party cookies or something as well as the random junk on the new page, so not willing to click around for half an hour I denied using anything and all went well. I'm pretty sure this isn't the first time I see the "use recommended settings" on this PC, since seeing it gave me an "again?!" reaction.
This is a Win10 Pro that's always been kept up to date.
I alos think it's less productive to interpret the phrase absolute evil as a comment on an entity's moral alignments (because it's a corporation, it's not chaotic evil or neutral good, it just is) but as a comment on the foundation and effects of the economic and political systems defining of the corporations (capitalism under neoliberalism). Absolute evil seems like a fairly decent personification of those metrics to me: every extra push to manufacture another product pushes us closer to a climate catastrophe (even 'green' products like Teslas, especially green products like Teslas[1]). Even if you deny climate change, you can't deny that workers are being taken advantage of near habitually. If we're going to personify the destruction of the earth and the worker, absolute evil does not seem too far off.
There is still a big difference, between exploiting people - and owning people - and literal doing what you want with them. Flock them. Burn them. Rape them - as you please. This is slavery as it used to be (and partly still is!!). And that term gets watered down when applied to something else.
Exploiting people because they are desperate is a big problem. Maybe call it modern day slavery. But it really is not the same as what slavery means for people who are literaly and 100% owned by others.
> Microsoft learned next to nothing from the browser wars lawsuit.
That's been true since the very beginning.
I very nearly filed papers to oppose class council in one of the state lawsuits on the basis that the proposed settlement was calculated to create a new antitrust injury to the class.
But I didn't because I was young and pro se and there was no way for me to afford or find representation. If I had to do it again I would've filed pro se requesting that they reject the settlement on that basis and appoint a guardian ad litem to roll the dice anyway.
Seriously. I hate zoom, there are so many features that smell like malware (how when a call starts sometimes my system level volume no longer is controllable and I have to go to zoom settings to control it. I have windows+wsl, but it's happened on macs in my company as well). Google gets a lot of hate, but I like their meeting tool because they keep it simple and it works.
I just changed company. Wish I could go back to Zoom. Google Meet is horrible. I have to open Chrome for all meetings, as it (probably intentionally) runs worse in other browsers. But even in Chrome there are issues. Some workloads (like running tests) can take 5x as long on my system if I'm sharing my screen on Meet. Making working with others more hassle than it should be.
This is fair, but at least you're sure that when you close the window that it's gone and that is as far as I'm concerned its biggest feature. Oh, and that it seems to work well on all platforms.
“Close browser tab” - immediately exits a Google Meet.
Closing a Zoom/Webex meeting, who knows since it’s still running in the background.
I also like meetings sandboxed in a browser so weird things like “automatically take control of your screen and maximize window” doesn’t happen when someone in a Zoom meeting starts sharing their screen.
That meme with the actor taking to a bloodied Jesus comes to mind while reading you guys comparing google with zoom. You guys are so lucky. I work on Skype for Business over a Citrix Workspace connection.
While Skype is an unmitigated disaster that can’t do simple stuff like copying text there is Citrix that requires a wizard installer with admin rights that deploys 3 background services and requires an audio plugin (separated, with another wizard installer) to do a worse remote streaming experience than what discord does for teenagers using a browser.
The inability to copy text may be due to an admin setting. At my previous workplace they disabled the ability to paste in images, etc. into Skype for Business saying that it was a security risk. They also disabled the ability to copy and paste between apps except within MS Office for the same reason.
It's not Citrix doing this, but your administrator.
Copy and paste works. They did disabled any communication between the client machine and the Citrix VDI except for audio and camera but the feature I'm complaining about is within the Remote Desktop. It works but its random and terrible. Sometimes you try to copy a single word but it copies the entire message along with the metadata containing sender and timestamp.
Since you are on Skype for Business I'm going to assume you are not using Teams currently. Teams is actually a lot worse in almost every way than SfB when it comes to the functions both systems share.
> While Skype is an unmitigated disaster that can’t do simple stuff like copying text
Do you mean from shared contents or from the chat? The latter works for me, but since you also mention using Citrix Workspace, which sounds like a remote desktop/application tool, it seems likely to me that this is actually the fault of Citrix, not Skype. Remote clipboards seem to be rather unreliable, I'm using DCV 2017 and the clipboard breaks basically every five minutes, necessitating a reconnect.
Sometimes you copy what you want sometimes you copy the message with the metadata and sometimes copy doesn’t work. Pasting stuff from other sources will cause some weird table elements to appear. There is no way to format code. Sometimes it says the message is too big but then you paste the same message into notepad and copy paste again it works just fine. The text editor and visualization seems to be arctifacts of a bygone era where everything was rich text.
I’m not sure if it’s the clipboard because my employer does not allow shared drives, clipboard, usb or any resource from my local machine except for mic and webcam.
Ohhh and let’s talk abou the HUGE black ribbon at the top of the screen when you are sharing your window. It totally covers the browser tabs. You have to restore the window and switch tabs and maximize it again. It _is_ an unmitigated disaster that degrades the overall experience.
Meet isn't much integrated into Chrome, so absent a Chrome bug, closing Meet stops running Meet code, so stops the meeting. “Closing” Zoom relies on Zoom detecting the closure and stopping the meeting.
It's not about spying from the software authors (having these softwares on your computer makes that impossible to defend against), but about knowing whether the people you were just talking to still have access to your camera and microphone feeds.
There has never been a webmeeting software that people didn't bitch about constantly. They all suck, because, fundamentally, what they are trying to accomplish sucks. Nobody wants to do audio/video meetings, we just suffer through them because we have to.
We had Zoom at our workplace for longer than most people knew what it was and I still have not installed it on my own PC. If I don't need to have myself on video, I run zoom on the work machine I'm remoted into and use my phone for the audio. If I need to use video, I use the application installed on my iPad since I trust that it's even more sandboxed than my Android device. I would rather not have the application installed on any of my personal devices, but that's the closest I can get when it comes to keeping Zoom away from my stuff.
Huh. I had this happen on Linux, too. I chalked it up to PulseAudio getting lost with my multiple sound cards and connecting / disconnecting peripherals.
> I love that this is a toggle like this, having control of my system is why I love Linux.
The need to keep telling this loud and clear for the manufacturers to hear is more needed now than ever since computers are becoming closed systems like smartphones and Manufacturers are claiming 'Customers not having to make hard decisions' to do so.
Kind of feels like apps should opt in to (or out of) mitigations individually. Obviously a web browser needs it, but does Clang? VSCode? Zoom? Probably not.
1) we can’t trust people to categorise their own apps because the incentive for performance over security is a trade off we’ve all made time and time again.
2) efforts to address mandatory access controls have a coloured history here: selinux and apparmor both have very low adoption rates no matter your personal anecdotes.
3) These mitigation’s are so thorough that it would be more expensive on performance to even _check_ per application than it would be just to enable it everywhere.
Yeah that should be really fast, still. Programs could also opt to just tell the OS "hey don't check this system call from me", on each system call, avoiding any lookup.
The impact of TLB flushing, not just the cost of the flush, is really significant - it's going to take a lot of work to be as expensive within the syscall path.
Nothing, but that only makes reading the malware's memory possible with these exploits. That malware won't be able to access memory of some other process, if that other process is using those flags itself.
Edit: For that to work that flag would have to work on the context switch level. So every time you switch away from a sensitive process, flush all buffers and whatever else, then switch.
This also requires the kernel itself to enable mitigations as necessary when it touches encryption keys before switching back to user space.
It's worth noting that mitigations=off doesn't even restore all the performance, compared to kernel versions before Spectre mitigations were added at all.
mitigations=off can only "patch out" some expensive instructions in the syscall path, or sometimes take a different path entirely, but it can't go back to the simple code before this was added in the first place. It also can't undo effects of compiler flags like -mindirect-branch which change the compiled code.
I haven't tested it recently, but when I looked at this more than a year ago, the numbers for a simple syscall (which doesn't do much work beyond the syscall mechanics itself) were something like 130ns, 250ns, 700ns for a "pre mitigation kernel", "new kernel with mitigations=off" and "new kernel with mitigations=on".
Some of the numbers have improved since then as better mitigations have been found, and/or improved CPU support for mitigations via microcode updates.
has there been any research on what hardware changes would be necessary to reclaim performance? I've noticed extreme stutter events on desktop OSX for the last 2 years. Would be curious if its related.
You can turn macOS into Windows 3.1 reading a floppy by mounting an SMB share with a ton of small files and running an rclone sync between it and an external drive that has previously completed a sync. The stat() operations make the kernel go crazy. It’s the most appalling thing I’ve seen and has been broken like this since Catalina where it arrived as a massive performance regression.
You don’t even need networked storage for that, just attach a slow spiny disk and it’ll grind every app accessing the filesystem (even if those files are on a super fast internal SSD!) to a halt at random points.
I know this is random but my Bluetooth mouse was driving me absolutely nuts, and this workaround (which involves a GUI instead of running some random script off the internet) was an absolute lifesaver: https://apple.stackexchange.com/questions/377853/macos-catal...
If you are pinned to a core, as non burstable instances should be, you are still pretty much vulnerable. Having noisy neighbours will pollute caches and make extracting data harder, but, eventually, everything will leak out.
I’ve been thinking what would happen if cores would be pinned to separate security domains - all kernel processes run on one set of cores and user processes on others. I imagine microkernel OSs could go that way much easier. If kernel and user space communicate only by messages and shared data, there’s no reason they’d need to even share an ISA.
Maybe each security context needs to be in its own cloud account and own network. Long ago it was an axiom that if you share a call stack in a process you trust each other. Perhaps the current truth is if you share hardware you trust each other.
Should we have a debate as to whether or not Spectre mitigations matter for some (or all) desktop computers? I know that, theoretically, I could install a piece of software on my Linux box that is malware and could try to read my memory via those methods, but let's be honest - we're all mostly concerned with servers that run code for dozens or hundreds of different clients.
I'm a foil hat as much as the next - security is of the utmost concern to me, but for once I actually just don't care and would take the performance back on my local dev machine.
> Unfortunately "install a piece of software" also includes allowing javascript to run in your browser.
Per-process Spectre mitigations could be helpful there, but I don't understand the technical details to know whether that would be possible to implement. It would be nice to disable mitigations on a video editor and for gaming.
The way I understand it (not that well, admittedly), per-process mitigations would be all about keeping that process from reading other memory areas, not about protecting that process from others. Which is better than the reverse if your intention is to allow some processes to run random js.
Yeah, but in the context of games, most likely it means threaded code written in C or C++.
If anything Spectre has shown us that the only real mitigation is to go back to multiprocessing with IPC, with the extra hardware resources it entails, as the exploit exists regardless of the language for in-process memory.
The problem with spectre/meltdown is they don't use standard calls to ask for memory of other processes... that is the vulnerability.
If you were do to do per process mitigation it would need to prevent certain process execution flows from happening, because the vulnerability is a problem with the CPU pulling memory from the way speculative execution works. This actually impacts things that are typically protected and is much more impactful than people think... for example, because the bug allows reading from nearly any memory address space, you could also pull in things like crypto keys from the OS or passwords from memory.
Yeah, but if you can mitigate per process, you can keep the secrets of trusted code from the eyes of untrusted code by only affecting the performance of the untrusted processes. The way I understand it the "protection cost" would fall on potential attackers, not on potential victims (unless of course they are both, holders of secrets and runners of untrusted code).
Unfortunately, that is incorrect understanding. In the context of stuff like this, "untrusted code" can be so many different things, it isn't just being able to run an executable... The issue with these vulnerabilities is the processor "pre-runs/prefetches" certain things for performance, which would likely be run in the future, so that it has those results cached, or to increase the amount of instructions in a CPU cycle. The issue is that many of these things aren't direct executable code, but more like access patterns.
For example, a speculative execution vulnerability might exist when there is a string of data in memory that has a memcp pattern, with memory addresses that are valid. To speed up the execution of programs, the processor might proactively read the memory from that memcp pattern because it is sending a command to the memory controller already.
Many of the mitigation techniques are to flush the caches/buffers and be careful about memory reads, which are the precise things that actually take the performance hits. And one of the problems is since they are access patterns, the vulnerabilities can be the html renderer compiled with an application, an SVG rendering library or a mail client.
For example, lets say there are mitigations built into the JS library... if you build a specifically crafted SVG, you could create similar access patterns to get around it. Its a huge cat and mouse game if there aren't OS protections and it only takes a single app to lose your secrets stored in memory.
Opt-in per-process spectre mitigation is already the case for some of them, because the mitigations in question are way too costly.
Now it is not possible for every kind of mitigations, because e.g. patching the kernel between mitigated processes and unmitigated ones would be more costly than just always running the mitigations.
edit: thinking more about it: you could have crazy ideas like two versions of the whole kernel space always loaded :D not sure about the cache impact in this case though.
Yeah no disagreement there. I had totally forgotten about the JS POC - ugh!
The JavaScript argument is interesting to me in that it's already flawed. I suppose I'd rather focus on the security issues with browsers running code on my computer more than anything else since it's effectively the "but what about ___" answer to so many threads like this one.
I've seen a few other comments suggesting per-process rules to enable or disable branch protections. That's an interesting thought, especially considering you could apply it to either "trusted" or "untrusted" code depending on it's source.
I don't know about the wild, but if this were tuned (i.e. this requires a lot of work for the first byte, the rest are easy) for a HVT you wouldn't know.
The problem is that PoC is extracting data which the PoC itself created specifically to facilitate said extraction. AFAIK no one has created a PoC which can extract specific data which hasn't been constructed to facilitate the PoC.
Yes, but your fans would start spinning like mad. I kill any browser that does that. You’d have to execute a successful attack within a few seconds to pull it off. I think that’s a risk I’ll take.
If this is your security mechanism (chuckle), then attackers will just slow themselves down by duty cycling. Say, only attacking for 100ms at a time, then sleeping a second. You'd never know.
...making it even more unlikely the attack would find anything of value (or even recognisable as such) in a reasonable amount of time.
To use an analogy, these side-channel timing attacks are really a "looking for a needle in a haystack" (or heap...) situation, except that [1] you don't necessarily know what a needle looks like, and [2] the haystack is constantly changing. AFAIK all the PoCs shown so far relied on having a deep knowledge of the system and carefully constructed conditions.
If these attacks could undetectably dump all of your RAM in a few seconds, that would definitely be a huge concern. But they're more like being able to read a few bytes per second, from somewhere in the address space, with no idea what they are or where they're being read from, and no guarantee that they're even contiguous.
I agree that it's not good, yet anecdotally I've realized that a device has been compromised by running `top`, on Windows and on Linux. It's not a good heurestic because it's only disvoverable post-compromise.
I can’t tell you how many startup’s splash page animations have actually caused my PC fans to spin at maximum. What is this website possibly doing with all my available computing power?
That's the first time I have heard a number this high for these exploits. All prior numbers I've heard were many orders of magnitude smaller, more like byte/s. The article linked above cites 1 kB/s as novel.
That was a number I heard (Meltdown pre-mitigations) when the "oh shit" papers started dropping a few years ago, could be misremembering. I'm also still slightly inebriated so thank you for nerdsniping me (Lit Review time!)
They tried. The V8 team eventually gave up and said it was unwinnable.
What they did do is move tabs to their own process so they can take average of the operating systems protections. Yes you can read the memory of the process hosting the JavaScript, but now there isn't anything interesting in it. Google's security team released a proof of concept attack that can read the memory in the renderer in many systems.
Man mobile keyboards suck. Any idiot knows the word average doesn't work there (at minimum you'd have to preface it with the word "the"), so why can't my keyboard run an ML model that's not an idiot?
Didn't even notice until reading this comment! I think my brain said, "starts with an A, got a V near the beginning, ends in AGE, must be ADVANTAGE in this context."
Mitigations for inter-process side channels address the issue of local applications attacking each other. That includes your web browser, the JS in it, or any other ad-laden crapware attack your local applications, e.g. to steal credit cards, SSH keys, etc.
Side-channels are pernicious. In the limit, they give applications unfettered read access across protection boundaries. If we don't shut them down, we might as well throw out the whole UNIX process boundary security model.
Ask yourself, would it be fine if every process had a 4KB/s (basically dialup speed) connection to read any desired byte of another process's address space?
Of course not. Thus, we need mitigations to shut these channels down.
address the issue of local applications attacking each other.
IMHO it's stupid to even try to isolate processes to that extent, as it's a really deep rabbithole that'll lead to worse performance and dubious increases in actual security. The best defense is to simply make everything running on the system be trusted.
Process protection boundaries should be for protection against accidental cross-process corruption, a form of reliability, and nothing more. That's effectively what the early 286/386 documentation stated, so Intel never even intended these protections to be defenses against side-channels in the first place.
Of course, the "security industry" needs to keep creating paranoia-fuel to justify their existence...
> Ask yourself, would it be fine if every process had a 4KB/s (basically dialup speed) connection to read any desired byte of another process's address space?
> Of course not.
So if it's not OK for processes to read each others' address spaces, does that mean it's not OK to attach gdb to a running process to figure out where it's stuck at, without running gdb as root? I chose to reenable ptrace among sibling processes on my system out of convenience, and hopefully it's not too much of a vulnerability. (I also chose to enable passwordless sudo, which is convenient, but probably dangerous as well. I wonder if I can use my hardware security key for sudo instead.)
Multiple Spectre variants (RDCL, RSRR, Lazy FP state restore, SpectreRSB) bypass process boundaries. It doesn’t matter what IPC mechanism you use, they can read arbitrary privileged memory no matter who owns it.
IPC really has nothing to do with anything, Spectre-wise; you don’t have to be using any IPC mechanism in either the attacker or attackee process to be vulnerable to these variants.
yes, I am interested in this.. basically I have mitigations OFF and also, do not run a web browser on the base OS. (Debian/Ubuntu here) in VMs I do run the browser, with two or three in use daily..
Honestly, I think it's time to reconsider the wisdom of allowing arbitrary untrustable third party executable code to run instantly in the form of things like JavaScript on web pages, instead of just nerf everyone's computer into molasses to prop up an idea that's been bad for the web anyways.
I've been of this opinion for a while now, not just because of performance slowdowns and security issues, but also just because of the way JS on web sites has been reducing usability in the form of popups, bitcoin miners, playing videos, sudden redirects to phishing sites and whatever crazy things are out there now.
I'm not saying get rid of JS, but treat it like it is - running code you can't trust. Web sites should start as largely static HTML documents that you read, and then if they need to use JS then they should be required to ask permission to do so, the same way any other executable code is managed in any other computing environment. That seems wild, but I think it's far less crazy than taking away a decade of performance improvements to the entire computing ecosystem by default so a broken security model can continue unquestioned.
You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea.
I think one problem with the comments about this post is that they doesn't emphasize enough that the hit is to system call heavy workloads. This is NOT a global slowdown of all compute. The hit is to system call performance, and it's big, no question, but I don't think we need to throw out the internet's structure in order to address that.
One option is to make fewer system calls. For a program that is basically scanning a file system that might be harder to do today, but for tons of other programs it isn't, and with iouring we have a very reasonable escape hatch for optimizing syscall heavy workloads.
This might sound silly, but this sort of thing is constantly happening - programs are optimized for thinking something is fast and something else is slow. For example, if you built a program in the 2000s you'd do everything you can to avoid the disk, aggressively caching. In 2020 disks are insanely fast, and the cost of caching will be worse than just optimizing your disk usage.
I don't know about the average website, but from what I can tell most sites that aren't total shit are pretty 'clean'. With an adblocker, especially so.
> running code you can't trust
We do that already. There's literally dozens of mitigations taken based on this.
> You're basically saying "let's consider reinventing the internet", which I think is not reasonable or a good idea.
It's absolutely reasonable to require the user to give a web page permission to start executing powerful, potentially dangerous code on their computer. Also JavaScript is not "the internet", nor is it even really "the web", which for most of its history was relatively benign HTML documents that you read, and things have frankly been on a downward trajectory in terms of safety and usability since we started changing it.
Powerful JS is a relatively recent phenomenon in the history of the web, and largely under the theory that we can do it safely with correct design. As someone that has to moderate code on un-trustable web sites as part of my work, I can just say it's not working out very well, even leaving out stuff like spectre/meltdown.
I don't think this would solve anything. This is like putting Word macros behind a "do you want to run this macro?". Yes, yes they do want to run it.
If people were willing to put every webpage behind a "do you want to run this webpage" we'd see them all using noscript already - virtually no one wants that experience.
> largely under the theory that we can do it safely with correct design
I blame operating systems and hardware vendors tbh. It's their job to make this safe, and they do a pretty bad job of it. Browser vendors have had to pick up a massive amount of slack to try to compensate, to the extent that browser teams have to make major patches to the Linux kernel.
I don't think we need to go quite that far. I think one of the issues is that browsers tend to entirely neglect the context of Javascript. They treat a complex webapp the same as they treat a simple website that has jQuery for drop down menus, despite the fact that the expectations should be substantially different.
The former should absolutely have some kind of security notification similar to installing an app: "this page wants permissions X, Y and Z". You can either accept those permissions and use the app, or decline them and the app can decide whether to just not work or to disable some features that rely on those permissions.
The latter should have an extremely minimal set of features. Probably just the ability to manipulate the DOM. The second it crosses into something as basic as AJAX requests, it now needs a different security context and the user should approve that. It now has the ability to exfiltrate data from your PC.
The blurring of lines between a web page and a web app has been great in many ways, but security on that front just doesn't seem to have moved much.
"Strong JavaScript" continues to fail this trust model even with very careful design, leading to (among other things) mitigations in the form of multiple double digit performance hits to all computing. That seems more like an engineering reason to re-evaluate the status quo to me. "Web sites should be allowed to run untrustable executable code because we can manage it" feels far more ideological to me, because it's based on a belief that is becoming increasingly unfounded by the accumulating evidence.
I’ve made similar comments in the past but I think we’re just trying to predict too much about what programs are trying to do in hardware.
I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”. Most of the real slowdowns anyone has in day to day performance has more to do with inefficient code than hardware anyways.
Look at old game consoles (like a regular old PlayStation) and what they were able to render on what today would be laughably slow hardware. They could do it because developers learned the stack inside and out.
I’m hopeful that the emergence of arm as a desktop/server competitor will help in some ways by putting enough pressure on companies like intel to really rethink some of their core stuff, but who knows.
> Look at old game consoles (like a regular old PlayStation) and what they were able to render on what today would be laughably slow hardware. They could do it because developers learned the stack inside and out.
You're oversimplifying the situation and drawing conclusions from it. The PSX had dedicated hardware for geometry transforms, video decoding, sound processing, and rasterizing. The CPU was used for game logic and queuing up the render pipeline. So it's not like all PlayStation developers were doing black magic in every game, they were using a lot of dedicated hardware with well known and relatively modest and fixed constraints (NTSC/PAL, stereo audio, and relatively small frame buffers).
It's interesting you picked the PSX as your exemplar because it's CPU/GPU/MDEC and audio processor were meant to be black boxes so developers didn't have to code to bare metal. The IO stack was much shorter and the OS (such as it was) was single tasking, single threaded, and didn't have any networking.
Slowdowns in modern systems are much more complicated that a simplistic "inefficient code makes them slow". There's hundreds of small stupid latencies all over the place in modern systems. The USB and Bluetooth stacks are filled with little latencies, retransmissions, and just wait loops. Unless your inefficient code is full of accidentally quadratic loops it's usually compounded latencies making systems "feel slow".
The description sounds more like PS4 than PS2 (maybe PSX was simpler - PS3 is closer to PS4 and "normal" programming). I've seen numerous examples of how involved CPU was in rendering, especially on PS2, due to special units being exposed as MIPS coprocessors. Efficient rendering meant you had to keep the pipelines happy and that could require significant amount of assembly wrangling.
I remember reading about how GTA3 on PS2 was a watershed moment, because it was a proof you could use a somewhat more generic engine - whereas console programming had a heavy amount of assembly focus due to historical reasons.
I'm sure there's plenty of people on HN with first hand experience developing for the various PlayStation models. I only know what I've read about the experience and technical tear downs. So maybe one will swoop in dropping knowledge bombs and tell me I'm wrong.
The original claim was 3D worked on the PSX because of "efficiency" of the code. While I'm not claiming games on the PSX were inefficient, the hardware was designed specifically to do real-time 3D rendering. It's not like the PSX could only do 3D because everyone somehow had super deep mastery of the system.
To my understanding the PSX was a big change in console development. While consoles always had some dedicated hardware (blitters, audio DSPs, etc), development was a lot of beam racing. There were no frame buffers, code ran as graphics were being drawn to the screen and during the VBI.
The PSX was more like a modern system where you had a CPU and a GPU (albeit fixed function) with an OpenGL-ish drawing model. It was a far more capable 3D machine than PCs of the time that had to do all 3D work on the CPU with no acceleration.
Tomb Raider on the PSX was impressive because the console only cost $300. While I'm sure Tomb Raider on the PSX wasn't inefficiently coded, the design of the PSX console contributed as much to its existence as the code. Quake on the PC on the other hand could only exist because of the developers' deep system mastery pushing generic hardware to its limits (before GPUs were prevalent).
> I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”.
Turning off speculative execution reduces performance enormously. Yes, code is often less efficient than it could be but "surprise, you need 5x as large of a datacenter because your hardware isn't doing fancy stuff" is not going to be an acceptable thing for any large organization.
I suspect our heavy reliance on speculative execution is just a local optimum, and we can grow out of it by providing the processor more information about the data flow, making memory access more explicitly asynchronous, and simplifying the hot paths.
I like the way the mill approaches these architectural problems.
I'm very unconvinced by these arguments. Providing enough information to the processor to claw back all the performance that predictors give you, that requires some way of knowing all those things in advance. Statically.
And so you fall into the pit of tar and despair that is relying on Sufficiently Smart Compilers. Same one that couldn't save Intel's shiny new IA-64 architecture (the "Itanic").
Static analysis is just not a tractable way to replace hardware predictors. Even profile-guided information is a questionable answer. Could it be we're missing some key idea that'll take us far beyond all of this? Maybe, but it's probably not the same WLIV designs that require impossible feats of software comparable to asking for the weather 2 years in advance so you can save yourself the hardware cost of an umbrella.
Now, perhaps it would be unfair to criticize the Mill for not taping out an actual chip, after all having new ideas is valuable and fabs are very expensive. But we know this is a tricky subject. Performance optimization ideas only have value after you benchmark them, and they don't have an RTL implementation. Nothing that can run on an FPGA, not even "abstract" Verilog running in a testbench on a software simulator.
If what you want is a DSP that runs super simple hot loops very fast, then build a DSP and make it VLIW all you like. But that's not the workloads people run on a general purpose computer.
> And so you fall into the pit of tar and despair that is relying on Sufficiently Smart Compilers. Same one that couldn't save Intel's shiny new IA-64 architecture (the "Itanic").
And how can one get their hands on an Itanium machine? It's a dead architecture in less than two weeks, and for the last decade the things have been almost exclusively enterprise machines; not something the hobbyist (or even the academic!) is likely to get access to.
Do you have an HP zx6000 lying around, perchance?
Itanium failed early; it had many more problems than compilers. And if we don't have a replacement, we'll never get those compilers from anyone but the most obsessed.
This has been tried (not on vaporhardware Mill, I'm more thinking about e.g. Intel Itanium) and it failed.
The reason is extremely simple: a speculative OOO processor optimizes dynamically. If you switch that with static compile time optimizations, you are bound to only be as fast as before in some quite limited parameter ranges (like: number of entries in a hash table, size of an image, etc.)
Transmeta were VLIW, yes, but weren't EPIC - which is the main difference involved. VLIW just means there's a long instruction word, usually targeting multiple units, but it doesn't necessarily mean there's no dynamic reshuffle in the CPU architecture or anything like that.
EPIC stood for Explicitly Parallel Instruction Computing, and took the "let's push it all to compiler" to the extreme. Itanium was never supposed to have any form of branch prediction or OOB, because it was supposed to be handled by the compiler.
This led to someone quipping that Itanium was a very fast DSP, but ridiculously expensive.
I agree with what you're saying around the Mill and dataflow in a sense, but feel like we disagree in the details. The issue with Spectre, etc. is that data of different trust levels are comingled in a single address space. We want the processor to speculate on some data, but not others and we don't tell it how to tell the difference. What's going to save us isn't dependency information or static scheduling, but more fine grained permissions around the data accessible at a single time.
IMO we need to bring back segmentation hardware. Not the x86 version of segmentation (there's not a feature that x86 wasn't able to make twice as complicated as it needed to be while only giving you half the use cases), but the cleaner object capability on top of paging hardware versions of segmentation. That solves the really rough Spectre cases like even NetSpectre where you can slurp out kernel state remotely from untrusted network packets. Just stick them in a "this memory is untrusted" segment. From there the CPU's dynamic dataflow optimizations can include speculation where memory is marked as trusted.
They're still going - Ivan said on their forum that they were planning on going full steam ahead last summer, but scuppered by lockdown. I don't totally buy that, but that's the story.
The interesting part about the Mill is that it's not even all that complex. It's just taking the existing VLIW architectural approach and adding a number of custom "tweaks" to improve the programming model over what VLIW provides.
This is sort of what GPUs do, since a GPU driver is essentially a big JIT compiler. Branching is very expensive compared to CPUs. Remember that 95%+ of branches of predicted successfully, and CPUs work on more stable ISAs.
More specifically, we should point out that speculative execution is important for papering over IO/memory latency. We can incant all we want about 'inefficient code', but the compute vs memory latency imbalance is a whole different beast.
> I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”.
Have you seen how happy people are with M1 machines? That's because it's faster. It's definitely not simpler.
> Most of the real slowdowns anyone has in day to day performance has more to do with inefficient code than hardware anyways.
Not true, especially not for heat. The energy use of on-CPU/on-GPU tasks is more up to the hardware. It might be true for things like network bandwidth though.
Let say the Pentium MMX 166 is roughly 60x slower, per core, than the Pentium G6950.
So the "IPC" (I'm not sure of what the benchmark are doing, but I'm doing rough evaluations anyway) is approx 3.5 lower for the Pentium MMX.
And that is while the speed gap constantly increased between memory and CPU (esp latency), so a Pentium MMX cpu core somehow speed up to 2.8 GHz would actually probably perform even worse in a design with memory that actually exists. Maybe way worse.
The complexity of modern good ARMs is comparable or even higher in some area than the complexity of x86 processors.
We’re seeing a full frontal assault on Intel by competing computing architectures. Everyone is jockeying to see who is going to have the better next gen architecture. The problem is that in order to start attacking general computing as a problem, you need first customers who buy a lot of chips, and those customers tend to have specific workloads they want accelerated. Now we’re back to designing for customers instead of abstractly making the absolute best chip.
And that’s the reality right? Demand drives innovation it private enterprise is funding it. If you want a chip for the public good, you’d need to fund it with public money and that’s a different dance with the devil.
In short, I think the way that technology is produced is fundamentally customer focused right now.
I think this has cause and effect reversed. Advancing general purpose CPU's is very hard and expensive nowadays. The slower rate of progress means that custom chips make more sense, they take longer to become obsolete.
I'll make a deal with you: I'll agree to turn down speculative execution in hardware if
1) you can solve the VLIW scheduling problem, and
2) you transition the entire computing ecosystem to a JIT model.
These are the things we would need to claw back the performance we would lose through disabling speculation. You can look at speculation (I'm handwaving a lot here, bear with me) as the processor hardware dynamically recompiling your program code depending on observed behavior of the program. That's well and good and it gets us a huge performance boost.
You can, in principle, do the same thing in pure software. But every single attempt to do has ended in total algorithmic failure.
The last serious attempt I'm aware of to "drive" a uOP scheduler explicitly in software was Itanium, and that failed, in part, because compilers couldn't take advantage of the processor's instruction level parallelism. There's nothing in math or mathematics or computer science that forbids a magical compiler of the sort the Itanium people wanted to create. But nobody's made one. Your first task in your project of eliminating speculative execution is to solve this algorithmic problem.
But solving problem #1, while necessary, is insufficient. No static ahead-of-time compiler can adjust the compiled code depending on the actual execution history of the program. To really get back to speculative execution par, you have to give your already-magical compiler the ability to recompile code at runtime. That means turning everything into a JIT. Your /bin/ls would actually be LLVM bytecode, not machine code, and some runtime system would be responsible for dynamically generating the machine code and adjusting it depending on execution history. After all, that's what current superscalar CPUs do internally, transparently, all the time. This is problem #2.
Honestly, I think the world we'd create by solving both these problems would be a better world. I really don't like how we can't program the processor's speculation engine and uOP scheduler. I'd love to be able to do that.
But I don't think we can get there from where we are, so we're going to be stuck with speculation and hardware mitigation forever. Please, prove me wrong.
> Honestly, I think the world we'd create by solving both these problems would be a better world. I really don't like how we can't program the processor's speculation engine and uOP scheduler. I'd love to be able to do that.
Have you started working on any solutions for 1 and 2?
But rendering isn't what makes a modern computer slow. For example, Assassin's creed isn't even that well optimized but it maxes all threads, uses all the GPU and looks beautiful.
And people have tried "simple" hardware (it ends up being not simple) that the programmer (compiler) understands before, it doesn't work.
> I don’t think software as an industry really has a “this chip isn’t fast enough problem”.
yet this is what I'm saying to myself every day, even with very fast computers available, and very efficient code running that hardware pretty much to its limits.
Consider the philosophy of MAME which plays old games and avoids optimizing for GPUs and (IIRC) most specialized graphics layers like Direct3D or Metal. As I understand it this makes it more portable and easier to maintain, at the cost of some performance.
Now MAME's scope is limited to aging games which aren't evolving. Only the underlyibg OS's and runtime hardware are changing.
Console games pushing aging hardware have a very small variety of runtime hardware to optimize for. And optimizations pay off in better graphics or features that differentiate. Optimizing for ever evolving desktop computers with near infinite hardware is a whole different story.
This was very well known when the mitigations came out but I do wonder if they were too broad.
sure mitigation in place for a platform that run untrusted code like a browser make sense but should it affect every program running? I know trust is fickle but at least for power user there should be an option to disable mitigation on a per program basis.
> sure mitigation in place for a platform that run untrusted code like a browser make sense but should it affect every program running?
The issue is that mainstream OS's are simply not designed to protect against information disclosure vulns like Spectre in a principled way. https://en.wikipedia.org/wiki/Multilevel_security is a very well known approach academically but practical implementation is lacking. So we have to go with one-size-fits-all mitigations that treat all code as untrusted, and all data as potentially sensitive.
On the one hand, I haven't seen any real exploitation of Spectre, at least by a non-TLA. On the other hand, the mitigations aren't so slow anymore on a modern CPU:
IMHO, there's a good argument for turning off the mitigations on Skylake in some systems - but in modern CPUs the cost of leaving the mitigations on is bearable.
Yeah, kinda similar to rowhammer. I was just saying the other day that these exploit techniques are totally viable, but there's not much point - privesc is trivial on any desktop environment (linux or Windows, maybe less on osx), and usually not too hard on servers either. Fancy exploits aren't worth it when operating systems are so vulnerable to local attackers.
That said, the mitigations are assurances, and it also lets us point a finger at intel and say "fix your shit you just caused a global performance regression".
No. Io_uring is a message passing system where you tell the kernel to do something and let you know when it's done.
Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace.
An example of this might be closing a multitude of file descriptors or registering signals or writing the same data to multiple fds etc, which becomes prohibitely expensive if you need to do it multiple times quickly, and actually doing it even once is really expensive if your sets are large.
Despite the name, there is nothing io-specific about the io_uring interface. Non-io syscalls can be added. Io syscalls just tend to benefit the most (due to call frequency).
> Syscall chaining refers to having the kernel execute consecutive systemcalls without switching the context back to userspace.
io_uring already gives you that. You can submit multiple operations in a batch and link the operations together so that if one operation in a chain of linked operations fails, io_uring won't try to execute the rest.
The scope of the potential damage is rather huge and can't really be overstated.
It's akin to handing over your entire working OS memory to a person, complete with all encryption keys, session tokens and whatever documents you're working on.
Potentially, anyway. The working proof-of-concept attacks I've seen use a lot of CPU to read memory and they read slowly, but those are proof-of-concepts and it would not be terribly difficult for a motivated person to make them significantly faster and less obvious.
Has there ever been a real-world attack of this type?
All kinds of things are possible, but you don't cut your leg off because theoretically you might possibly one day get gangrene from an ingrown toenail.
There are working proof of concept attacks. The only reason you don’t hear more about this is that the mitigations being complained about here are universally enabled in the most vulnerable targets, like cloud hosts.
Otherwise it would be pretty trivial to weaponize the original demonstration, deploy an image to AWS or Google Cloud and read out all your neighbours’ secrets.
The success of the mitigations in rendering these attacks unworkable is literally the only reason people are under the mistaken impression that the cost of the mitigations isn’t worth it “because these attacks don’t happen”.
The proof of concept code has been further mitigated by removing high precision timers from JavaScript in most/all browsers; however it is not terribly difficult to create code which bypasses that restriction.
The only thing that’s prevented more investment into this method of attack is that it has essentially no value due to everyone being immune.
I assume the triple letters have done it, but these attacks require a lot of careful planning so why bother when you can exploit something else. That kind of protects us, but these exploits are terrifying for purveyors of homogenous interfaces (i.e. the cloud) that can be attacked in ways you are already imagining.
Also, anyone deploying this won't be stupid enough to chat.
Those exploits enable any program to read essentially all memory.
This means nothing you did between turning on your computer and running an application with potentially malicious code (e.g. looking at a website with javascript enabled) is secret.
So if I understand this right, CPUs try to predict what operations are going to be made in order to gain performance, but instead introduced a vuln that killed performance? Wouldn't the logical thing be then to get rid of the predictions on hardware in order to be able to turn off these mitigations?
Are there CPUs out there / being made without these SoC predictions?
The techniques used to make CPUs fast have possible vulnureable areas (not all of it is due to Out-Of-Order Execution, some was due to optimizations made on top).
The mitigations introduced stalls into those mechanism, clearing some of the state, resulting in slowdowns.
However, the mitigations are not as big slowdowns as not having the speculative execution mechanism at all.
I'm not sure if I got you right: The performance boost with speculative execution is massive. It introduces a vuln. It is the fix for that vuln that kills the performance.
What I'm saying is if the fix for the vuln negates the performance boost from speculative execucution, then the net outcome is 0 performance boost and speculative execution might as well be removed entirely. It wouldn't surprise me if it just costs more energy to keep the vuln and mitigation active at the same time.
I think your views are founded on the "moar Mhz moar performance" myth ( which is prevalent ), and Intel's decades old monopoly didn't help either, but if you compare 2 equivalent CPU's 10-15 years apart, there is no stagnation in performance.
Maybe the old trick of cranking up the Mhz and call it a day doesn't work the way it used to, but in terms of performance results we are getting improvements.
> Maybe the old trick of cranking up the Mhz and call it a day doesn't work the way it used to, but in terms of performance results we are getting improvements.
Except... we aren't. Intel's CPUs haven't gotten significantly better in 4+ generations. AMD's have, but that's only because they were still catching up to Intel.
I have to say that I'm liking the technical discussion here. Although I am surprised that nobody has mentioned the meta topic about the word usage of the title. Like did I miss something and is "murder" actually legit jargon? Or is the author just being dramatic? (Article looked like "kills" would have been perfectly adequate and appropriate.)
Well, the marketing of these vulnerabilities was also bombastic and hyperbolic, so it follows that the retorts should employ similar language so they are taken just as seriously.
Is this agnostic to hardware? I thought Intel/AMD had different strategies regarding variants of spectre with AMD having specific solutions of retpoline.
Without knowing the hardware, what is the point of the performance comparison?
Not agnostic at all. Newer processors have less bugs to work around, and instructions to speed up the workarounds, so the performance impact is smaller:
The author's hardware is uniquely susceptible - Skylake is old enough to suggest Meltdown mitigation (the new Intel processors and of course AMD don't require it) in addition to Spectre mitigation, yet it's new enough to use indirect branching more thoroughly than Broadwell.
If the author had older or newer hardware the performance effect would have been smaller.
* It might be noted that there were Intel models betwen Skylake and the current which were still susceptible to meltdown. Even those had a smaller performance impact:
I would love to see new chips that take all of the transistors used for speculation and use them for more cores. I asked electrical engineers once how many of the transistors on a chip serve speculation, and they said, "To a first approximation, 100%."
That means we could add a lot more cores. Add enough, and the OS could easily pin basically all processes/threads to their own cores.
And that, I believe, might win some performance back.
> Since most of the circuitry within each core is dedicated to computation, rather than speculative features meant to enhance single-threaded performance, most of the die area and power consumed by Fermi goes into the application’s actual algorithmic work.
But GPUs are far from easy to code for, even in 2021, and there are a lot of workloads that benefit from speculative branching. Having a combination of GPU cores and speculative CPU cores in an architecture allows you to access the best of both worlds.
Hey, I just read your blog post, and while I assume you have an interest in making improvements in this area I think you’re handwaving away a lot of concerns, and are seemingly unaware of many other issues in ways that significantly affect the viability of your designs. If I could come up with an analogy, it might be like if I wrote the following about cars:
“Car design has stagnated for decades. They emit massive amounts of greenhouse gases, and they’re not even all that efficient in doing so. But we can fix this! First, we’re going to use antimatter to power the engine, it’s 100% efficient and it has no waste products to boot,”
Your entire post is kind of like this for computer architecture. You rely on a lot of theoretical/academic ideas, which are cool, but nowhere near being practical (or even proven). Then there’s stuff like “we’ll solve security by formally verifying the OS and core software, and writing everything else in a memory safe language”…I mean yes, this obviously solves certain security issues. But there’s no clear path to get there, and we don’t even have the tools to formally verify certain software yet.
Then there are parts where you either undersell your knowledge on the topic or are seeming unaware of the current state of the art: dynamic linking for example. Your idea of memory mapping libraries is basically how dynamic linking works, except you call it static linking so you can handwave away the concerns that come with it. There’s also a lot of things that are unlikely to be efficient at all: pinning tasks to their own cores means they are unlikely to be doing much most of the time, using a ring buffer for message passing means that you’re going to be spinning on them (which is good for high-performance contexts, but most applications aren’t going to benefit from this). And so on.
I think overall you’ve actually done a fairly interesting job redesigning how a lot of HPC stuff works already, so I guess you can at least consider yourself on the right track for that kind of thing. But this kind of design isn’t really going to fly for general workloads, and you’re still relying on a lot of things that don’t actually exist beyond a research paper.
You have good points, but I think you misunderstand the post in many ways.
First, you do realize that there already has been an OS that has been formally verified, right? It's called seL4. There is also a C compiler that has been formally verified. It's called CompCert. So there is a clear path to get there on the software side.
Second, I am not referring to dynamic linking. Dynamic linking requires jump tables because the dynamic library will be mapped into a different spot for every process. That is not what I am suggesting.
I am suggesting that the OS map the library into the same spot in every process. This means that no jump tables, and thus, the dynamic part of linking are required. Most importantly, the OS would not have to invoke the dynamic linker to execute the program.
So what I am really suggesting is something like static linking, but with OS support for reducing binary code duplication.
Think of it this way: say I had an OS that could take a static .a library and map it into memory. Then I compile my libc into a static library and tell the OS to map it at address 0x0A0000. Then when I compile programs, I tell the compiler that libc will be at address 0x0A0000.
When running such a program, the OS recognizes that it needs libc at that address, so it maps it. Then it maps the program and just starts it.
Of course, this would still require recompiling every program when libc changes, but if you keep the equivalent of LLVM IR around for every program, you only need to run the backend when that happens.
As for pinning stuff to their own cores, it turns out that most transistors in a chip are not running all of the time. That would, in fact, be a problem because it would be too much power consumption and heat. The term for this is "dark silicon," by the way.
So pinning stuff to their own cores and leaving those cores idle is not, in itself, a problem. The hope would be that the dark silicon would be balanced out by the fact that when the process gets a signal it needs to respond to, the OS does not need to do a process switch to start the process running again, which would save a lot of time.
However, I could still be wrong about how well such a design would utilize cores. I acknowledge that.
About the ring buffer, I would want hardware support for this, but if hardware support existed, then a process could try to read from the ring buffer. If there is no data, it could set a bit and go to sleep. Then when there is data, the hardware could wake up the process, and it could immediately start executing. Likewise for trying to write to a full buffer.
Thus, instead of spinning on them, they would do something closer to how glibc uses futexes: check them and if no progress is possible, go to sleep, then wake up on a signal from the hardware.
The double benefit from this design is that the OS would not need to get involved to wake processes up.
However, I do acknowledge that the design includes things that don't even exist, even in a research paper. The blog post was sort of a target to hit eventually, in 30-50 years or so.
> First, you do realize that there already has been an OS that has been formally verified, right? It's called seL4. There is also a C compiler that has been formally verified. It's called CompCert. So there is a clear path to get there on the software side.
CompCert has not actually been formally verified - only the middle-end has. The C preprocessor and assembler aren't, the frontend formerly wasn't (but I think is now), and bugs have been found in those parts by fuzzing.
Plus being a faithful implementation of the C spec certainly leaves room for security issues…
(Why do we say "formally verified"? It sounds like weasel words. What is formal about it?)
Regarding "formally verified," I believe the "formal" refers to the formal in formal methods, but I agree that it can be weaselly.
In the case of seL4, however, I don't think it is because they are incredibly precise about defining their assumptions. They have verified the machine code for various architectures, subject to those assumptions.
> Add enough, and the OS could easily pin basically all processes/threads to their own cores.
But usually (when you care about performance) you don't have 20 processes requiring 5% CPU load each, but 1-2 processes requiring everything. Making those slower won't accomplish much.
And if your problem is actually embarrassingly parallel [0], you are looking to run your code on a GPU (as another commenter notes).
is there an actual number one can attach to at how much risk this puts me in practice? Say I'm an average user, writing softare, using the web, is it one in a million on any given day, on in a thousand? It's hard make judgements about whether to make these performance/security trade-offs without any real sense of how dangerous it is.
