4 ms·

I'm sure there are plenty of EE types here who can tell you how to refine silicon, design and print a circuit, program in binary, assembly, C, and high level la

by wisty 5y ago

I'm sure there are plenty of EE types here who can tell you how to refine silicon, design and print a circuit, program in binary, assembly, C, and high level languages, explain network stacks, and build a web app. But really, can anyone really explain how computers work nowadays? Look at how optimisations in cache stuff on the CPU led to horrible security flaws, surely that should be obvious if anyone really knew what was happening under the hood?

tremon 5y ago
Everything is obvious in hindsight; these "horrible security flaws" you speak of are only a problem now because we're treating software as adversarial. If the machine's owner is 100% in control of the software that runs on the CPU, there is no security boundary between the CPU and the software running on it, so there is no need to even entertain the notion of leaks through speculative execution. Ubiquitous software delivery from questionable sources is the problem, that's what invalidated the design assumptions underlying the cache optimisations. You might argue that it is the hardware designer's fault to not see how the software world would change in the next 20 years, but you can similarly argue that it's the software designer's fault to not keep in mind the security limitations of the processor it's running on.
- wisty 5y ago
  Not really. Timing attacks are not all that hard to understand - if the timing (or anything else) a user sees depends on information they shouldn't be able to see, then there's a (theoretical, at least) information leak and that's a security flaw. I'm not a security expert, and this is something that's always in the back of my mind when considering security. It's ... one of the only things in the back of my mind - you need a constant time string compare for passwords is the most obvious example (and one that literally any decent programmer should be somewhat aware of). I only know the basics of security, and this is one of the basic principals. It's up there with "escape strings". People simply don't think about every layer of the stack. If they did, then it would be obvious (but there's so much in the stack that this is infeasible). JavaScript came out in 1995. Timing attacks on the CPU have been feasible since them (and heck, if you go back further then everything was terminals and multi user operating systems anyway). There's never been a time when CPUs haven't run potentially hostile operations. But virtually no-one (myself included) thought "can a timing attack happen"? despite timing attacks being a very common type of attack.

by wisty 5y ago

tremon 5y ago

Everything is obvious in hindsight; these "horrible security flaws" you speak of are only a problem now because we're treating software as adversarial. If the machine's owner is 100% in control of the software that runs on the CPU, there is no security boundary between the CPU and the software running on it, so there is no need to even entertain the notion of leaks through speculative execution. Ubiquitous software delivery from questionable sources is the problem, that's what invalidated the design assumptions underlying the cache optimisations. You might argue that it is the hardware designer's fault to not see how the software world would change in the next 20 years, but you can similarly argue that it's the software designer's fault to not keep in mind the security limitations of the processor it's running on.

wisty 5y ago
Not really. Timing attacks are not all that hard to understand - if the timing (or anything else) a user sees depends on information they shouldn't be able to see, then there's a (theoretical, at least) information leak and that's a security flaw. I'm not a security expert, and this is something that's always in the back of my mind when considering security. It's ... one of the only things in the back of my mind - you need a constant time string compare for passwords is the most obvious example (and one that literally any decent programmer should be somewhat aware of). I only know the basics of security, and this is one of the basic principals. It's up there with "escape strings". People simply don't think about every layer of the stack. If they did, then it would be obvious (but there's so much in the stack that this is infeasible). JavaScript came out in 1995. Timing attacks on the CPU have been feasible since them (and heck, if you go back further then everything was terminals and multi user operating systems anyway). There's never been a time when CPUs haven't run potentially hostile operations. But virtually no-one (myself included) thought "can a timing attack happen"? despite timing attacks being a very common type of attack.