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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
