[SLOF] [PATCH 0/4] Block write support for SCSI and virtio-block disks

[Nikunj A Dadhania]

Thomas Huth <thuth at redhat.com> writes:

> On 14.11.2016 07:32, Nikunj A Dadhania wrote:
>> 
>> Hi Thomas,
>> 
>> Thomas Huth <thuth at redhat.com> writes:
>>> GRUB2 uses a file called grubenv in the boot partition to store certain
>>> information like which kernel should be booted the next time (see
>>> https://www.gnu.org/software/grub/manual/html_node/Environment-block.html
>>> for details). If the user set the "next_entry" variable here, e.g. with
>>> the "grub2-reboot" command under Linux, the corresponding kernel should
>>> only be booted once, so the GRUB2 bootloader has to update the grubenv
>>> file on the boot partition to avoid that it is booted again after the next
>>> reboot. That means GRUB2 needs write support at the firmware layer!
>>> This patch series implements this block write support in SLOF, so that
>>> the "grub2-reboot" command now works with SLOF as with other firmware
>>> implementations (i.e. the grubenv file is updated after the kernel that
>>> should be booted only once has been selected).
>> 
>> My only worry here is that it would open up a way to write to the
>> critical section of the disk image from the SLOF prompt. Is there a way
>> we can prevent this?
>
> Good idea, I also felt a little bit uneasy to have write support in the
> firmware, but since GRUB needs it, we likely can't ignore this.
> So with critical section, you mean the MBR, I assume?

Yes.

> That should be feasible, I think I could add a check that refuses
> writes to the first 512 bytes (or a little bit more to also protect
> the GPT? Suggestions welcome!).

Correct. For MBR 1st sector. For GPT (34 sectors in the beginning and 33
at the end) please refer to the following link for more details

https://en.wikipedia.org/wiki/GUID_Partition_Table


> I'll send a v2 once I've figure out a nice way to do this...
>
>  Thomas

Regards
Nikunj