grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/2] efi: SPI NOR flash support


From: Heinrich Schuchardt
Subject: Re: [PATCH v2 1/2] efi: SPI NOR flash support
Date: Thu, 11 Feb 2021 15:04:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 11.02.21 13:50, Michael Lawnick wrote:
> Am 11.02.2021 um 09:51 schrieb Heinrich Schuchardt:
>> On 11.02.21 08:36, Michael Lawnick wrote:
>>>
>>> Hi,
>>>
>>> seven days of silence. In the end no interest for extending EFI support?
>>>
>>> KR
>>> Michael
>>>
>>> Am 05.02.2021 um 09:58 schrieb Michael Lawnick:
>>>> Add EFI SPI NOR driver
>>>>
>>>> Use UEFI interface for accessing SPI NOR flashes.
>>>> If supported the implementation of UEFI boot software abstracts
>>>> away all those ugly H/W details like SPI controller or protocol.
>>>> Provided functions:
>>>> grub_efi_spi_nor_
>>>>      init
>>>>      erase
>>>>      write
>>>>      read
>>>>      flash_size
>>>>      flash_id
>>>>      erase_block_size
>>>>
>>>> This driver might be used for further abstraction to a common
>>>> (SPI) flash interface.
>>>>
>>
>> A commit message should describe what the patch is good for.
>>
>> What is the use case for GRUB accessing SPI?
>
> Many industrial systems use SPI flash as primary boot source. And most
> times there are changeable parameters to be stored.
>
>>
>> In your second patch you introduce a command to write and erase the SPI
>> flash. Hopefully the firmware has disabled writes.
>>
>> GRUB writing to SPI would mean that a user program could introduce
>> malware into the firmware by adding said command to grub.cfg.
>>
>> This would be a gross security issue. Hopefully the firmware has locked
>> the SPI flash before entering GRUB.
>>
>> SPI flash updates should be effected via signed UEFI update capsules and
>> not via GRUB.
>
> Hi,
>
> write protection is system architecture issue. If sensitive sections
> aren't protected S/W support for access won't change that. Latest in O/S
> state the devices can be accessed.
> On (many/some) x86 SoC I know it is BIOS which configures read/write
> protection, on my current ARM based system it is a combination of
> security level for complete boot device and H/W protection pin for
> unchangeable section in data device.
> In our company's area we do have H/W protection enabled on root of trust
> part and verification on module chain.
> Several boot parameters are stored in our SPI flash to configure the
> systems for different use cases.

I still do not understand why you need access in GRUB. You can read and
write the SPI flash in U-Boot on your embedded system.

Maybe you could provide a short example script showing how the new
command would fit into the GRUB boot flow.

Best regards

Heinrich

>
> I have the impression that your view is coming from x86/desktop
> direction. I am coming from embedded systems.
>
> KR
> Michael




reply via email to

[Prev in Thread] Current Thread [Next in Thread]