Hi,
The recent patch [1] for the OP-TEE Dispatcher in TF-A proposes a way
of post-boot loading OP-TEE by the Linux kernel with signature
verification in the normal world only. This has previously been
discussed in this mail thread [2] about half a year ago. Ultimately,
it was concluded that this should in principle be accepted upstream as
a platform choice to allow this or not. There are concerns that what
we have in upstream TF-A should serve as good examples, and trusting
the normal world to verify secure world software might not meet that
criterion. There are also concerns about adding signature verification
to BL31
Leaving the secure world wide open until the Linux kernel has been
able to successfully load and verify an OP-TEE binary seems very
risky. Even if it's claimed that the normal world can be trusted at
this point, we're still giving up a critical level of defense without
a good reason.
I've started to review [1], but it should not be accepted for merging
without support and approval from other maintainers.
I would like to explore other options in this mail thread. In [2] it
was suggested that a remnant of bl2 could be kept to verify OP-TEE
before starting to execute it. This could be taken one step further
and load a limited OP-TEE at boot which later is updated live, almost
like what's discussed in [3]. This should minimize the impact on TF-A
and also leave OP-TEE in charge of accepting an update instead of a
divided responsibility between the normal world and TF-A.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/18635
[2] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…
[3] https://github.com/OP-TEE/optee_os/issues/5699
Thanks,
Jens
Hello everyone,
A new security vulnerability has been identified in TF-A X.509 parser,
used for trusted boot in BL1 and BL2.
Please note that this vulnerability is *not* exploitable in TF-A
upstream code. Only downstream code might be affected under specific
circumstances.
The security advisory has been published in TF-A documentation and has
all the details:
https://trustedfirmware-a.readthedocs.io/en/latest/security_advisories/secu…
Patches to fix the identified bugs have already been merged in TF-A
tree. The advisory lists the relevant patches.
I would like to thank Demi Marie Obenour from Invisible Things Lab for
responsibly disclosing this security vulnerability to
TrustedFirmware.org, for providing patches to fix the identified bugs
and further harden the X.509 parser, for providing a detailed impact
analysis and for helping put this security advisory together.
Best regards,
Sandrine Bailleux, on behalf of TF-A security team.
This event has been updated with a note:
"Correcting the deletion of the wrong Techforum."
Changed: time
TF-A Tech Forum
Thursday Jan 26, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
View all guest info
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Reply for tf-a(a)lists.trustedfirmware.org and view more details
https://calendar.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1…
Your attendance is optional.
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
This event has been canceled with a note:
"No topic this week. Cancelling. Joanna"
TF-A Tech Forum
Thursday Jan 26, 2023 ⋅ 4pm – 5pm
United Kingdom Time
We run an open technical forum call for anyone to participate and it is not
restricted to Trusted Firmware project members. It will operate under the
guidance of the TF TSC. Feel free to forward this invite to
colleagues. Invites are via the TF-A mailing list and also published on the
Trusted Firmware website. Details are
here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr…
Firmware is inviting you to a scheduled Zoom meeting.Join Zoom
Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap
mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US
(San Jose)Dial by your location +1 646 558
8656 US (New York) +1 669 900
9128 US (San Jose) 877 853 5247 US
Toll-free 888 788 0099 US Toll-freeMeeting ID:
915 970 4974Find your local
number: https://zoom.us/u/ad27hc6t7h
Guests
marek.bykowski(a)gmail.com
okash.khawaja(a)gmail.com
tf-a(a)lists.trustedfirmware.org
~~//~~
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this email because you are an attendee on the event. To
stop receiving future updates for this event, decline this event.
Forwarding this invitation could allow any recipient to send a response to
the organizer, be added to the guest list, invite others regardless of
their own invitation status, or modify your RSVP.
Learn more https://support.google.com/calendar/answer/37135#forwarding
Hi all,
With the start of the new year I’m looking to see what TF-A Techforums should cover over the next few sessions. As folks may know these are held every two weeks on a Thursday at 4pm GMT. If you need an invite do reach out to me.
If folks have anything they would like to present to the TF-A community please do reach out to me as we often need topics. If we don’t have anything to present on upcoming sessions I will cancel the sessions the day before they are due to be held.
Currently I tentatively have the following for the first 4 sessions which will be confirmed nearer the dates:
* 12th January – No topic
* 26th January – LTS Update
* 9th February – No topic
* 23rd February - Tech talk for PSCI OS-initiated mode
Thanks
Joanna
Hello,
I'm working on a project for ChromeOS where we would like to be able to
load the BL32 payload (OpTee) for SEL-1 after the linux kernel has booted
rather than during the usual BL32 stage. We would do this via an SMC we
would add which would take the OpTee image from linux and then have EL3
load it and perform the init for SEL-1 at that time.
The reasoning behind this is that it's much easier to update the rootfs
than the FW on our devices, and we can still ensure the integrity of the
OpTee image if we load it early enough after the kernel boots.
The main questions I have are if there are any issues people would be aware
of by loading it after linux boots rather than during the usual BL32 stage?
And I would definitely want to upstream this work if it's something we can
do.
Thanks,
Jeffrey Kardatzke
Google, Inc.
Hi all,
I test the SMMUv3 on FVP_Base_RevC-2xAEMvA_11.20_15, and my TF-A is
the branch "arm_cca_v0.3".
When I boot my FVP, I set the following commands:
-C pci.pci_smmuv3.mmu.SMMU_ROOT_IDR0=3 \
-C pci.pci_smmuv3.mmu.SMMU_ROOT_IIDR=0x43B \
-C pci.pci_smmuv3.mmu.root_register_page_offset=0x20000 \
-C cluster0.rme_support_level=2 \
-C cluster1.rme_support_level=2 \
Based on the FVP manual, the SMMU base is 0x2b40_0000, and I think the
SMMU Root Control Page should be 0x2b42_0000.
Thus, I add the mapping to this region in plat_arm_mmap[], as:
MAP_REGION_FLAT(0x2b420000,(0x2b430000-0x2b420000),MT_MEMORY | MT_RW |MT_ROOT)
Then I try to access the SMMU_ROOT_IDR0 register in TF-A. Based on
the manual, its offset is 0x0, so I read 0x2b42_0000.
However, it returns 0x0, which is not what I configured in the boot
commands (I think it should be 0x3).
Can someone tell me the reason for this?
Sincerely,
WANG Chenxu
Hello everyone,
I'd like to draw your attention on the following patch stack
(contribution from Demi Marie Obenour, thank you!):
https://review.trustedfirmware.org/q/owner:demiobenour%2540gmail.com+is:open
These patches refactor the X.509 certificate parser leveraged by the
trusted boot implementation in TF-A, such that the parser more closely
follows the X.509 format specification [1] and ASN.1/DER encoding rules [2].
In a nutshell, this means that the X.509 parser is now stricter. Some
ill-formatted certificates which TF-A would have previously accepted are
now rejected.
All trusted boot tests in the TF-A OpenCI have passed with these patches
but I realize that this does not cover all platforms and use cases.
Thus, I'd like to allow time for all platform maintainers that wish it
to conduct their own testing and report any issue they're seeing on the
mailing list. If we don't hear anything by end of Wednesday (14/12),
we'll merge the patches.
Best regards,
Sandrine
[1] See RFC5280, https://datatracker.ietf.org/doc/html/rfc5280
[2] ITU-T X.690,
https://www.itu.int/ITU-T/studygroups/com10/languages/X.690_1297.pdf