Earlier quoted context omitted.
And yet, my abacus is even more secure ;-)
Only if you wear gloves while using it and shake it after finishing a calculation.
Been reading Cryptonomicon, have we?
Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
201–210 of 232 posts
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#202I understood everything up until the "suppose we flush our cache before executing the code" part which is probably the most important part. There was a comment below the article that explained this part a little further: > Imagine the value at the kernel address, which gets loaded into _w, was 0xabde3167. Then the value of _x is 0x100, and address user_mem[0x100] will end up in the cache. A subsequent load of user_me…
Yes, that is the this is left as an exercise for the reader part of the explanation. (-: The remaining part is to iterate the process over all of the bits in the word, using different bitmasks. The resultant set of 0 or 1 results for each bit yields the complete word. Then one iterates that whole process over all (useful) words in (mapped) kernel memory.
How might one know which address to attack like this? I thought memory was fairly randomly laid out.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#203Earlier quoted context omitted.
> It isn't funny or witty to point out that an Opel Corsa gets better gas mileage than a 747 Actually, if it's true that a car gets a better mileage than a big airplane (more in one vehicle = more efficient, people seem to believe) I would find that interesting. Similarly, I can see how OP thinks it's ironic that a very cheap machine is not vulnerable whereas a quite expensive piece of equipment is, making it seeming…
Transatlantic flights average 75 mpg per passenger, but can be up to almost 100 mpg per passenger: https://en.wikipedia.org/wiki/Fuel_economy_in_aircraft Jet fuel is 37.4 MJ/L; compare to gasoline at 34.2: https://en.wikipedia.org/wiki/Energy_density#Energy_densitie... An electric car will have up to 150 miles-per-gallon equivalent (aka 150 miles per the same amount of energy that's in one gallon of gasoline): https:…
You already started along the road to normalisation by using MJ/L but you might as well go the whole way and consider absolute cost per person per mile... or person miles per absolute unit cost if you prefer. Those might be more telling figures.
For instance many EV proponents note the total cost of ownership difference due to significant differences in maintenance costs. Playing the other side of the argument: they tend to forget about the value of upfront cost is more than later cost.
It's still possible to achieve some sort of quantitative comparison by applying an interest rate based on "distance" of the cost in time before summing them. If you applied this to a regular petrol car you might be able to make a better comparison to the ticket price of a flight.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#204Earlier quoted context omitted.
Right, but at a cost of a leaky cache abstraction. Which is now hugely expensive to work around, making me question how that ever got approved if the security model was clearly leaking at that point (which has been known for the entirety of speculative execution, right?)
> how that ever got approved if the security model was clearly leaking When you consider a theoretical model of the CPU, then it's not leaking - the speculative execution, cache, other parts of the CPU are designed carefully so that no data can "escape" and be read by processes that don't have the permission to do it. Speculated execution can happen, but before any results from that are released, the permissions are…
I may be wrong, but the timing attack only reveals the cache line, but being able to read the cache line is something itself I would expect to fail even without the timing attack. How does that not cause an exception?
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#205Earlier quoted context omitted.
"Considering that on average you have a branch every 5 instructions and the reorder buffer of high performance OoO CPU is in the order of a hundred of instruction, such a CPU is pretty much running under speculation all the time (often of multiple branches at the same time)." Yes, it is. Remember, again, that the vast majority of those instructions can still be speculated, because the vast majority of instructions ar…
I doubt that any CPU manufacturer is going to go first in crippling its memory subsystem. I think realistically the only safe and not completely performance crippling workaround will be, at the very least, to run any untrusted code under a separate address space (assuming that the cpu is immune from meltdown). That doesn't necessarily require a full blown separate process, but something like memory protection keys mi…
Yeah, i don't disagree at all.
Something like this what i meant by "cooperation" (lfence or equivalent for code that can't be isolated but must be protected) + "weird abstractions" (IE back to segmented land we go)
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#206How many RPi users are using this board to run untrusted code?
The RPi may mitigate risk of these attacks simply in the way it is used.
Perhaps hobbyists use it to run their own small programs, not random third party Javascript in an enormous web browser from some corporation.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#207Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#208Fantastic read. Before reading the article, I assumed there were many HN readers who were extremely proud about their Raspberry Pi being invulnerable to Spectre or Meltdown
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#209Ok I think I understand the subtleties of these attacks now. But: can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? If that happened then none of these attacks would be possible. I got my computer engineering degree in 1999 and ended up going the computer science route making CRUD apps all day. I feel in my gut that some engineer, somewhere,…
> can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? From what I understand, it does happen on AMD, which is why AMD CPUs are not vulnerable to the more dangerous Meltdown attack (any code reading kernel / hypervisor host memory). Intel / ARM delays the checks until later, to the time when the speculated instructions are actually finalised an…
> This means that all sorts of sandboxing methods for javascript interpreters, bytecode interpreters, plugin architectures, etc are insecure.
I just now understood the impact of Spectre. It is not just that all existing attempts to execute code in a sandbox are vulnerable. For CPUs with this problem, it is literally impossible to create a secure sandbox.
We certainly live in interesting times...
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#210Earlier quoted context omitted.
Right, but at a cost of a leaky cache abstraction. Which is now hugely expensive to work around, making me question how that ever got approved if the security model was clearly leaking at that point (which has been known for the entirety of speculative execution, right?)
> if the security model was clearly leaking at that point The leak is only clear in retrospect. Many, many things are only clear after you see how they were done. It has been twenty years since processors with this vulnerability started appearing. Over those two decades, thousands of very smart engineers (including state-sponsored ones) have collectively spent millions of hours of analysis trying to find security fla…
Colin Percival found a similar problem with Intel's implementation of "HyperThreading" back in 2005:
http://www.daemonology.net/hyperthreading-considered-harmful...