Hi Julius,
your attached comments may have been stripped by the mailing list. I did
receive them via direct email, but you may want to upload them somewhere
so others on this list can comment.
Am 13.12.25 um 09:23 schrieb Julius Werner:
Yeah, I wasn't even really aware of this document yet at that time, I
was only able to see it after Werner sent out the link earlier in this
thread. I probably didn't see the email you sent back then to be
honest.
There are so many things going on, it was easy to miss.
I think we were all a bit unaware of how urgent this is and
how massive and overbearing the document's contents would be.
Agreed on the urgency, but I beg to differ on the document's contents.
IMHO that standard is relatively lightweight and on the shorter side
compared to others. One of the bigger standards for another product
category has more than 80000 words.
I definitely really appreciate any help you can provide in explaining
and navigating this process now, or helping us get the foot in the
right door.
A lot has been happening behind the scenes, and one coreboot developer
was instrumental in making this document way less UEFI-centric than it
could have been. That is a great achievement.
Let me share some good news: I talked with the rapporteur for boot
managers a few hours ago (after all, we were in the same meeting room
for three days) and he is still very much interested in comments,
preferably against the latest version of the draft. It will be
challenging for him to squeeze in those comments, but better try now
than later.
That sounds great, thanks! This did actually get me to marathon
through the evening now and make it to the end of at least the
requirements part of the doc (though I may have skimmed and missed a
few parts). I've got all my comments gathered in a PDF (attached) for
now.
Thank you for your commentary! From the (really good) structure of your
document, I think we can transform that document into the expected shape
with roughly one hour of work together.
That said, some of your comments may be rooted in a misunderstanding
about which requirements apply conditionally/unconditionally. I can help
explain that when we work through the document.
I assume I'll need to transform all of these into "issues"
according to the process in
https://labs.etsi.org/rep/stan4cra/en-304-623? Or is this something
you could directly forward to this "rapporteur"? (I'm a bit confused
by the feedback process, I can only see two existing issues on the
labs page. Is that all the feedback they ever got on this document or
are the others just hidden somehow?)
You have every right to be confused. This particular standardization
process is a new design, combining an official mandate (standardisation
request by the European Commission) with international coordination (led
by ETSI and CEN/CENELEC), nation-state support (via national standards
organisations of EU member states), rapid iteration (faster than IETF
drafts, with some groups meeting twice a week), early public draft
releases (like IETF) as well as direct participation by private
individuals (unlike any other standards process) and companies and civil
society organisations. This also means the process has (and had)
teething problems.
The now-finished early commenting period was an experiment to get
input/feedback from anyone (private individuals, experts, companies)
without a heavyweight bureaucratic process. This also means some people
attended meetings and gave verbal comments, others sent them via e-mail,
others opened issues and merge requests in private and public gitlab
instances, each person using their own preferrred way to comment. That
is also the reason you were only seeing very few issues in this specific
gitlab instance. The next phase is a more traditional standards-process
commenting. What we're now trying to do is squeezing in between those
two phases and use a commenting format which won't put too much of a
burden on the rapporteur (Christian "fukami" Horchert).
Let me explain some terms which may be confusing to people not
involved in EU politics:
"Rapporteur" is a combination of chairperson, editor, notetaker,
presenter, moderator, convener for a single standard. A rapporteur is
tasked with collecting all input from all interested parties,
consolidating it, building consensus among particpipants, and then
continuously reporting the results (i.e. all unresolved comments as well
as the current state of the document) to the standards organisation
overseeing this particular "vertical". The rapporteur is not expected to
have deep knowledge of the subject at hand, but rather have a cursory
understanding combined with excellent editorial and people skills.
Unexpectedly, rapporteurs for quite a few verticals had to write
substantial parts of the documents themselves due to scarce
contributions from participants.
"Vertical" (in the context of the standards we're talking about) means a
product category as laid out in Annex III and Annex IV of the Cyber
Resilience Act:
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02024R2847-20241120#anx_III
. Examples for such categories are "Standalone and embedded browsers",
"Operating systems" and "Boot managers". "Boot managers" is the
category/vertical applicable to coreboot/UEFI.
I'll be on a plane Monday/Tuesday, but I can try to do that later next
week — I hope that will still be in time?
I think so, yes. We should try to get this done in a call next week and
then submit the comments during or immediately after the call. Please
mail me directly with your availability so we can try to schedule a call.
I would also appreciate
anyone else who wants to look through my objections and let me know if
they make sense or I'm just misunderstanding something, of course (a
lot of this is just about very vague wording, or requirements that
seem to be specific to a certain (usually UEFI-style) bootloader where
it's not clear what this means for other systems that use different
concepts).
To jumpstart the dicusssion, let me try to reply to a few larger topics
you seemed to focus on. (Admittedly my reply is not structured in a way
which would be fit for submission. I tried to do this in a few hours and
cover multiple topics.)
- The whole signing/verification scheme seemed to irk you a lot. AFAICS
the requirements for replacable certificate hierarchies are designed to
address one problem: A machine may ship with UEFI and trust the
mainboard vendor's CA as well as a Microsoft CA to authenticate any code
that gets run by the firmware or boot loader. The user (or admin) may
want to not trust Microsoft and instead replace the Microsoft CA with
another more trusted CA, possibly a CA controlled by the user. When
refurbishing/recycling this machine, there needs to be an option to undo
this CA change and/or replace the first user's preferred CA with the
second user's preferred CA, subject to some robust controls so an
attacker cannot do it without consent from the owner.
- CA hierarchies: There have been so many compromised intermediate CAs
(usually from hardware vendors signing their drivers) used for signing
malware that it makes sense to retire an entire compromised intermediate
CA and start fresh without having to roll out a new root CA everywhere.
- Clearing memory: If the firmware asks for a boot password and then
keeps the password (or traces of keystrokes) in memory accessible to the
operating system, an admin of the operating system can later learn
secrets which should have been restricted to the person knowing the boot
password.
- The whole memory-safety thing: Exploitable parsers with firmware
privileges are bad. Use a mechanism of your choice to prevent
exploitation (memory safe language, encapsulating or de-privileging the
parser, compiler features, whatever).
- Authentication: Should physical presence be sufficient authentication
for certain operations? IMHO that depends. Evil maid attacks use
physical presence and you may want to protect against them. It is
non-trivial to differentiate between a legitimate wish to replace the
firmware and an evil maid trying to replace the firmware. It doesn't get
easier if someone installed their own coreboot on a chromebook and wants
protection against evil maid attacks, including evil maid attacks
reverting the firmware to the factory-delivered version. This is
probably one of the harder problems requiring significant effort to get
it right and document the implications of the solution/solutions.
- Some requirements being too strict: The idea is to have a risk-based
approach and apply stricter requirements to higher-risk uses. If you see
a requirement which arguably is unnecessary for the general use case,
you can try to get it moved as a requirement only for higher-risk uses.
- Having to verify code before flashing if code is verified before
execution anyway: If you don't verify before flashing and only before
execution, you may have created a DoS attack.
- Vague wording: A few things in the standard would benefit from
explanations along the lines of "why is this a problem" or "why do we
want this solution" to help people understand the rationale and/or
improve the requirements and/or suggest something should be scrapped.
Regards,
Carl-Daniel
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
