Replacing x86 firmware with Linux and Go

Posted Nov 21, 2017 22:08 UTC (Tue) by luto (guest, #39314)
In reply to: Replacing x86 firmware with Linux and Go by pbonzini
Parent article: Replacing x86 firmware with Linux and Go

True, although adding a whole microcontroller would cost more than just an I2C flash chip. The only service that I think is really needed is some NVRAM that can be written outside SMM to queue up variable writes. I don't know whether current Intel chips can lock down part of boot flash while leaving some unlocked.

> The OS could overwrite 0x30000 and gain access to SMRAM. "Why 0x30000?" is near the top of my list of x86 unanswered questions, even higher than "What the heck was CR1?".

I've never understood why the reset/SIPI vectors and the default SMBASE don't point to addresses that are unconditionally in the boot flash. I guess that all that's really needed is the ability to securely run something from flash before any OS code can possibly execute on a newly hot plugged CPU. Is this not actually possible without kicking all CPUs into SMM before powering up a new CPU?

Replacing x86 firmware with Linux and Go

Posted Nov 22, 2017 0:02 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (2 responses)

It's certainly possible, the problem is that 0x30000 doesn't point into flash. :(

Defaulting SMBASE to 0xA0000 would have made a lot more sense.

Replacing x86 firmware with Linux and Go

Posted Nov 22, 2017 0:04 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

I forgot a sentence: 0x30000 doesn't point into flash, so you need to bring everyone in SMM when the newly-hotplugged CPU does SMBASE relocation.

Replacing x86 firmware with Linux and Go

Posted Nov 24, 2017 11:13 UTC (Fri) by pityashian_sweatshopworker (guest, #119852) [Link]

Some rambling talking:

The final SMM base for each core is not always is constant. The SMM space is usually nearby other *stolen* memory spaces (like integrated GFX or ME) to make more available memory space to be continuous. The 0x30000 (hardware reset default) is used as a trampoline or temporary space to craft SMM context only. (Some old guy SMM base called as A-segment 0xA0000 which is nearby the VGA ROM, on the recent machine which is called as T segment, the T is referred as the 'T' in TOLUD possibly).

About flash based SMM handler which is robuster than memory based specially with RAS slang, but the footprint size vs cost problem emerged. The more functionality make the footprint size to grow up. Even recent Intel ME (for serve product segment) also reside in the stolen memory instead of SRAM! Once server ME stop working, a lot of function of the *isolated* BMC will stop working too.

I guessed bravely that prior to CPU/SMM context is initialized w/o any examination(maybe i am wrong), it seems unlikely SMM entry will be conducted for a CPU. Even in the more restrictive environment, STM maybe used to monitor SMM activities.

A-bit off topic,a notorious and common problem of SMM security is that in some laptop implementation, it will disable the execution out of SMM space exception and then call video BIOS or GOP in SMM directly and roughly.