Hi, > > First, smram allocation doesn't work that way. Have a look at > > OvmfPkg/SmmAccess. I guess that easily explains why this series > > breaks S3 suspend. > > Oh? Could you explain a bit more for 1) how smram allocation works? 2) what's > the possible reason break the S3? I haven't check yet.
SmramInternal.c handles that. It creates two regions, one is a page at the start of SMRAM where S3 state is stored (and marked as allocated), one is all the rest. So, if you need some smram to initialize SMM in PEI I'd suggest to either add a third region, or make the first region larger. It's not clear to me why you put the logic upside down and introduce that HOB in the first place. > > Second, storing these descriptors in a HOB (which is PEI memory) > > is questionable from a security point of view. > > HOB is only to expose the SMRAM address and size, not the contents in smram, > what's the security concern? Storing anything SMM related outside SMRAM makes me nervous. I'd strongly suggest to avoid that. It might be that in this specific case it is not a problem. But it needs very careful review of the implications (which I have not done) and you have to hope you don't miss a possible attack vector, such as someone modifying the HOB and the firmware then storing SMM data + code outside SMRAM. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118212): https://edk2.groups.io/g/devel/message/118212 Mute This Topic: https://groups.io/mt/105593577/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
