Replacing x86 firmware with Linux and Go

Posted Nov 21, 2017 0:56 UTC (Tue) by pbonzini (subscriber, #60935)
Parent article: Replacing x86 firmware with Linux and Go

There is one important thing that SMM does that is not just vendor crap. By accessing flash memory and handling the UEFI persistent store, SMM provides the trusted base for Secure Boot. So, if they want to implement some kind of code signing, they need to do it in SMM.

In addition, APEI functionality (ACPI Platform Error Interface) is usually implemented via SMM.

Replacing x86 firmware with Linux and Go

Posted Nov 21, 2017 16:47 UTC (Tue) by luto (guest, #39314) [Link] (7 responses)

I don't really buy this. I see no reason that the secure part of flash ever needs to be written after boot. A high quality implementation of UEFI should be able to queue up variable writes such that the next boot will find them, validate them, and apply them before ever executing code off the disk.

I'm not at all sure that Intel's flash hardware can do this, but it's surely doable with a second plain I2C flash chip on the system SMBUS.

Replacing x86 firmware with Linux and Go

Posted Nov 21, 2017 21:06 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (4 responses)

Well, if you can throw additional hardware at the task that's certainly a possibility. :-) Instead of a second I2C flash you could also delegate UEFI variable services and APEI to a microcontroller (also on SMBus).

Oh, and there's actually another thing that SMM does, which is orchestrating CPU hotplug. And that's an ugly one because, due to the asinine default choice of SMBASE made in the 386SL(*), it's the only case that really, really needs to bring *all* processors at the same time on SMM.

(*) 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?".

Replacing x86 firmware with Linux and Go

Posted Nov 21, 2017 22:08 UTC (Tue) by luto (guest, #39314) [Link] (3 responses)

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.

Replacing x86 firmware with Linux and Go

Posted Nov 23, 2017 19:31 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

> I see no reason that the secure part of flash ever needs to be written after boot.
How about the efivars pstore driver? Saved me a lot of grey hair the last time my home server hit a kernel panic in the middle of the night, and I could actually diagnose it afterwards.

Replacing x86 firmware with Linux and Go

Posted Nov 23, 2017 21:03 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

That doesn't write to the secure part of the variable store.

Replacing x86 firmware with Linux and Go

Posted Nov 22, 2017 6:45 UTC (Wed) by MakeHinduGreateAgain (guest, #119801) [Link] (1 responses)

I thought the better description is that install my customer SMM handler in Linux payload (As https://github.com/rminnich/linux/commits/monitor). The RAS related function code is resident in SMM and some of the registers are SMM access only if my memory is correct.

And a little anecdote is default UEFI SMM handler always bright up other core APs into SMM synchronously (the CPU troop is spining and waiting). If you have more AP cores, the more latency you will get. (Although there are some security implication here). A modern server machine has at least twelve cores. There will be some performance and latency issue.

Replacing x86 firmware with Linux and Go

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

Even if you have a chain of trust to the kexec-ed Linux, it isn't necessarily fine for it to do arbitrary accesess the key store (or at least, in the UEFI trust model, it's not).

If it's not, you need some "trusted" code to survive from the pre-kexec environment, in order to validate accesses to flash.

> And a little anecdote is default UEFI SMM handler always bright up other core APs into SMM synchronously (the CPU troop is spining and waiting).

Yup, in fact port 0xB2 gets all cores into SMM. We tried avoiding that for KVM's implementation of SMM (which is only used for UEFI secure boot), but we kept finding bugs in Tiano Core and finally decided to get the thundering herd of CPUs into SMM just like on bare metal. :( But we still do not support hotplug with secure boot because Tiano Core lacks the required SMM magic (Intel hasn't open sourced it yet).