[coreboot] [Issue Tracker] Security notification
Email coreboot@coreboot.org was removed. https://ticket.coreboot.org/my/account User: flx IP address: 185.104.142.213 Date: 04/12/2022 12:55 AM -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs
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-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Martin Roth via coreboot wrote: > 1) Please don't use the term deprecate - use "moved to a branch" I don't think the wording matters, my points are discoverability and drive-by maintainance. > If a platform is perfect and doesn't need to be updated, it doesn't > need to be on the master branch, right? I think wrong, because being on master is the only chance to receive tree-wide changes, e.g. through coccinelle spatches or sed:its. Missing those rots the code quicker so yes, something getting moved to a non-master branch is de-facto deprecation by degradation to second class. > I absolutely agree that if something isn't being used, it doesn't > need to be maintained on the master branch. I disagree. > I just want to make sure that things actually aren't being used > before moving them to a branch. I think "no usage" alone should be a very weak motivator to move something from master, just like "no availability". (Many SOCs are currently unavailable and will remain so for some time!) If code is perfect or nearly perfect then why move it? If there are *concrete* issues with code then I think it would be reasonable for *that* to count much more than "no/unknown usage", but the current proposal did not reference any such issues, Paul's ask didn't yield any and neither did mine. //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes
Martin Roth via coreboot wrote: > > Your concern is valid and I think a key point. CBOR may not be bad > > over a socket, but such a complex and arbitrarily extensible format > > is much too error prone to be a good technical choice during boot. > > So if the idea is to create a payload handoff format that can be > shared and used by multiple different firmware packages, do you have > a better option? Yes, coreboot can just continue with just the > coreboot tables, but that seems a little like sticking our head in > the sand and refusing to recognize that other boot firmware exists. I'd ask what other boot firmware is missing from coreboot tables for them to be universally acceptable. > > I agree that it could be a step forward, but I think the devil is in > > the details. CBOR data structures can also be unneccessarily complex > > and error prone, beyond the parser itself. > > So maybe we try to limit the complexity? I'm not really familar with > CBOR, so I don't know the issues with it. CBOR (RFC 8949) is a binary serialization of JSON with some extensions. So "CBOR" itself says nothing about the data within. > Intel did say that they were willing to look at other alternatives if > we had any. That's a positive signal! I propose that coreboot tables are a good alternative - fight me! :) > I hope nobody takes any of this as criticism - I appreciate the > open discussion, and am sincerely looking for the best path forward here. Not at all. Let's see if coreboot tables can grow to cover all needs? Kind regards //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Another day, another SMM loader vulnerability
arthur, what might we do with either the build process or startup to avoid this problem in future? Do you think we could find a way to catch this programmatically soon, rather than humanly too late? On Mon, Apr 11, 2022 at 2:48 AM Arthur Heymans wrote: > > Hi > > After last week's SMM loader problem on all but the BSP, I noticed another > problem in the SMM setup. > The permanent smihandler is currently built as a relocatable module such that > coreboot > can place it wherever it thinks it's a good idea. (TSEG is not known at > buildtime). > These relocatable modules have an alignment requirement. > > It looks however that the code to deal with the alignment requirement is also > wrong > and aligns the handler upwards instead of downwards which makes it encroach > either an SSE2 > FX_SAVE area or an SMM register save state. It's hard to know whether this is > easily exploitable. > I would think that a carefully crafted SMM save state on the right AP > arbitrary code executing might be possible. On the other hand I noticed last > week that launching SMM on APs is broken too so this is likely a lesser > problem. > > Anyway the fix is in https://review.coreboot.org/c/coreboot/+/63475 > (It has a comment indicating what code was causing this problem) > Please review and update your coreboot code! > > Kind regards > Arthur > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Another day, another SMM loader vulnerability
Hi After last week's SMM loader problem on all but the BSP, I noticed another problem in the SMM setup. The permanent smihandler is currently built as a relocatable module such that coreboot can place it wherever it thinks it's a good idea. (TSEG is not known at buildtime). These relocatable modules have an alignment requirement. It looks however that the code to deal with the alignment requirement is also wrong and aligns the handler upwards instead of downwards which makes it encroach either an SSE2 FX_SAVE area or an SMM register save state. It's hard to know whether this is easily exploitable. I would think that a carefully crafted SMM save state on the right AP arbitrary code executing might be possible. On the other hand I noticed last week that launching SMM on APs is broken too so this is likely a lesser problem. Anyway the fix is in https://review.coreboot.org/c/coreboot/+/63475 (It has a comment indicating what code was causing this problem) Please review and update your coreboot code! Kind regards Arthur ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
