@kakaroto maybe you are the one who i’m asking this stuff, but if anyone else on purism crew know something about it, everyone is welcome
i saw this video and i’d like to know if and how do you manage this hidden/unknown code with librem product, is it a part of deblobbed/deactivated stuff you do with coreboot or is other things? and if is other things there is a way to isolate/deactivate?
i’m not a technical guy so my understanding is not high like yours, but i’d like to understant more about it, and hear something from you about this
What is the question exactly ? because you reference the video but believe me, I do not have 45 minutes to spend watching the video just to understand your question, so can you clarify it please ?
From a quick look at the description of the video though, I think he’s referring to x86 instruction fuzzing (similar to what this does : https://github.com/xoreaxeaxeax/sandsifter or maybe that’s what he’s talking about… or maybe not at all actually). In which case, that’s about x86, and I don’t see what your question is relating to librems.
Actually, this is teh presentation at Blackhat about sandsifter.
I am thinking the question relates to what can be done to protect against these undocumented instructions. Without knowing what all these possable instructions do there really is nothing that can be done.
True, probably not much that can be done.
On the other hand, there is not much danger.
If you can trust all of the code on your device, including the compiler that built it, you can be pretty sure hidden commands will never be executed.
Just like the existence of the dd command is not a problem per se
Thanks, for the link!
Domas did the hard part, now setting up an open database with undocumented instructions per chip model, and a tool to scan your system binaries should be trivial isn’t it?
We are not there yet https://github.com/rigred/sandsifter-tests
Does the interaction between hidden instructions and microcode look like an interesting research topic to you?
You are completely wrong. It is very easy to design hardware to completely own you in an undetectable fashion. This is also why all military chips need to have a verifiable production chain.
Now, whether or not such hidden attacks are lurking somewhere in the chips of hundreds of millions of consumers (next to the Intel ME) is an open question, but it’s certainly possible.
We are talking about undocumented instructions, not about hidden subsystems. Therefore I said as long as you trust all the code, it’s not a big deal. Assume there is a hidden instruction that somehow allows userland code ring-0 access. That’d be troubling, but not too bad if you trust all the code - and only if you are the only user of the system
