Re: GRUB trusted boot framework

[phcoder <phcoder@gmail.com>]

> Oh, I want!
> If I remember correctly, exactly this broke the protection on some game console!
Do you refer to Xbox crack based on King kong game? For once their goal 
is the evil one. For second the problem is a buffer overflow in 
rendering engine, not the not checking part. If you want to make a 
secure system it must be free of such bugs. Or you may as well hash the 
whole hd and be hacked through network code. Here is where advantages of 
open developement come in play
> 
> But how do I get it into every possible loader?
s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPARENT)
s/grub_file_open(filename)/grub_gnupg_open(filename, 0)

> 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.

Then how is your proposition with two file read functions different from 
mine with two file read functions? What can be proposed is to merge 
somehow all opening functions into one with following protype
grub_file_open (const char *filename, int flags, struct grub_file_info 
*info)
Then on opening the function will do the default behavior with possible 
override possible through flags. It has an advantage of future 
expandability for possible new transparent transformations

> 
> 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)
And then after a minor write or fs self-maintenance it suddenly stops 
working. You may as well not boot at all. Perfectly secure booter in 2 
bytes of x86-assembly:
eb fe :   self: jmp self
> 
> Greets,
> 
> Jan
Regards
Vladimir 'phcoder' Serbinenko