Hi Dennis,
I agree with your suggestions. To be host I love the idea to put
boot.img to mbr and core.img to sectors following it (mbr hole),
especially it was also suggested in manual.
But things are not just vulnerability considerations. We had some
discussions internally about this, we should have to consider
different scenarios and setups .. overwriting mbr would mostly likely
to cause some setup to fail (as we can't figure out what's current
setup users have, then better not touch them). Also writing to mbr
means that SUSE loaders takes control over the master boot code, well
we can chain load to other systems, but what if the chain load fail or
even loader is broken? We don't support booting into others systems ..
so let mbr do his job still .. :)
I think mbr is a feasible propose to new or single OS environment,
that is we don't need to consider multi-os booting and solid is the
only concern. Also change to use gpt is a good idea for such booting
scenario.
PS. What we taking is about "proposed location", or default location
would install. We can override it if we prefer others. :)
在 2012年3月8日上午12:22,Dennis Gallien
On Tuesday, March 06, 2012 11:18 PM Michael Chang wrote:
Where are we locating core.img, the disk's extended area just past the MBR or in a filesystem? IIRC the manual recommends the former over the latter. Both locations have vulnerabilities. I seem to recall that the master's extended area is sometimes used by MS e.g. for BitLocker, and perhaps other vendors use this space too for proprietary purposes, although these are quite unusual. But a filesystem is vulnerable to moving blocks which can render the address hard-coded into boot.img invalid.
Besides this issue, there is another vulnerability with using a filesystem - getting the address to embed into boot.img wrong in the first place. Here again grub2 has an advantage over grub1 when using the MBR extended area for core.img. The grub installer program checks several data to determine the disk address of core.img, including making a bios query. Sometime the address is just plain wrong. In my tests with grub1 and for a reason I cannot explain, this happened more often when stage1 was looking for grub on a logical partition. If core.img is placed in the MBR extended area, it is always in exactly the same location on disk and so the address hard-coded into boot.img will always be correct.
Given the above, it seems that it would always be best to install boot.img to the MBR and core.img to the area immediately following, unless that space is already used (I would think the installation program could check that).
For users who already have Windows installed, this means writing over the DOS code in the MBR (as already is frequently done in installation now). It would be good to have a simple recovery mechanism whereby /usr/lib/master-boot-code could be written back to the MBR, or at least instructions somewhere on how to do this with live-media, in the event the grub installation fails; the machine would then at least be bootable again. The alternative to this is to not use the MBR at all for grub, which means using the generic code in the MBR with the active flag set + a primary PBR for boot.img + a filesystem for core.img, and with that back to the problems above.
yast2 bootloader have some facility to backup and restore mbr in grub1's setting page. Maybe we have to copy them to grub2. (noted)
My $.02.
Thanks a lot. :) Michael
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org