Hi
When refactoring the coreboot SMM setup I noticed that there is a security vulnerability in our SMM setup code.
It boils down to this: except on the BSP the smihandler code will execute code at a random location, but most likely at offset 0. With some carefully crafted code a bootloader or the OS could place some code at that offset, generate an SMI on an AP and get control over SMM. More recent silicon has hardware mechanisms to avoid executing code outside the designated SMM area (TSEG) so those would not be affected.
The commit introducing this problem is https://review.coreboot.org/c/coreboot/+/43684. Roughly it affects most x86 builds from end 2020/ beginning 2021 till now.
https://review.coreboot.org/c/coreboot/+/63478 fixes the problem. (Feel free to review the rest of that series as it makes the smm setup much more readable ;-))
Kind regards Arthur
Hi
I did some testing on real hardware with an Intel Coffeelake system on whether vectoring out of TSEG is prohibited by the hardware, which I assumed would be the case. It's *not* the case! Vectoring out of TSEG does succeed so this issue really affects modern hardware. So I think this issue might affect a lot more systems than I initially thought.
Kind regards Arthur
On Fri, Apr 8, 2022 at 12:43 AM Arthur Heymans arthur@aheymans.xyz wrote:
Hi
When refactoring the coreboot SMM setup I noticed that there is a security vulnerability in our SMM setup code.
It boils down to this: except on the BSP the smihandler code will execute code at a random location, but most likely at offset 0. With some carefully crafted code a bootloader or the OS could place some code at that offset, generate an SMI on an AP and get control over SMM. More recent silicon has hardware mechanisms to avoid executing code outside the designated SMM area (TSEG) so those would not be affected.
The commit introducing this problem is https://review.coreboot.org/c/coreboot/+/43684. Roughly it affects most x86 builds from end 2020/ beginning 2021 till now.
https://review.coreboot.org/c/coreboot/+/63478 fixes the problem. (Feel free to review the rest of that series as it makes the smm setup much more readable ;-))
Kind regards Arthur
Arthur Heymans wrote:
I think this issue might affect a lot more systems than I initially thought.
Would it make sense to backport your fix to old releases and bump those release numbers to a .1 on the end?
//Peter
Hi
Would it make sense to backport your fix to old releases and bump
those release numbers to a .1 on the end?
Some see releases as mere synchronization tags & nice PR. Some releases are also branches in gerrit but there are none affected by this (latest is 4.12 and it was introduced in 4.13). There is a precedent where 4.8 was bumped to 4.8.1 because all boards were broken.
I don't have a strong opinion on this. Do people really use the releases in production or are most using git anyway? It's a bit weird to have releases that you'd have to advertise as *don't use*, but I've seen us do that in the past (because issues are quite often just fixed in master).
Kind regards Arthur
On Tue, Apr 12, 2022 at 12:52 AM Peter Stuge peter@stuge.se wrote:
Arthur Heymans wrote:
I think this issue might affect a lot more systems than I initially
thought.
Would it make sense to backport your fix to old releases and bump those release numbers to a .1 on the end?
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Arthur Heymans wrote:
Would it make sense to backport your fix to old releases and bump those release numbers to a .1 on the end?
..
It's a bit weird to have releases that you'd have to advertise as *don't use*, but I've seen us do that in the past (because issues are quite often just fixed in master).
I don't know about actively advertising "don't use" but most projects do keep public records of security-related issues including the first fixed version.
I asked specifically about backporting since non-master branches are a) supposed to have some longevity and b) maybe used to simplify people's and companies' own release management.
I too would appreciate hearing from those shipping coreboot.
Thanks
//Peter
On April 12, 2022 8:55:56 AM UTC, Arthur Heymans arthur@aheymans.xyz wrote:
Hi
Would it make sense to backport your fix to old releases and bump
those release numbers to a .1 on the end?
Some see releases as mere synchronization tags & nice PR. Some releases are also branches in gerrit but there are none affected by this (latest is 4.12 and it was introduced in 4.13).
As you may know, coreboot distributions (talking of Heads specifically here), take releases tarballs and apply patches where needed on top of it.
In the present case, Heads currently depends on coreboot 4.11, 4.13 and 4.15 for its supported boards. I quickly attempted to backport the relevant patches to 4.13 tarball release, unsuccessfully. The alternative would be to move all 4.13+ coreboot versions to switch to a specific commit in the middle of the current 4.16 release, which doesn't seem to be interesting from a stability perspective for users, moving production board owners to testers of 4.17 coreboot release.
The relevant patchset is on top of 4.16, where I haven't found a proper merging strategy to backport a good patchset onto 4.13. I attempted to find all patches touching the 4.13 introduced new smm2 handler, but conflicts arose when trying to cherry-pick those commits in reverse order in the attempt of creating a patch that would apply successfully on top of 4.13 extracted tarball.
I believe as well that new tarballs for 4.13.1 and newer should have the patchset backported and included and newer branches/tarballs (.1) released, so that all coreboot based distributions can easily point to those new tarballs without each of them having to suddenly point to a specific commit in between releases, 4.16 just having been released, also containing the vulnerability.
There is a precedent where 4.8 was bumped to 4.8.1 because all boards were broken.
I don't have a strong opinion on this. Do people really use the releases in production or are most using git anyway?
In the goal of coreboot release based distributions, and to properly support products/solutions, I am not aware of a lot of projects that are based on coreboot rolling release (git).
If reproducibility of coreboot distribution builds (roms) are also being a goal for those coreboot distribution projects, pointing to a git commit is only good for testing new introduced platforms, not optimal in creating stable releases for already supported platforms, which project codebase changes as well in between coreboot upstream releases.
It's a bit weird to have releases that you'd have to advertise as *don't use*, but I've seen us do that in the past (because issues are quite often just fixed in master).
In an ideal world, each of those projects would have time to test fully rolling releases. But the reality is different. Heads/Skulls/Osboot/libreboot relies on coreboot releases to build ROMs for their supported platforms and users.
Kind regards Arthur
On Tue, Apr 12, 2022 at 12:52 AM Peter Stuge peter@stuge.se wrote:
Arthur Heymans wrote:
I think this issue might affect a lot more systems than I initially
thought.
Would it make sense to backport your fix to old releases and bump those release numbers to a .1 on the end?
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hello Insurgo,
On 12.04.22 16:01, Insurgo Technologies Libres / Open Technologies wrote:
On April 12, 2022 8:55:56 AM UTC, Arthur Heymans arthur@aheymans.xyz wrote:
Would it make sense to backport your fix to old releases and bump those release numbers to a .1 on the end?
Some see releases as mere synchronization tags & nice PR. Some releases are also branches in gerrit but there are none affected by this (latest is 4.12 and it was introduced in 4.13).
As you may know, coreboot distributions (talking of Heads specifically here), take releases tarballs and apply patches where needed on top of it.
In the present case, Heads currently depends on coreboot 4.11, 4.13 and 4.15 for its supported boards. I quickly attempted to backport the relevant patches to 4.13 tarball release, unsuccessfully.
have you checked if the SMM module loader v2 was used in your 4.13 builds? AIUI, it was optional and only enabled on user request.
Nico
On 4/12/22 10:17, Nico Huber wrote:
Hello Insurgo,
On 12.04.22 16:01, Insurgo Technologies Libres / Open Technologies wrote:
On April 12, 2022 8:55:56 AM UTC, Arthur Heymans arthur@aheymans.xyz wrote:
Would it make sense to backport your fix to old releases and bump those release numbers to a .1 on the end?
Some see releases as mere synchronization tags & nice PR. Some releases are also branches in gerrit but there are none affected by this (latest is 4.12 and it was introduced in 4.13).
As you may know, coreboot distributions (talking of Heads specifically here), take releases tarballs and apply patches where needed on top of it.
In the present case, Heads currently depends on coreboot 4.11, 4.13 and 4.15 for its supported boards. I quickly attempted to backport the relevant patches to 4.13 tarball release, unsuccessfully.
have you checked if the SMM module loader v2 was used in your 4.13 builds? AIUI, it was optional and only enabled on user request.
Thanks Nico for that pointer. Community maintained Heads boards are mostly based on coreboot 4.13 as of now:
# CONFIG_X86_SMM_LOADER_VERSION2 is not set
was hidden in the savedefconfig format stored under Heads repositories for coreboot 4.13 depending boards.
Expending the saved configuration confirms non-usage of SMM2 optional loader and is therefore not considered vulnerable per reported vulnerability.
I would highly doubt other coreboot based distributions would have activated this explicitly, but will depend of the new coreboot pushed defaults from upstream releases. Let's see.
4.15 and 4.16 removed that optional configuration setting (default configuration) and seemed to have switched to SMM2 by default.
Neither coreboot 4.14, 4.15 or 4.16 releases notes explicitly noted the change to SMM2, where 4.13 announces the change. Not sure users are following coreboot discussions, but I hope coreboot distribution maintainers are.
Consequently, all downstream coreboot based distributions, and their users, may stay vulnerable if no new 4.15.1 4.16.1 are released from my understanding until 4.17 is released.
A quick exploration of other coreboot distributions I am aware of:
- Skulls uses coreboot master git at time of release (1.0.4 is based on 74d2218cc7 as of december 2021, configs are also saved in savedefconfig and are expected as well, consequently). https://github.com/merge/skulls/releases/tag/1.0.4
- Not so familiar with osboot build system. They store configs in expended full format. Sampled config for x220 was updated last month and seems to be based on coreboot 4.14+ 9probably 4.16), which is deemed to be vulnerable as well. https://notabug.org/osboot/osbmk/src/master/resources/coreboot/x220_8mb
- Not so familiar with libreboot recent buildsystem either. A sampled configuration for x200 shows coreboot config being last updated 4 months ago, making it depend on coreboot 4.14+ which is not showing 4.13 optional SMM2 loader, which also seem to default to SMM2. Hence all their boards (outside of kgpe-d16, kcma-d8 etc depending on older 4.11) being vulnerable as well: https://notabug.org/libreboot/lbmk/src/master/resources/coreboot/x200_8mb/co...
As per my precedent e-mail, I believe all coreboot based distributions (maintainers and their project users) would be grateful to have releases backporting this patchset (4.14? 4.15, 4.16) to properly support their coreboot users. Then being able to do a point release as well without all of them having to point to a random commit, happening in between coreboot releases/maintainers or trying to manually cherry-pick relevant commits and have patches deployed (if their build systems permit that) to have point releases.
Nico
Thierry
Apr 12, 2022, 10:25 by insurgo@riseup.net:
On 4/12/22 10:17, Nico Huber wrote:
Hello Insurgo,
On 12.04.22 16:01, Insurgo Technologies Libres / Open Technologies wrote:
On April 12, 2022 8:55:56 AM UTC, Arthur Heymans arthur@aheymans.xyz wrote:
Would it make sense to backport your fix to old releases and bump those release numbers to a .1 on the end?
Some see releases as mere synchronization tags & nice PR. Some releases are also branches in gerrit but there are none affected by this (latest is 4.12 and it was introduced in 4.13).
As you may know, coreboot distributions (talking of Heads specifically here), take releases tarballs and apply patches where needed on top of it.
In the present case, Heads currently depends on coreboot 4.11, 4.13 and 4.15 for its supported boards. I quickly attempted to backport the relevant patches to 4.13 tarball release, unsuccessfully.
have you checked if the SMM module loader v2 was used in your 4.13 builds? AIUI, it was optional and only enabled on user request.
Thanks Nico for that pointer. Community maintained Heads boards are mostly based on coreboot 4.13 as of now:
# CONFIG_X86_SMM_LOADER_VERSION2 is not set
was hidden in the savedefconfig format stored under Heads repositories for coreboot 4.13 depending boards.
Expending the saved configuration confirms non-usage of SMM2 optional loader and is therefore not considered vulnerable per reported vulnerability.
I would highly doubt other coreboot based distributions would have activated this explicitly, but will depend of the new coreboot pushed defaults from upstream releases. Let's see.
4.15 and 4.16 removed that optional configuration setting (default configuration) and seemed to have switched to SMM2 by default.
Neither coreboot 4.14, 4.15 or 4.16 releases notes explicitly noted the change to SMM2, where 4.13 announces the change. Not sure users are following coreboot discussions, but I hope coreboot distribution maintainers are.
Consequently, all downstream coreboot based distributions, and their users, may stay vulnerable if no new 4.15.1 4.16.1 are released from my understanding until 4.17 is released.
I definitely agree that it would be a good thing to create the release branches for 4.14, 4.15, and 4.16 and port at least these security changes, then do a .1 release with those updates, and remove the original tarballs from our download page.
Even if this isn't needed for a particular project like Heads, I think it's our responsibility to go back and fix security issues like this.
I'll see what I can do to make this happen.
Martin
Nice hunt, Arthur! The attack surface in coreboot is lesser than UEFI but the misconfig during the setup will lead to serious issue. This one is neat and worth a CVE. Please use CVE-2022-29264 as record:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29264
regards Shawn
------- Original Message ------- On Thursday, April 7th, 2022 at 10:43 PM, Arthur Heymans arthur@aheymans.xyz wrote:
Hi When refactoring the coreboot SMM setup I noticed that there is a security vulnerability in our SMM setup code. It boils down to this: except on the BSP the smihandler code will execute code at a random location, but most likely at offset 0. With some carefully crafted code a bootloader or the OS could place some code at that offset, generate an SMI on an AP and get control over SMM. More recent silicon has hardware mechanisms to avoid executing code outside the designated SMM area (TSEG) so those would not be affected. The commit introducing this problem is https://review.coreboot.org/c/coreboot/+/43684. Roughly it affects most x86 builds from end 2020/ beginning 2021 till now.
https://review.coreboot.org/c/coreboot/+/63478 fixes the problem. (Feel free to review the rest of that series as it makes the smm setup much more readable ;-)) Kind regards Arthur
The branches for 4.14, .15, and 4.16 are created and ready for patches to be pushed.
After the patches are merged, I'll handle the releases.
Martin
On Mon, Apr 25, 2022 at 11:54 PM Shawn C shawn.chang@hardenedvault.net wrote:
Nice hunt, Arthur! The attack surface in coreboot is lesser than UEFI but the misconfig during the setup will lead to serious issue. This one is neat and worth a CVE. Please use CVE-2022-29264 as record:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29264
regards Shawn
------- Original Message ------- On Thursday, April 7th, 2022 at 10:43 PM, Arthur Heymans arthur@aheymans.xyz wrote:
Hi When refactoring the coreboot SMM setup I noticed that there is a security vulnerability in our SMM setup code. It boils down to this: except on the BSP the smihandler code will execute code at a random location, but most likely at offset 0. With some carefully crafted code a bootloader or the OS could place some code at that offset, generate an SMI on an AP and get control over SMM. More recent silicon has hardware mechanisms to avoid executing code outside the designated SMM area (TSEG) so those would not be affected. The commit introducing this problem is https://review.coreboot.org/c/coreboot/+/43684. Roughly it affects most x86 builds from end 2020/ beginning 2021 till now.
https://review.coreboot.org/c/coreboot/+/63478 fixes the problem. (Feel free to review the rest of that series as it makes the smm setup much more readable ;-)) Kind regards Arthur
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Glad this is being addressed in coreboot. According to https://kb.cert.org/vuls/id/796611 Insyde's UEFI implementation currently has 23 SMM vulnerabilities researched and disclosed by the company binarly.io and there is no telling if and when the vendors downstream apply the fixes and release BIOS updates to their customers.
On Tue, Apr 26, 2022 at 11:45 AM coreboot org coreboot.org@gmail.com wrote:
The branches for 4.14, .15, and 4.16 are created and ready for patches to be pushed.
After the patches are merged, I'll handle the releases.
Martin
On Mon, Apr 25, 2022 at 11:54 PM Shawn C shawn.chang@hardenedvault.net wrote:
Nice hunt, Arthur! The attack surface in coreboot is lesser than UEFI
but the misconfig during the setup will lead to serious issue. This one is neat and worth a CVE. Please use CVE-2022-29264 as record:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29264
regards Shawn
------- Original Message ------- On Thursday, April 7th, 2022 at 10:43 PM, Arthur Heymans <
arthur@aheymans.xyz> wrote:
Hi When refactoring the coreboot SMM setup I noticed that there is a
security vulnerability in our SMM setup code.
It boils down to this: except on the BSP the smihandler code will
execute code at a random location, but most likely at offset 0. With some carefully crafted code a bootloader or the OS could place some code at that offset, generate an SMI on an AP and get control over SMM. More recent silicon has hardware mechanisms to avoid executing code outside the designated SMM area (TSEG) so those would not be affected.
The commit introducing this problem is
https://review.coreboot.org/c/coreboot/+/43684.
Roughly it affects most x86 builds from end 2020/ beginning 2021 till
now.
https://review.coreboot.org/c/coreboot/+/63478 fixes the problem.
(Feel free to review the rest of that series as it makes the smm setup much more readable ;-))
Kind regards Arthur
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Arthur Heymans -
coreboot org -
Insurgo -
Insurgo Technologies Libres / Open Technologies
-
Martin Roth -
Nico Huber -
Peter Stuge -
R S -
Shawn C