RFC: Patina UEFI Variables - #1760
Conversation
✅ QEMU Validation PassedAll QEMU validation jobs completed successfully.
Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/33235072897 Boot Time to EFI Shell
Dependencies
This comment was automatically generated by the Patina QEMU PR Validation Post workflow. |
github-actions
Bot
added
impact:non-functional
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Initial RFC for UEFI variables in Patina. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
eee2da4 to
b340f3a
Compare
|
|
||
| Ext ==>|"input flow (Zone Gasket)"| A | ||
| R ==>|"routed data"| G | ||
| R ==>|"cache check"| Ca |
There was a problem hiding this comment.
It seems odd that the router, part of the front-end, would explicitly check the cache in the back end. In my mind either the cache is part of the front-end and the router maintains it, or the cache is part of the backend, and the router is agnostic to its existence.
There was a problem hiding this comment.
The main reason is that the backend is expected to maintain its cache outside of high-cost entry/exit environments like MM while the main I/O operations (e.g., read and write) are expected/allowed to be within those environments. Does that make sense? If so, I can clarify this in the RFC.
| completely decoupled from other design areas. Control only transfers between zones across well-defined APIs. All data | ||
| transferred across zones is considered external and untrusted. | ||
|
|
||
| - `External` - Code outside the front-end and back-end. |
There was a problem hiding this comment.
Concrete examples of the zones would be helpful in digesting this. E.g. Front end: EDK2' Variable DXE driver, Back End: Standalone MM's variable driver, etc.
| Some elements may perform the same actions regardless of flow. In other cases, flow will completely change how the | ||
| component behaves. | ||
|
|
||
| ## Stages |
There was a problem hiding this comment.
Perhaps I'm missing the point, but as a note. I think the transition between implementation boundary definitions and implementation specific definitions is a bit confusing. Zones, Gaskets, etc. all relate to well defines ABIs and connecting physically different entities where Stages gets into the specific implementation within a single binary. I wonder if it would be helpful to define this in layers such that you talk about the high-level connection between Zones and then the layering within the Zone. At least in my readthrough that would have helped me get a mental model faster.
2 participants
Description
Initial RFC for UEFI variables in Patina.
Still a work in progress. PR is in draft while implementation is completed so any changes can be captured in the RFC.
How This Was Tested
cargo make allIntegration Instructions