161–170 of 248 posts
Isn't it the case that the Itanium architecture would not be vulnerable to Spectre because it moves the onus of branch prediction from the CPU to the compiler?
Assuming the compiler knows what it's doing :)
Earlier quoted context omitted.
Sounds like it's time for me to give up on the so-called "modern web" and install noscript.
You can have both "modern web" and block most JavaScript. You just need to keep adding scripts to the whitelist until sites you trust work again. It's a bit arduous at first, but possible to get used to once everything you visit daily has been added.
Earlier quoted context omitted.
It's not that it makes the practice of breaking into computers that much more interesting so much as it makes the underlying field much more interesting to work in. The engineering problems just got a lot more complex. We're all taking an attack vector seriously --- microarchitectural side channels --- that we weren't taking as seriously before, except as an abstract threat to crypto and a way of defeating a mitigati…
> they didn't have the cycles to write everything down! hahaha that was a good pun! Do you have a link to Jann Horns personal blog or Github? I've not never heard of him before.
Earlier quoted context omitted.
Legitimate question: on any non-shared non-virtualized system is there any reason to enable these workarounds besides running sandboxed applications such as javascript in a web browser (or flash/java applets/Active X, but those are not really super popular nowadays)? For any other non-sanboxed application you pretty much have to trust the code anyway. Privilege escalation is always a bad thing of course, but for sing…
> on any non-shared non-virtualized system is there any reason to enable these workarounds Does the non-shared non-virtualized system have any encryption keys in memory that you want to protect? Do you use full-disk encryption or ssh to other machines or use a cryptocurrency wallet?
I don't think this particular vulnerability significantly increases the surface of attack for any non-sandboxed application running on my computer. There are much easier and straightforward ways to get access to anything an attacker with shell access may want that don't involve dumping the kernel VM. So in my situation the only vector of attack I'm worried about is JS running in the browser since I gave up on javascript whitelisting long ago when I realized that most of the web is unusable when you don't allow heaps of untrusted scripts to run all over the place. I don't have time to audit the source code of every random website I visit.
Earlier quoted context omitted.
Legitimate question: on any non-shared non-virtualized system is there any reason to enable these workarounds besides running sandboxed applications such as javascript in a web browser (or flash/java applets/Active X, but those are not really super popular nowadays)? For any other non-sanboxed application you pretty much have to trust the code anyway. Privilege escalation is always a bad thing of course, but for sing…
This unfortunately also affects almost all mobile apps and modern Windows installations, as they all run Javascript-enabled ads. Maybe this might cause Microsoft to reconsider what it allows to run on Windows but I don't see mobile ads going away any time soon.
Good opportunity to get rid of them.
Earlier quoted context omitted.
That's bad. A single 5% hit might not be the end of the world, but 5% here and 10% there and another 5% over there in the common case adds up badly enough. Doubly-pathological cases (indirect calling-heavy code calling lots of syscalls)... a 50% slowdown and a 30% slowdown combines to a 60% total slowdown. Yeowch. Will be intrigued to see how processor manufacturers respond to this. If they were even slightly relaxed…
Sounds like it could be great for processor manufacturers. In the age where CPUs don't get faster, there's finally a reason for customers to buy new CPUs again!
When this all shakes out, the general story is going to be "upgrade sooner, current-gen Intel chips are x% faster", where x is going to be a larger number than it was a week ago.
It's more-or-less the Apple battery story all over again. Current devices are going to be slower, newer ones are going to be faster. Even if you know the why and the how, you're still in the same place as everybody else (at best, you could upgrade just the chip if your MB is new enough, but you're still buying Intel). Unless there's some clear way of imposing the external cost of this bug on Intel, it's a win-win for them.
Earlier quoted context omitted.
That won’t really be a problem for the cloud providers. That simply charge more because the customers will use more compute.
Which in some cases might make it cheaper for customers to use their own hardware, resulting in cloud providers losing business.
Earlier quoted context omitted.
How about not running untrusted code? That seems to be much easier to do and won't kill performance. Kill js on the web. Run only apps signed by Microsoft. Develop ML based malware fingerprinting that can recognise timing attack patterns. Throwing OO execution away shouldn't be an option in the long term.
It's not just "untrusted code" any more. The "true secure" way is not running any untrusted code, not connecting to any untrusted networks, and not accepting or storing any untrusted data. At that point you can't run a computer. It's just not an answer to say "don't let bad things in" because bad things are always going to get in. And with side channel exploits getting more and more common, and with them being worse…
Earlier quoted context omitted.
And I fear there's little reason to think that the "three variants" from project zero's announcement are the full scope of the problem. They were just the variants that the few people in on this found time to develop exploits for. There can now be security bugs in things your program doesn't do; it seems like there is room for nearly unlimited creativity in finding them. From the spectre paper: "A minor variant of th…
> d I fear there's little reason to think that the "three variants" from project zero's announcement are the full scope of the problem. Agreed. This is an entirely new class of vulnerabilities, and we're just at the beginning.
Earlier quoted context omitted.
>Its hard to get your head around how big a deal this is. It truly is difficult to predict all the ripple effects from this. I can't think of a single computer bug in the last 30 years that's similar in reach to this Intel Meltdown. [EDITED following text to replace "Intel bug" with "Spectre bug" based on ars and jcranmer clarification. The Intel Meltdown can be fixed with operating system update patches for kpti ins…
That won’t really be a problem for the cloud providers. That simply charge more because the customers will use more compute.