Patch Set 2:

Patch Set 2:

Patch Set 2:

Patch Set 2:

if i remember correctly, this programming sequence requirement was from cannon-lake onwards. skylake/kabylake can still use native (coreboot) sgx init flow.

On SKL LT_MEMORY_LOCK has to be set, too, and FSP does this with SkipMpInit=0. AFAICT native SGX init can't be used on SKL for the same reasons we can't use it on CNL.

From cannon-lake onwards, sgx init needs fsp for the reasons mentioned in https://review.coreboot.org/c/coreboot/+/36356/2/src/soc/intel/cannonlake/finalize.c#116. i guess mp-ppi may also be used for cannon-lake onwards. Please follow Nate's recommendation for that.

PS: I see my gmail was added earlier and that notification was in spam. Thanks for adding my @intel email. I am off next week, I’ll respond the following week if there are follow-up questions.

See CB:36356. Native SGX init is not used in CNL, so there is nothing more to do.

"FSP-S must be able to write and lock some registers that would be immutable after setting LT_LOCK_MEMORY."* I dont think i got into this issue when i wrote native sgx init flow. At that time i was able to activate the SGX and lock it correctly by using native code only. i created enclaves also from the application and checked it was encrypted and working as expected.

@Nate: is this* valid for SKL/KBL as well?

Yes, this is valid and exactly the point, why native SGX init can't be used. LT_MEMORY_LOCK must be set, *before* native SGX init (well, more specifically before microcode reload). That conflicts with the requirement of FSP-S to be able to write registers.

At that time i was able to activate the SGX and lock it correctly by using native code only. i created enclaves also from the application and checked it was encrypted and working as expected

Yes, SGX works. No, not in a secure way with native SGX init without LT_MEMORY_LOCK.

View Change

To view, visit change 44244. To unsubscribe, or for help writing mail filters, visit settings.