zlacker

[return to "Toward a Reasonably Secure Laptop"]
1. d33+y5[view] [source] 2017-07-11 12:35:59
>>doener+(OP)
If I read that right, they're allowing Intel ME, which sounds like a sad compromise to me. Given that it's a pretty big complex black box that one can't easily disable, would you agree that x86 is doomed when it comes to security? If that's the case, is there any hope we could have a CPU with competitive capabilities? (For example, is there an i7 alternative for ARM?)

What could one do to make it possible to have ME-less x86 in the future?

◧◩
2. zer0to+m7[view] [source] 2017-07-11 12:52:15
>>d33+y5
I think the whole point of Qubes OS is t not trust hardware because of potential BIOS or ME backdoors.

Joanna Rutkowska, Qubes founder, is the person who brought up intel ME as a problem in her paper Intel x86 considered harmful (https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf).

◧◩◪
3. adrian+ti[view] [source] 2017-07-11 14:21:22
>>zer0to+m7
You can't run trusted software on untrusted hardware. If someone has a backdoor in your ME, you can't protect yourself from it.
◧◩◪◨
4. falcol+xn[view] [source] 2017-07-11 14:57:14
>>adrian+ti
I'm curious: if we can solve the "trusting trust" problem - that is identifying compromised compilers, even if the other compiler is compromised - couldn't we potentially solve this problem in a similar way?
◧◩◪◨⬒
5. jancsi+Mw[view] [source] 2017-07-11 16:03:44
>>falcol+xn
Ignoring for the moment all the indeterminism on a running laptop, the main reason is that we don't have the tooling to do that.

For example: compiler is to software as X is to hardware. What is X? And how does one go about creating their own X?

◧◩◪◨⬒⬓
6. falcol+3X[view] [source] 2017-07-11 18:51:48
>>jancsi+Mw
Ultimately a compiler is just a bit of software; one that takes inputs and produces outputs. The identification of compromise is the difference in outputs for the same inputs (simplified, of course).

So, given we can control most inputs to hardware, and most outputs, it seems possible to objectively identify when the HW is misbehaving (such as "A" produces network output that "B" does not). It wouldn't nail down which piece of hardware was compromised, but it would help identify that hardware is compromised.

It will never be _that_ easy, of course... but it seems possible.

◧◩◪◨⬒⬓⬔
7. jancsi+Ln2[view] [source] 2017-07-12 13:38:51
>>falcol+3X
> It wouldn't nail down which piece of hardware was compromised, but it would help identify that hardware is compromised.

Do TCP timings and retransmissions count as difference in outputs?

[go to top]