Add ability to change CMOS values for X230

[flawedworld]

Add ability to change CMOS values by genning SMBIOS tables and using the values from stock bios, this allows for editing of SMBIOS values to change things such as VRAM allocation, FN and CTRL key swap etc

[tlaurion]

How would we measure changes ?

[flawedworld]

I'm of the view it's not needed. There is no harmful options in NVRAM and even if there was (again, I don't see the scope of it), we can patch it easily out of coreboot anyway.

Alternatively, we force load a custom SMBIOS table on every boot, which the user may customize at compile time only, this would only allow on the fly changes, so an attacker could not do anything with persistence. Attacker could edit using nvramtool on a usb via recovery shell.

The most dangerous thing you could do is enable hyepr threading which isn't implemented on X230, which can be set with 'nosmt' in kernel anyway (which we should probably add as a boot argument for heads by default).

[tlaurion]

Hyper threading is supported on i7, but deactivated by QubesOS grub config as if now.

Not against having the defaults being loaded at compile time.

I think this is another state we might not want collectively merged inside of a shared board config and produced resulting CI built images, though.

[MrChromebox]

what exactly do the SMBIOS tables have to do with CMOS? IIRC, they are completely unrelated

[flawedworld]

@tlaurion I would personally say, this should be implemented on a board-by-board basis and we leave the NVRAM values at default coreboot values at compile times.

@tlaurion agreed, maybe a build flag would be useful for this?

@MrChromebox Forgive me, I may be using wrong terminology here, but from my understanding, CMOS chip holds the user defined NVRAM values, which is backed by the CMOS battery, so when you yank it out then in and boot you'll fallback onto the default SMBIOS tables and their default values respectively. Please correct me if I am wrong in my explanation. Perhaps I should edit original post replacing CMOS with NVRAM?

[MrChromebox]

@flawedworld the CMOS is a tiny amount of NVRAM historically part of the southbridge which coreboot uses to store configuration values. It has no direct connection to the SMBIOS tables. It's also generally not used interchangeably with NVRAM since that has a different connotation.

Looking at the cmos.layout for the x230, I don't see how any CMOS values for that board would result in any changes to the SMBIOS tables. And your selecting of CONFIG_SMBIOS_PROVIDED_BY_MOBO -- what is the goal there? Edit: this also seems to already be selected by CONFIG_DRIVER_LENOVO_SERIALS and so is redundant

So ultimately, the question is why have you selected CONFIG_GENERATE_SMBIOS_TABLES=y and CONFIG_SMBIOS_PROVIDED_BY_MOBO=y when those have nothing to do with CMOS configuration / changing the settings you mentioned in the PR.

[flawedworld]

@MrChromebox Indeed you would be correct, it seems that only CONFIG_USE_OPTION_TABLE=y is necessary. I was previously under the impression all the options were necessary, thanks for clearing that up and the explanation, I will edit accordingly

[MrChromebox]

since the CMOS data is stored outside of the AP SPI flash, there's no issue with measured boot. LGTM

[flawedworld]

@tlaurion any followup comments to this?

[tlaurion]

#602
#274 (comment) see STATIC advice?

[flawedworld]

I think the best way if we are worried about the persistence aspect is that we load a table in with user defined values at compile time, I will test these options out as soon as I can. I dare say the heads master branch is ready to handle that judging from #300 . Seems overkill but I mean its no harm done.

[flawedworld]

Tested and working on X230