Date 1 - 1 of 1
TianoCore Community Design Meeting Minutes - Jul 12
[resend from mail client to make sure format is expected.]
1. OOB verification: a common solution providing chain of trust
Presenter: Jian Wang
* key advantage:
- verify whole FV in every boot path: s3, recovery, capsule
- avoid TOC/TOU
- report verification result through status code
- deadloop upon verification failure/error
* requirement: hw-based root of trust
* boot flow: refer to "Boot Flow (Boot Guard Version)" in slides.
- Comments: FvInfo -> FvInfo, for more readable code.
- Comments: Hash -> Hash, for support of future bigger hash size though unseen today.
- Comments: What if platform code that reports FV directly is not removed completely? Is it a potential security hole?
- Comments: *_REPORT_FV_INFO_PPI -> *_REPORT_PEI_FV? *_REPORT_FV_INFO_HOB -> *_REPORT_DXE_FV?
Considering nested FV, *_REPORT_PEI_FV doesn't mean to report PEI FV.
Conclusion: comments to explain how the FV_INFO_PPI/FV_INFO_HOB are consumed.
- Comments: Support verification in smaller granularity other than FV.
Verification including FV header is necessary to avoid potential bugs.
2. Enhance CPU Feature Initialization to Handle Disabled Core#0
Presenter: Ray Ni
* How CPU Features are initialized: refer to "How CPU Features are Initialized" in slides.
GetConfigData() is split from Support() because Support() is called by each CPU while GetConfigData() needs to allocate memory which cannot be called in AP.
* Problem: Core#0/Thread#0 is disabled resulting some features (e.g.: C1E) are not initialized.
* Proposal #1: Interpret Location as Logical
No-go: Some features rely on physical locations.
* Proposal #2: Add FirstX in CpuInfo. 6 bits each indicates whether the CPU is the first one in its parent scope.
e.g.: FirstX.Core = 1 for each CPU inside first Core inside each Module.
- Comments: Need to see whether a better name other than FirstX can be used.
Will discuss in email.
|1 - 1 of 1|