Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

S3 resume script in coreboot? #69

Open
osresearch opened this issue Dec 18, 2016 · 5 comments
Open

S3 resume script in coreboot? #69

osresearch opened this issue Dec 18, 2016 · 5 comments

Comments

@osresearch
Copy link
Collaborator

Does coreboot use something like the SMM lockbox to prevent S3 script hijacking? This won't matter as much if #12 (SPI HW write protection) is fixed, but until then the system is potentially vulnerable to code execution during resume. Even if FLOCKDN is set early enough, it is a powerful place for malware to hide.

@osresearch
Copy link
Collaborator Author

We've already made LOCK_SPI_ON_RESUME_RO the default in the Heads coreboot config file, but need to validate when it is being setup during the resume process. https://www.coreboot.org/pipermail/coreboot/2016-April/081224.html

@osresearch
Copy link
Collaborator Author

Not sure if this is locked on the Chell -- the config parameter only appears in coreboot/src/southbridge/intel/bd82x6x/finalize.c, so we might be depending on the Intel FSP to do the locking (cue repeat of Snorlax/Prince Harming).

@osresearch
Copy link
Collaborator Author

Really nice overview of the S3 sleep/resume process including the interaction of AML, the kernel and the firmware. https://wiki.ubuntu.com/Kernel/Reference/S3

@Siproqu
Copy link

Siproqu commented Jul 16, 2020

Is this still a thing? Shouldn't LOCK_SPI_ON_RESUME_NO_ACCESS or LOCK_SPI_ON_RESUME_RO be set as default?

@tlaurion
Copy link
Collaborator

The platform lockdown configuration in coreboot changed a lot since this issue was opened.
The new default should become what is under #326, which would be the safer default for Sandy/Ivy bridge, but where FSP workarounds need to be pushed upstream to be able to deal properly with platform lockdown.

Discussion happened under tlaurion@3343f8d for coreboot 4.13+

Basically requiring io386 module and then the following addition under coreboot config:

  • CONFIG_BOOTMEDIA_LOCK_CONTROLLER=y
  • # CONFIG_INTEL_CHIPSET_LOCKDOWN is not set

And then:

  • modification of kexec-boot script to call lock_chip just prior of kexec call

@root-hardenedvault added FSP hacks on his Heads fork for newer platforms.

tlaurion pushed a commit to tlaurion/heads that referenced this issue May 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants