271–280 of 349 posts
How much slower would processors be if they got rid of all complex / risky optimizations? How much performance could we gain back with more expensive components, more integration (e.g. SoCs), and other approaches that are unlikely to lead to security problems?
Earlier quoted context omitted.
It seems to me like most don't have a fundamental gut feel for what speculative execution actually is and the implications of "not getting it". At some level we need to fight for performance. My operating systems are only getting slower and shittier. I cannot fathom my CPUs going backwards too. Security must take a back seat at some point. You can't put bubble wrap and warning labels over everything or it becomes use…
> Why should everyone else on earth have to suffer crappier performance by default because of the business/software practices of a select few? The author states in the article that they believe this may be exploitable from javascript in a browser. Just to hammer the point home, any web page could steal anything in memory on your computer. Spectre was also browser-exploitable, and was mitigated there partly by making…
You could hijack a user that has SAPGUI open, then push code updates to SE38 that spread everywhere.
Earlier quoted context omitted.
> Native mobile apps thrive despite this magical web browser working everywhere There’s also user behavior. Many users are conditioned to get software through the App Store. I’ve seen this be a driving factor for quite a few web native applications spinning up native dev teams and shipping native clients. Many folks are surprised to see just how far you can push a browser app and how small the gap between web and bro…
We really need to standardize "just wrapping a browser view". Why are we shipping a whole browser when we could be shipping a zip file of HTML with some metadata, and maybe a few tiny native helper utilities?
For mobile apps you can use webview component which will use system browser. You don't need to ship the entire browser (actually you can't even do that on iOS).
Earlier quoted context omitted.
If I'm reading this right, the caveat is that the exploit only lets you read registers that have been saved for context-switching. So, in order to extract data, that data must be in constant active use (i.e. loaded in a register) at the time of the attack.
Would environmental variables be something that shows up in context-switching?
Once again it seems clear that running code from two security domains on the same physical processor cores is just not possible to get right, and we should probably just stop doing it. There are really only two common cases for this anyway. VMs and JavaScript. For VMs we just need to give up on it. Dedicate specific cores to specific VMs or at least customers. For JavaScript it’s a bit harder. Either way, we need to…
There’s a marketing opportunity here to put multi-core back in the spotlight. Most workloads have reached the point of diminishing returns for adding more cores to a CPU, but if it turns out we need more cores just so we can run more concurrent processes (or browser tabs) securely, then here come the 128-core laptop chips…
What I find odd is that after the initial Spectre attacks, there have been a long string of these attacks discovered by outside researchers and then patched by the chipmakers. In principle it seems like the chipmakers should hold all the cards when it comes to discovery: they are experts in speculative execution, know exactly how their chips work and have massive existing validation suites, simulators and internal ma…
In many ways it is a much more difficult problem too. Going back to first principles, what execution in one context could have an affect on a subsequent context? The answer is just about everything. If you really wanted to be sure you couldn't leak information between contexts, you could only ever run one privilege level on the machine at any time. Not just core, entire machine. When switching contexts, you would have to stop everything, stop all memory and IO traffic, flush all caches and queues, and idle all silicon until all temperatures had reached ambient, voltages, fans, frequency scaling had settled. Then you could start your next program. Even then there's probably things you've forgotten -- programs can access DRAM in certain ways to cause bitflips in adjacent cells for example, so you've probably got a bunch of persistent and unfixable problems there to if you're paranoid. That's not even starting on any of the OS, hypervisor or firmware state that the attacking program might have influenced. So the real answer is that you simply can't share any silicon, software, or wires whatsoever between different trust domains if you are totally paranoid.
All of these things are well known about, but at some point you make your best estimation of whether something could realistically be exploited and that's very hard to actually prove one way or another. Multiply by all possible channels and techniques.
That's probably why you see a side channel vulnerability discovered every month by outsiders, but very few architectural defects (Pentium FDIV type bugs).
That said, this issue looks like a clear miss by their security process. Supplying data to an untrusted context, even if it can only be used speculatively, is clearly outside what is acceptable, and it is one of the things that could be discovered by an analysis of the pipeline.
Contrast with the recent AMD branch prediction vulnerability, which could plausibly fall under teh category of it being a known risk but was not thought to be realistically exploitable.
As others have said though, everyone makes mistakes, every CPU and program and every engineering project has bugs and mistakes. I don't know if you can deduce much about a CPU design company's internal process from looking at things like this.
At this rate, with all these vulnerabilities and mitigations, we'll rollback CPU performance back at least 10 years.
It seems to me like most don't have a fundamental gut feel for what speculative execution actually is and the implications of "not getting it". At some level we need to fight for performance. My operating systems are only getting slower and shittier. I cannot fathom my CPUs going backwards too. Security must take a back seat at some point. You can't put bubble wrap and warning labels over everything or it becomes use…
Earlier quoted context omitted.
HTML/CSS is one of the easiest way to develop GUIs, one of the most visually flexible, and one of very few things this side of ncurses that runs everywhere. Actually, without hacks, there are probably more end user devices with a browser than a command line. It's also highly standardized. Regular programming languages have dozens of GUI toolkits, or at least one per platform. I'd rather we go the other way, and build…
> I'd rather we go the other way, and build the browser into the OS This didn't work out that great with MSIE.
But it seems to have worked great for years for Chromebooks!
What I find odd is that after the initial Spectre attacks, there have been a long string of these attacks discovered by outside researchers and then patched by the chipmakers. In principle it seems like the chipmakers should hold all the cards when it comes to discovery: they are experts in speculative execution, know exactly how their chips work and have massive existing validation suites, simulators and internal ma…
Simple to fix with a microcode update. No serious performance implications.