[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GRUB trusted boot framework
From: |
Jan Alsenz |
Subject: |
Re: GRUB trusted boot framework |
Date: |
Sun, 22 Feb 2009 20:16:15 +0100 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090104) |
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
signature.asc
Description: OpenPGP digital signature
Re: GRUB trusted boot framework, Vesa Jääskeläinen, 2009/02/22
- Re: GRUB trusted boot framework, Jan Alsenz, 2009/02/22
- Re: GRUB trusted boot framework, Vesa Jääskeläinen, 2009/02/22
- Re: GRUB trusted boot framework,
Jan Alsenz <=
- Re: GRUB trusted boot framework, phcoder, 2009/02/22
- Re: GRUB trusted boot framework, Jan Alsenz, 2009/02/22
- Re: GRUB trusted boot framework, phcoder, 2009/02/22
- Re: GRUB trusted boot framework, Jan Alsenz, 2009/02/23
Re: GRUB trusted boot framework, Robert Millan, 2009/02/27