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

[Nikunj A Dadhania]

Thomas Huth <thuth at redhat.com> writes:

> On 15.11.2016 02:47, Alexey Kardashevskiy wrote:
>> On 14/11/16 23:03, Thomas Huth wrote:
>>> On 14.11.2016 08:53, Nikunj A Dadhania wrote:
>>>> Thomas Huth <thuth at redhat.com> writes:
>>>>
>>>>> On 14.11.2016 07:32, Nikunj A Dadhania wrote:
>>> [...]
>>>>>> 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 just had a look at it, but adding code for checking whether the GPT is
>>> available or not (or using the checks from disk-label.fs) would render
>>> the whole checking mechanism quite complicated, as far as I can see...
>>> What about simply refusing write accesses to the first 4 sectors or so?
>>> Would that be OK? I think GRUB should never try to write to them - with
>>> MBR + partition header + file system superblock etc. the grubenv file
>>> should never be located below sector 4.
>> 
>> Can SLOF remember what partition it loaded grub from and restrict writes
>> just to that partition? The "grub" which SLOF loads is the one at
>> /boot/grub/grub, right?

The grub that SLOF loads is from the PReP partition. Rest of the loading
is then done by grub itself using client interface.

Are you recommending to remember the partition when client interface is
invoked.

> Good idea - I think such a check could be done at the disk-label.fs
> level. I'll have a try...

Regards
Nikunj