Re: GRUB trusted boot framework

[Jan Alsenz <janalsenz@student.ethz.ch>]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

Vesa Jääskeläinen wrote:
> Jan Alsenz wrote:
>> Vesa Jääskeläinen write:
>>> I do like the idea what some protected systems use, they sign the binary
>>> (in our case .mod file and kernels of loaded OSes). Now in that scenario
>>> it is responsibility of the kernel module loader to first verify the
>>> signature for correctness. This way the signature checking would be
>>> somewhat transparent to the rest of the system.
>>>
>>> I do not see a need to add any hooks to disk read. It should be
>>> responsibility of the code needing signature checking to handle that.
>> Well, since to trusted operation should be transparent (and in my opinion should
>> not need code changes in something like the loaders - so if someone writes a new
>> loader, it should work by default), that's where the hooks come in.
>> Maybe the "disk read" was misleading, what I meant where "file reads".
> 
> Hi,
> 
> Well.. you probably don't want to verify authenticity of the fonts or
> bitmaps in graphical menu?

Oh, I want!
If I remember correctly, exactly this broke the protection on some game console!


> Anyway. I think the right place for verification hook in this case is
> the module or OS kernel loader.
> 
> If you think otherwise. Then you have to provide a complete technical
> design how it should work as I see no other good choice for it.
> 
> (actually there is one other place that could be used, but I let you
> come up with the idea after you have given a bit more though on the
> implementation side :))

But how do I get it into every possible loader?

My current suggestion would be to put a hook possibility into kern/file.c and
extend the fs interface with a function to compare to files, to get rid of the
double hashing problem mentioned by phcoder.

I also checked the loopback code and it uses the standard grub_file_read, so for
these cases a read version without a hook would be needed.

By the way we're assuming here, that every file-system driver is free of
exploitable bugs!
To avoid this a real disk read hook would be needed, but of course that is
largely impractical. (There might be options with "sparce" hashing - meaning
only hashing the parts that are actually read, and including the map of read
areas into the final hash)

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]