Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

This is surely a misunderstanding - the Zen pipeline is 19 stages deep, and disabling branch prediction would utterly destroy performance.

View on HN

My understanding is that it only disables indirect branch prediction, and only within the Kernel.

Could be wrong, though.

Righto, that makes some more sense. Still going to be awful for performance though!

So will the Intel IBRS patches. >99% branch prediction accuracy -> 77% accuracy from what I've heard.

As a consumer, will I have the ability to avoid using or disable the IBRS patches?

To be honest I don't really care about some theoretical attack that almost certainly won't be used to target me, and if they do, they can have it. I'd rather have the performance.

If everybody else is patched, bad buys don't have much incentive to write attacks. It's herd immunity. You have chosen no to vaccinate.

https://en.wikipedia.org/wiki/Herd_immunity#Free_riding

Except that the smallpox virus doesn't have the brains to team up with a thousand other viruses, create an exploit kit, test your immune system, and then deploy only the one specific tool most likely to bring you down. The immunology metaphor breaks down once we realize that electronic pathogens are deployed not by innocent rats but sentient human vectors.

Smallpox also doesn't know the difference between Joe Blow and Mark Zuckerberg. Humans have the ability to pick the most valuable targets and concentrate resources on exploiting them.

respectfully, ha ha. Just because an exploit is old doesn't mean it still doesn't get used.

Attacks don't follow the close-quarters-infection that physical viruses do, so it's a bad model to use.

That's not entirely without precedent. Look at macOS, still comparatively little malware compared to Windows even though macOS has had quite a bit more vulnerabilities in the OS itself compared to Windows.

Care to post some figures along with a citation for that assertion, please?

Sure.

https://www.cvedetails.com/product/156/Apple-Mac-Os-X.html?v...

https://www.cvedetails.com/product/32238/Microsoft-Windows-1...

https://www.cvedetails.com/product/17153/Microsoft-Windows-7...

But everyone here is already thinking about the string of recent macOS vulnerabilities. Even just in the past few months Apple has been hit by a bunch of fairly major vulnerabilities while Windows hasn't been in the news for a while. What bugs me though is that a theres a handful of the Apple vulnerabilities that weren't caused by an implementation error, it was from a flawed design.

In particular the most notable example of this would be the API used by system preferences that would let any user create arbitrary files with arbitrary permissions owned as root. Obviously the first choice with that is to create a setUID binary but even if the permissions weren't user provided this should be something that should jump out during the design process as a bad idea.

https://truesecdev.wordpress.com/2015/04/09/hidden-backdoor-...

As for a comparison of just recent newsworthy macOS vulnerabilities compared to Windows I'll just cite Hacker News as far smarter people than I have commented on this subject to death.

I just used the following query and only looked at the links on the first page.

https://www.google.com/search?q=site%3Anews.ycombinator.com+...

macOS total karma 2345

https://news.ycombinator.com/item?id=15410953

https://news.ycombinator.com/item?id=15807913

https://news.ycombinator.com/item?id=15828767

https://news.ycombinator.com/item?id=15864637

https://news.ycombinator.com/item?id=15804726

https://news.ycombinator.com/item?id=16043578

Windows total karma 304

https://news.ycombinator.com/item?id=815265

https://news.ycombinator.com/item?id=2758554

https://news.ycombinator.com/item?id=10889728

https://news.ycombinator.com/item?id=13577709

The macOS results span the last 3 months, the Windows results span the last 8 years. Mac sales only provide about 8% of Apple's revenue which is overwhelmingly dominated by iPhone sales and app store revenue. macOS has become the red headed step child and it's really starting to show.

1. It won't take long for this attack to stop being "theoretical" (assuming it still is).

2. No one has to target you specifically, it's a matter of time until someone uses this attack vector on something everyone has -- a web browser.

3. Once you're owned, you're going to be sharing resources with a couple of bots, so don't be so sure you'll get to keep the performance.

Web browsers are potentially easier to protect, as I understand it. You prevent javascript from getting access to high accuracy timers and rate-limit their access to syscalls. If a script is repeatedly calling methods that trigger a syscall thousands of times a second, just slow it down a little and the attack becomes impossible.

Disabling high precision timers isn't a long term solution. There's probably only a matter of time until someone finds a new way to make a high enough precision timer, and even if that wasn't the case, features like SharedArrayBuffer are just too useful to completely disable forever - and there's no easy way to make it impossible to create a high precision timer with a SharedArrayBuffer (just have a web worker which just increments a number in a shared buffer in a loop).

Would throttling syscalls really prevent using these syscalls? Surely it would just make the exploits lower to perform? Is there something I've not understood, or is the idea just to throttle syscalls enough to make it infeasably slow? If it's the latter, remember that users might potentially be on a website for half an hour at a time (if they're reading a long article or watching a video), so an attacker (whose code is running on the site, potentially through a compromised ad/tracking platform, or just XSS) would have a lot of time to extract whatever memory they want.

> and even if that wasn't the case, features like SharedArrayBuffer are just too useful to completely disable forever

That's only if you continue to participate in the shared delusion that the WWW can or should be a high-performance applications platform. Those of us who usually browse with JavaScript turned off can get along fine without SharedArrayBuffer or WebGL or WebSockets.

But how will you mine bitcoin or whatever for your favourite website then?

/grumble

Honestly curious, why is it a delusion to want the WWW to be a more powerful platform that offers more than just being a web of shared documents? Why is it bad for there to be an array of purposes or applications available on the Web? Just because you don't see value in it, doesn't really make it fair to call others who do see value in it delusional.

The WWW started out as a document sharing platform, and that has proven repeatedly to be a horrible base upon which to build an application platform. There's technological ugliness in the form of kludges like WebAssembly and WebSockets and WebGL that are (badly) re-inventing large parts of the operating system. There's the usability nightmares caused by trying to make a web application imitate a native UI (or worse, trying to use web technologies locally as a UI toolkit a la Electron). The addition of application-oriented features has detracted from the original feature set: gratuitous overuse of JS for stuff that can be done in CSS and HTML is rampant, leading to less responsive sites with worse accessibility and worse battery life. And sooner or later, every attempt to shoehorn a real security model onto the Web has fallen. Every month, the idea of a secure sandbox for running untrusted third-party code looks more and more like a pipe dream.

I fully understand how much the world has invested in making the web into an applications platform, and I recognize that many things of value have been built on that platform. But it's been a fundamentally flawed enterprise from the start, and the pitfalls are getting harder to ignore. We need to start taking seriously again the idea that untrusted code cannot be trusted. We need to stop re-inventing the operating system within the browser just because some programmers are too lazy to port their applications to more than one OS even when there are libraries to abstract away all the differences that don't require a UI redesign. We need to stop sacrificing so much efficiency for the sake of portability that doesn't live up to its purpose.

In order for a web browser suitable for document-oriented usage with limited interactivity to be secure and offer reasonable protections for your privacy, it has to take measures that preclude it from being a good applications platform. That conflict seems irreconcilable.

There are myriad reasons beyond programmers being "too lazy" to port applications to more than one OS for the web evolving into an application platform. Your rant is on par with suggesting we go back to horses and buggies because high-speed car accidents can be deadly. It vastly overstates the danger posed by JS specifically, completely discounts its superiority in filling the niche that it does compared to the previous status quo, and advocates a non-sequitur, anachronistic resolution.

> Your rant is on par with suggesting we go back to horses and buggies because high-speed car accidents can be deadly.

Don't be ridiculous. I'm not saying we shouldn't have cross-platform apps at all. I'm just saying we need a clear distinction between the WWW and any applications platform, just like we need a clear distinction between sidewalks and freeways. The web browser cannot do both jobs well.

> I'm just saying we need a clear distinction between the WWW and any applications platform, just like we need a clear distinction between sidewalks and freeways.

One problem is, no one seems to be able to define "web application" in a way that makes the distinction clear. Most sites that use javascript still use it in the context of displaying documents, so if you define any site that uses javascript at all as an "application," then most sites, including Hacker News, count as applications. But that doesn't actually fix any problems.

Fully agree.

Web should stay as interactive documents.

WebGL is such high performance that most examples posted on HN struggle on my phone, where I routinely play OpenGL ES 3.x games without any visible jank.

That ship sailed the moment JavaScript arrived on the scene, and Flash rode in on its coat-tails. The writing was on the wall: people wanted more from the web, envisioned more for it, than simply interactive documents, and they still do.

Granted, not everybody: some are more than happy with interactive documents. Great, that's awesome, and I hope you're happy, but you don't get to dictate the behaviour of the 99%.

And that figure is not an exaggeration: for my own sites about 1% of people have JS disabled. This post from Yell, over a much larger sample of data, suggests that 0.07% of their visitors disable JavaScript: https://blog.yell.com/2016/04/just-many-web-users-disable-co....

Granted, a large portion of that 99% won't know or care what JavaScript is, but they'll care if they lose the additional functionality it brings to the sites they use (though, honestly, I doubt they'd miss the ads, for which it's so often misused).

The problem I have is that 99% of my web use is the web as an interactive document - news and articles in particular - but those web sites still load an absolute ton of code.

Yeah, I'm certainly on board with that: vast amounts of ad-related assets and tracking code need to become a thing of the past. Still, for that I have uBlock, and I'm increasingly avoiding the worst offenders on that front anyway.

Still, sites I use on a regular basis that benefit from JS: GitHub (most evident with real-time updates to projects, issues, PRs); Office365; GMail, Google Drive, Google Analytics, Google Docs, the Adsense and Webmaster portals, and - of course - YouTube; Clubhouse (project management, heavier than Trello, lighter than JIRA); Azure management portal; pipeline apps such as TeamCity and Octopus Deploy.

Yeah, no dispute from me on that count, there are a lot of valid uses.

I am getting sick of what I presume is coin-mining code. I was reading an article about keyboards on some site the other day and after a few seconds my laptop started to sound like an aircraft taking off.

Yeah, high precision timers aren't a fix-all. Imagine a loop where you test a single bit of some protected memory. If it takes microseconds to determine the value of that bit that's really bad, but even if it takes milliseconds, seconds, or even hours that's still really bad. This is equivalent to how fast an attacker can download your system's memory during an attack. If that rate is mb/s that's catastrophic, if it's kb/s that's still super bad, if it's bits per day that might be enough to mean that only the highest value systems will be targeted, but that's a far cry from actual security.

I read there is already a web browser exploit, if I remember it was a CCC talk this summer

All OSes will be patched soon and then no one will be attacking using this exploit anymore.

Plenty of legacy OSes will not receive any patches, plenty of current OS instances will not be updated by technically incompetent owners, and either way attacks using this exploit will continue to be profitable.

Servers don't have/need web browsers (in general). Some on premise compute clusters don't even necesarrily have internet access except SSH from a few trusted users and exploits to run code locally would go through them or SSH (at which point you don't need meltdown to access the data).

I believe there are valid usecases for not applying these patchws.

Spectre (and maybe Meltdown, I'm not sure?) can be done in a browser with javascript.

Imagine if a random bad advertisement or injected script on a popular website could silently steal all of your stored session information for other sites.

It requires a lot of CPU so there isn't anything silent about it. If some bad advertisement absolutely kills the tab you're looking at, I hope you'd notice. If you're using a multi-process browser (like Chrome) the impact is pretty minimal.

That's not to say it's not bad -- the exploit works remarkably well -- but it's not fast or easy.

Imagine: You open the browser, leave it open on some page and then leave your computer for a few hours or overnight. You can’t notice what a rogue ad did while you were away. Your passwords are maybe gone.

Besides the "hiding" strategy (bots hide themselves under the windows clock. It's a wonderful world out there), I'm afraid it's unlikely you'll notice. Reliability of modern consumer software ain't all that great.

You'll get targeted through a web ad which will then install a BTC miner on your machine, so your performance will be shot anyway.

Yes, from what I've read on the LKML, the IBRS has to be enabled and disabled by the kernel at the appropriate moments, and there will be a kernel command line flag to disable it (or leave it enabled all the time).

> ... there will be a kernel command line flag to disable it ...

FYI:

  pti=off

They are doing the same as the Intel microcode update presumably, offering kernel a bit to enable/disable indirect branch speculation. Usually it will be disabled on entry into kernel and reenabled on exit, so it helps the kernel, not necessary user programs spying on each other (retpoline for those)

See here:

https://lkml.org/lkml/2018/1/4/615

The IBPB mitigation clears indirect branch prediction state on context switches between processes so it does help with processes spying on each other.

Translation: Only closes some low-hanging attack vectors.

* Only if you use branches in your code.

Yeah, who uses those?

I like how this comment is a branch.

I never liked those "if" statements! "IF"? Why is there an "if"? It implies you're uncertain, or have hesitations, doubts even? That's rookie shit. I never do. Straight and happy path for this cowboy, always.

If you have conditionals in your program, it means that you're trying to do too many things at once. Follow the UNIX philosophy: do one thing, and do it well!

And always run every program and always pass every option! Do everything well!

A for loop also is an implicit branch, by the way. At least it will be compiled to something with a conditional jump.

So being unsure about how many times you want to do a thing is a no-go too.

Not if it's a known constant trip count, then you can fully unroll it. No more branches!

If the trip count isn't known at compile time? You should find out.

No branches if you movfuscate[1] your code! You do end up with that happy path, that straight path, that clean path that's wholly immune to those pesky branching bugs.

1: https://github.com/xoreaxeaxeax/movfuscator

Yea, if true, you can go ahead and stick a fork in AMD.

Reply on news.ycombinator.com