cedarhouse1@comcast.net has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38768 )
Change subject: [UNTESTED] intel/stm: Introduce stm_update_smm_info() ......................................................................
Patch Set 2:
(1 comment)
Patch Set 2:
(1 comment)
https://review.coreboot.org/c/coreboot/+/38768/2/src/security/intel/stm/StmP... File src/security/intel/stm/StmPlatformSmm.c:
https://review.coreboot.org/c/coreboot/+/38768/2/src/security/intel/stm/StmP... PS2, Line 165: * algorithm. (align on 4K)
My original (align on 4k) smm_save_state_size was based on the comments within Bios/StmCpuPkg/PiSm […]
| Can't say that I fully understand that code. Aren't SMM entries supposed | to be in SMRAM? It seems they just use a standard allocator.
Same here, I think it would be easier just to map out the data structures and code making sure that when increment the SMBASE that they don't conflict.
Actually, you could possibly start SMM in non-SMRAM. That was the basis for the cache-poisoning attacks some 10+ years ago. That's generally how the SMRR's came about and the MSR setting that prevents execution outside of SMRAM.
||Should we work to increment SMBASE in the positive direction? Or, does that break something ||important? | | Hmm, not sure what you are up to.
Right now, coreboot decrements the SMBASE for each thread. That, as you pointed out with the STM, limits us to 24 threads. To allow more than 24 threads, we need to increment the SMBASE as we allocate for each thread. That was shown in the example.