5 ms·

Can't trust the OS without all the code. Can't trust the code if you can't trust the compiler. Can't trust the compiler if you can't trust the CPU. Can't trust

Can't trust the OS without all the code. Can't trust the code if you can't trust the compiler. Can't trust the compiler if you can't trust the CPU. Can't trust the CPU if you can't trust the microcode. Can't trust the microcode unless you've visually inspected the die. You can't win. Make compromises that are reasonable.

oliwarner 9y ago
> Make compromises that are reasonable. When it's so easy to use a community-vetted Linux distribution, I think "reasonable" gets shunted down a layer. It's not all or nothing. Every reasonable step counts.
- abiox 9y ago
  > community-vetted i wonder if this sort of confidence makes you less-safe. something like this should've prevented heartbleed, in theory, right?
  - oliwarner 9y ago
    It's not confidence that I'm secure, it's a belief that this software development process makes me more secure. You and your friend down there seemingly have more faith that a closed source process, what, would have identified this bug before it was deployed? Why? That it would have been found by good actors first? Why? That it would have been fixed promptly? Why? Announced with disclosure of its existence and ramifications? Why? It's not a money question for this stuff either. There are hundreds if not thousands of paid engineers for known good-actors all working to break and responsibly disclose security issues in the same software stack I use. The only thing you know about the comings and goings of closed source software is when public disclosure happens (and it's later fixed). Why would I be more confident in that process? It's not good enough.
- scarface74 9y ago
  "Community-vetting" didn't stop the HeartBleed bug to linger for over a year.
  - msla 9y ago
    And we have no idea how many bugs worse than HeartBleed haven't been found yet in closed-source software.
    - astrodust 9y ago
      It depends on the development process. Some companies aggressively re-visit older code, others never look at it. Open-source is not inherently better or worse, it's all a matter of motivation on the part of the developers.
dredmorbius 9y ago
Cross-compiling and multi-device compiles are a thing.
- abiox 9y ago
  i feel like this is just shuffling concerns rather than addressing them, but i'm open to being shown otherwise.
  - dredmorbius 9y ago
    Suppose you suspect compiler A or CPU X. Recompile on compilers B and C and compare results. Or on CPUs Y and Z. In reality, there will almost certainly be differences (different compiling algos, different CPU instruction sets), but if you can pinpoint behavioural distinctions or encoding distinctions which are not explained by known compile or instruction-set distinctions, well, you've got something interesting to explore. The point being that you don't have to descend the entire stack of turtles. Just compare different stacks of turtles.
    - astrodust 9y ago
      It's going to be really hard to compare binary A vs. binary B and determine functional differences. clang and gcc emit entirely different machine code, but they do their best to be functionally identical, at least as far as their respective specs are concerned.

oliwarner 9y ago

> Make compromises that are reasonable. When it's so easy to use a community-vetted Linux distribution, I think "reasonable" gets shunted down a layer. It's not all or nothing. Every reasonable step counts.

abiox 9y ago
> community-vetted i wonder if this sort of confidence makes you less-safe. something like this should've prevented heartbleed, in theory, right?
- oliwarner 9y ago
  It's not confidence that I'm secure, it's a belief that this software development process makes me more secure. You and your friend down there seemingly have more faith that a closed source process, what, would have identified this bug before it was deployed? Why? That it would have been found by good actors first? Why? That it would have been fixed promptly? Why? Announced with disclosure of its existence and ramifications? Why? It's not a money question for this stuff either. There are hundreds if not thousands of paid engineers for known good-actors all working to break and responsibly disclose security issues in the same software stack I use. The only thing you know about the comings and goings of closed source software is when public disclosure happens (and it's later fixed). Why would I be more confident in that process? It's not good enough.
scarface74 9y ago
"Community-vetting" didn't stop the HeartBleed bug to linger for over a year.
- msla 9y ago
  And we have no idea how many bugs worse than HeartBleed haven't been found yet in closed-source software.
  - astrodust 9y ago
    It depends on the development process. Some companies aggressively re-visit older code, others never look at it. Open-source is not inherently better or worse, it's all a matter of motivation on the part of the developers.

dredmorbius 9y ago

Cross-compiling and multi-device compiles are a thing.

abiox 9y ago
i feel like this is just shuffling concerns rather than addressing them, but i'm open to being shown otherwise.
- dredmorbius 9y ago
  Suppose you suspect compiler A or CPU X. Recompile on compilers B and C and compare results. Or on CPUs Y and Z. In reality, there will almost certainly be differences (different compiling algos, different CPU instruction sets), but if you can pinpoint behavioural distinctions or encoding distinctions which are not explained by known compile or instruction-set distinctions, well, you've got something interesting to explore. The point being that you don't have to descend the entire stack of turtles. Just compare different stacks of turtles.
  - astrodust 9y ago
    It's going to be really hard to compare binary A vs. binary B and determine functional differences. clang and gcc emit entirely different machine code, but they do their best to be functionally identical, at least as far as their respective specs are concerned.