OSDev.org

Hi,

Solar wrote:

azblue wrote:What else can I do? If it's corrupted I can't trust it to output any sane message (I can't trust it to do anything).

Undefined behaviour is undefined, if your code is corrupted it is corrupted. You can't do jack about that.

Try to cover your bases as best you can, but don't fret about those parts you can't do "safely".

I was going to say that it's a little bit like asking a person if they're a liar - an honest person will tell the truth and say "no" and a liar will lie and say "no".

If you're concerned about security, there is one thing you can do: use a third party. This is (part of) what the TPM chip was intended for. The idea is that the MBR asks the TPM chip to create a glorified checksum of the VBR before the VBR is executed; and later on something else can determine if the value in the TPM chip is the same as it should be (and if it's not the same as it should be, assume that the VBR was tampered with).

Of course in practice it's more complex - an attacker could tamper with the MBR so that the MBR modifies the VBR after the VBR's checksum was created but before the VBR is executed, so that the VBR's checksum is correct even though the VBR was modified. To guard against this you end up with a "chain of trust"; where you end up with a glorified checksum of each step in the chain (starting with the firmware itself) and where the checksums for later parts of the chain can only be trusted if all earlier parts of the chain can be trusted. It's not exactly pretty...


Cheers,

Brendan

TPM got a really bad rep back in the day, because it could be used to lock other operating systems out of the boot process, or even deny installation to "unsigned" applications -- with the certification in the hands of the OS provider (a.k.a. Microsoft). Microsoft never went as far as actually implementing Windows that way, but I am rather sure they only didn't because of the boiling kettle they suddenly had on their hands.

It's also been attacked successfully.

Hi,

Solar wrote:TPM got a really bad rep back in the day, because it could be used to lock other operating systems out of the boot process, or even deny installation to "unsigned" applications -- with the certification in the hands of the OS provider (a.k.a. Microsoft). Microsoft never went as far as actually implementing Windows that way, but I am rather sure they only didn't because of the boiling kettle they suddenly had on their hands.

Yes.

It is/was also seen as "not ideal" for security for a few reasons - mainly, that "chain of trust" is fragile and depends on too much (which is something AMD fixed with "dynamic root of trust" since); and the fact that it's retroactive (code that's been tampered with is executed, then checks are done after the code is executed) and not preventative (refusing to execute code that's been tampered with - e.g. like SecureBoot).

Solar wrote:It's also been attacked successfully.

Some implementations have been successfully attacked, but implementations of almost everything have been successfully attacked - if we waited for "guaranteed 100% secure" we'd be waiting forever.

The real question is, does using TPM to make it harder for an attacker to tamper with boot code? You'd have to assume that using TPM gives better security than not using TPM; even if TPM can be broken by a child in less than 1 minute.


Cheers,

Brendan

Somewhat akin to security offered by automatic surveilance cameras.

Do they provide more security than we would have without them?

To some degree, certainly, if perhaps only retroactively, perhaps only subjectively ("false security").

Is that a reason to accept the issues and drawbacks involved? Do we want to give this tool to whoever holds power over it? Now there is a question...