Re: GRUB trusted boot framework

[phcoder <phcoder@gmail.com>]

Jan Alsenz wrote:
> phcoder wrote:
>>> 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
> 
> It is totally irrelevant, if the purpose is good or evil, if it can break the
> system.
> And since it is awfully difficult to produce bug free code, the goal must be to
> reduce the code that has to be bug free to the absolute (and openly known)
> minimum: In this case I'd say the reasonable choice is the fs driver code.
> 
You can't really do this. You can safeguard from e.g. fonts drivers 
bugs. But what do you do with vulnerabilities with usb code. Some may 
connect an evil mouse to the computer
>>> 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)
> 
> With "every possible loader", I wanted to include unknown future loaders.
> 
New loaders will use the existing ones as a template. I did
> That would be a good idea.
> The difference between your and my solution was, that mine it had secure as default.
Mine too. It involves just using right code. If a developer wants to 
wrote unsecure code he can always, otherwise I don't see why he wouldn't 
use e.g. linux loader as a template
> - (It may be useful to have some order within the hooks)
It's even necessary. Otherwise you can't know if you have first to 
compress or to sign