Re: GRUB and the risk of block list corruption in extX

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

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

I haven't gone through this whole thread yet but this is one of problems
with blocklist installs:
Suppose blocklist changes because of e.g. user mistake. Yet at the old
location there is still the old core.img. For the time being. So this
problem may go unnoticed for years yet if someone has the ability to
create new files on the disk in question, he creates ton of files with
copies of malicious sector, one of them will overwrite core and be
executed on next reboot.
This is a securitxy problem coming from the fact that in normal
environment blocklists are abstracted away into files and are no longer
either visible or considered, yet they are still manipulated. embedding
zone doesn't have this problem since it's by definition never manipulated.
Another trouble is that ext4 devs control only their own implementation.
But there are several more floating around. Once we had problems because
hurd ext2 behaviour is different from Linux one. Additionally, as long
as behaviour of not modifying blocklists of core.img isn't specified as
official implementations which would do so (specifically the cow
flavours) are within their rights.
It's possible to add ext4 parsing to boot sector but it's not sure that
it will be maintainable in face of new ext* features.
A possibility is to use 2 unused sectors in front of ext* to store
initial stage but it doesn't help if embedding isn't available for other
reasons than installing to partition.
Having embedded zone described by an inode is unusual but is usable as
long as:
1) special sector allocation. It must be (at least, preferably more)
4K-aligned (necessary for supporting 4K-sector disks) and contiguous.
Either:
2a) miniature parser in boot.S to find this file. Greatly simplified if
inode is fixed, since fs parameters are fixed it would be a
straightforward of value read.
2b) immutability of blocklist. This also implies that this file can't be
shrunk or deleted.


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