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
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
