Hi Werner,
On Fri, Sep 06, 2024 at 01:10:54PM +0000, Zeh, Werner wrote:
From the implementation point of view it looks a bit tricky to me: We do weave two independent projects (coreboot and Tianocore) quite a lot together in order to accomplish this task. Though there might be justifications to do that (coreboot owns SMM and unrestricted flash access can most complete be done from SMM while EDK II is the place to which the OS communicates to in order to provide the capsule), we should be careful doing so. There is just this one configuration out there which uses this feature (both sides, coreboot and Tianocore, need to enable capsule update). How shall be make sure that either side stays functional and will not logically break when the independent projects are getting developed further over the future?
The situation is similar to the one with SMMSTORE: coreboot configuration that wants to support capsules should use an appropriate EDK2 fork and revision even after things get fully upstreamed. coreboot is also the one responsible for specifying package and defines/PCDs for EDK2 and thus ultimately dictates whether the feature is enabled in the firmware as a whole.
Do you plan to add any kind of unit test to both projects so that it can be guaranteed? Because I otherwise fear that this feature can break quite easy without being noticed by both communities on time.
Automated tests are available at
https://github.com/Dasharo/open-source-firmware-validation/blob/a6414a7e3a23...
They can be run in QEMU or on real hardware (requires appropriate setup). This doesn't test upstream coreboot, but once changes are upstreamed and Dasharo fork is rebased, it essentially will.
Is there a way forward to reduce the intersection between coreboot and Tianocore by limiting the task coreboot needs to serve, maybe to just temporarily disable the flash write protection? This way the update could be implemented mostly on Tianocore side reducing the dependencies a lot.
The point of using SMMSTORE was to avoid reimplementing flash driver in EDK2 and just use the existing one in coreboot.
Most of the code added to coreboot is related to gathering pieces of capsules scattered almost anywhere in RAM by an OS before warm reset. coreboot either needs to do this or be very careful to avoid stepping on all of those regions and hope that none of them will create problems for starting payload.
coreboot then provides list of capsules in CBMEM. All the actual processing is in EDK2, only the most low-level part is handled by coreboot which in EDK2-only firmware is done by its PEI part.
Regards, Sergii