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

Nikunj A Dadhania nikunj at linux.vnet.ibm.com
Mon Nov 14 18:53:38 AEDT 2016

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?


> 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


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


More information about the SLOF mailing list