What other "trustable" things are "untrustable"?
Only all of them ...
tpm.fail/

@theruran @thegibson @yojimbo And now people know why I don't / won't support things like secure boot and such on the Kestrel. The only security possible is utter transparency and the willingness to periodically check your code. Impractical? Maybe. But, so is 6 MIPS performance these days, so who cares?

Not that I will prevent others from forking and/or porting their own implementations. But me? Nope. Not gonna happen.

Follow

@vertigo @theruran @thegibson @yojimbo Not that secure boot is necessarily a panacea, but check your code... how, exactly? And how do you catch some malicious firmware change before it ransomwares you or leaks all your secrets? One of the things secure boot tries to do is to check the code on every boot to make sure your computer is running the code you (or MS and Intel usually) think it is.

@freakazoid @vertigo @theruran @yojimbo

The entire world must move to some form of EDR.

Our best defense is protecting from these attacks by dynamically stop malicious code execution by pattern recognition.

@thegibson @freakazoid @theruran @yojimbo In the case of the Kestrel, the system firmware is, as far as the FPGA is concerned, located in mask-programmed ROM. Not flash. There is *no* write ability from the Kestrel itself to the system's flash chip.

Meaning, the only way to compromise the flash is to gain physical access to the computer, take it apart, desolder the chip, solder a new chip in it's place (or reprogram and resolder).

@vertigo @theruran @thegibson @yojimbo Some hardwired module that could just display a cryptographic checksum of the firmware might be good enough, maybe? Perhaps using a keyed MAC of some kind so you only need a few digits because a remote attacker won't be able to determine the key?

@freakazoid @theruran @thegibson @yojimbo In practice, however, it doesn't protect anyone from ransomware (as evidence by the number of people still getting hit by it), and in my first-hand experience, only results in bricking the machine when trying to upgrade to a newer version of Linux when using ASUS motherboards.

*shrug*

Let's just agree to disagree on this matter. I don't foresee any of us coming to an agreement here.

@vertigo @theruran @thegibson @yojimbo I think the main threats secure boot is supposed to handle involve getting "underneath" the OS. Ransomware usually doesn't need to do that because of discretionary access control; it gets access to everything the user who executed it could access. The use case with ROM is for when you chain to some piece of software in mutable storage, which you almost always need to do.

Sign in to participate in the conversation
R E T R O  S O C I A L

A social network for the 19A0s.