3 ms·

>Branch prediction is great except in the rare cases where it isn't. Sure, is there any CPU feature that this does not apply to? >I wouldn't want to see it re

by ksk 8y ago

>Branch prediction is great except in the rare cases where it isn't. Sure, is there any CPU feature that this does not apply to? >I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it. Its hard to parse what your exact request is here. Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Or do you want to just disable it? But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms.

lmm 8y ago
> Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Sure, though hopefully that's something a compiler could do. What I'd like is to be able to write a compiler that could understand the difference between as-fast-as-possible code (most code) and constant-time code, and build the latter correctly. > But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms. There are other holes, sure. That's not a reason not to fix the biggest hole. We'll fix the smaller holes in turn.
- ksk 8y ago
  >What I'd like is to be able to write a compiler that could understand the difference between as-fast-as-possible code (most code) and constant-time code, and build the latter correctly. If you want your compiled code to rely on the internal design of the CPU then its going to be tightly coupled to one particular CPU. CPU Upgrade -> code no longer works. Oh you ran the software on your laptop which has Core i5 instead of Core i7 -> Code no longer works. Oh your S/W Vendor went out of business and you purchased a new machine with a different CPU -> No working code for you. >There are other holes, sure. That's not a reason not to fix the biggest hole. OK, please propose a solution then. Or are we merely arguing over hypotheticals and lamenting the fact that stuff isn't secure? If so, yeah, stuff isn't as secure as any of us would like it to be! That doesn't get us anywhere though.
  - lmm 8y ago
    > If you want your compiled code to rely on the internal design of the CPU then its going to be tightly coupled to one particular CPU. CPU Upgrade -> code no longer works. Oh you ran the software on your laptop which has Core i5 instead of Core i7 -> Code no longer works. Oh your S/W Vendor went out of business and you purchased a new machine with a different CPU -> No working code for you. Indeed. Better that than CPU Upgrade -> silently leak your private keys, which is what we currently get. > OK, please propose a solution then. I've been proposing a solution this whole thread: publish enough information about exact CPU behaviour to allow a (specialised) compiler to produce reliably constant-time code, even if only for a single CPU model at a time.
    - ksk 8y ago
      That is not a solution though. Its your personal wish list. Neither Intel nor AMD is going to publish their CPU design. No consumer is going to purchase/use software that arbitrarily breaks. Its as unrealistic as someone saying don't release any software with bugs. A solution recognizes the reality of the current situation. You'll have to figure out how to get all parties on-board your agenda. I don't expect you to come up with one right this moment, but I did want to challenge your position.

by ksk 8y ago

lmm 8y ago

> Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Sure, though hopefully that's something a compiler could do. What I'd like is to be able to write a compiler that could understand the difference between as-fast-as-possible code (most code) and constant-time code, and build the latter correctly. > But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms. There are other holes, sure. That's not a reason not to fix the biggest hole. We'll fix the smaller holes in turn.

ksk 8y ago
>What I'd like is to be able to write a compiler that could understand the difference between as-fast-as-possible code (most code) and constant-time code, and build the latter correctly. If you want your compiled code to rely on the internal design of the CPU then its going to be tightly coupled to one particular CPU. CPU Upgrade -> code no longer works. Oh you ran the software on your laptop which has Core i5 instead of Core i7 -> Code no longer works. Oh your S/W Vendor went out of business and you purchased a new machine with a different CPU -> No working code for you. >There are other holes, sure. That's not a reason not to fix the biggest hole. OK, please propose a solution then. Or are we merely arguing over hypotheticals and lamenting the fact that stuff isn't secure? If so, yeah, stuff isn't as secure as any of us would like it to be! That doesn't get us anywhere though.
- lmm 8y ago
  > If you want your compiled code to rely on the internal design of the CPU then its going to be tightly coupled to one particular CPU. CPU Upgrade -> code no longer works. Oh you ran the software on your laptop which has Core i5 instead of Core i7 -> Code no longer works. Oh your S/W Vendor went out of business and you purchased a new machine with a different CPU -> No working code for you. Indeed. Better that than CPU Upgrade -> silently leak your private keys, which is what we currently get. > OK, please propose a solution then. I've been proposing a solution this whole thread: publish enough information about exact CPU behaviour to allow a (specialised) compiler to produce reliably constant-time code, even if only for a single CPU model at a time.
  - ksk 8y ago
    That is not a solution though. Its your personal wish list. Neither Intel nor AMD is going to publish their CPU design. No consumer is going to purchase/use software that arbitrarily breaks. Its as unrealistic as someone saying don't release any software with bugs. A solution recognizes the reality of the current situation. You'll have to figure out how to get all parties on-board your agenda. I don't expect you to come up with one right this moment, but I did want to challenge your position.