This event has been cancelled.
Title: TF-A Tech Forum
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
When: Thu 3 Dec 2020 16:00 – 17:00 United Kingdom Time
Calendar: tf-a(a)lists.trustedfirmware.org
Who:
* Bill Fletcher- creator
* 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 courtesy email at the account
tf-a(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively, you can sign up for a Google Account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organiser and be added to the guest list, invite others regardless of
their own invitation status or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hi Heyi,
Happy to discuss the detail but the short answer is no.
Instead, it is possible to run an MM partition in S-EL0 under the TEE. This work is being done with OP-TEE.
From a SW architecture standpoint, it did not seem like a good idea to let EL3 run its "application" i.e. MM SP alongside a TEE which also runs its own applications. It is better to let the TEE own S-EL1 and run all applications in S-EL0 under it.
Cheers,
Achin
On 23/11/2020, 05:36, "TF-A on behalf of Heyi Guo via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hi All,
On some platforms there may be requirements to run both TEE and SPM_MM
instances, such as providing TEE services on server platforms.
Do TF-A support this scenario? If it doesn't, do it make sense to add
such support?
Thanks,
Heyi
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi All,
On some platforms there may be requirements to run both TEE and SPM_MM
instances, such as providing TEE services on server platforms.
Do TF-A support this scenario? If it doesn't, do it make sense to add
such support?
Thanks,
Heyi
Hi All,
The next TF-A Tech Forum is scheduled for Thu 19th November 2020 16:00 – 17:00 (GMT).
Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from BST.
A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know.
Agenda:
* Trace-based Code Coverage Tooling for Firmware Projects
* Presented by Basil Eljuse & Saul Romero
* Summary
* TF-A has adopted a code coverage system to measure the effectiveness of the various runtime testing performed and this is achieved without doing code instrumentation. This presentation is an overview of that approach which has applicability beyond the TF-A project.
* Optional TF-A Mailing List Topic Discussions
If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled.
Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list.
Thanks
Joanna
Hi All,
i've been trying for a couple of days to load current optee together with atf from the github, with no luck. For that i have been using manuals (https://trustedfirmware-a.readthedocs.io/en/latest/plat/rockchip.html , http://opensource.rock-chips.com/wiki_ATF ) for rockchip and what i have succeded is to run very old atf tag 1.3 with optee blob from rockchip which i suspect is also very old. And if i try to use any newer atf >= 1.4 than i suspect that it does not load, because i do not see any LOGS from it, no matter that LOG_LEVEL was set to 50...
Can anybody help me solving this issue or point me to some solution? Thanks in advance.
BR
Piotr Łobacz
[https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png]<https://www.softgent.com>
Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND
KRS: 0000674406, NIP: 9581679801, REGON: 367090912
www.softgent.com
Sąd Rejonowy Gdańsk-Północ w Gdańsku, VII Wydział Gospodarczy Krajowego Rejestru Sądowego
KRS 0000674406, Kapitał zakładowy: 25 000,00 zł wpłacony w całości.
Hi Julius,
The TF-A build sets the `-mstrict-align` compiler option, that means that the compiler will generate only aligned accesses as default. So disabling the check at runtime, seems `unaligned` with the compiler option IMO. The programmer can induce unaligned access though, although I am struggling to understand why the programmer would want to do that. The case you have pointed out seems like an error which needs to be corrected in platform code IMO.
> Well, my assumption is that performing an unaligned access cannot be a
> vulnerability.
TF-A has linker symbol references and non-trivial linker section manipulations at runtime and these have previously triggered alignment errors when binary layout changed due to code issues. Disabling the alignment check at runtime means these errors would have remained undetected and would have resulted in more obscure crash at runtime or even a vulnerablility. In some cases, only the RELEASE builds (DEBUG=0) triggered the alignment fault.
> There are scenarios where unaligned accesses can be intentional, but I am not too worried about those -- there are ways to work around that, and if we make it policy that those accesses always need to be written that way I'm okay with that. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production. If the main reason you're enabling this flag is to help with early detection of coding mistakes, I wonder if the best approach would be to enable it for DEBUG=1 and disable it for DEBUG=0 (of course, if there are really security issues associated with it like you mentioned above, that wouldn't make sense).
Agree. But I am failing to understand why the unaligned accesses came to be there in the first place. My worry is, if this was not intended by the programmer, this might as well be a bug that will remain undetected if the alignment check is disabled.
Best Regards
Soby Mathew
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius
> Werner via TF-A
> Sent: 10 November 2020 02:31
> To: raghu.ncstate(a)icloud.com
> Cc: tf-a <tf-a(a)lists.trustedfirmware.org>
> Subject: Re: [TF-A] Alignment fault checking in EL3
>
> > >>. What I am worried about is mistakes and oversights that slip
> > >>through testing and then cause random or even attacker-controllable
> > >>crashes in production
> >
> > Why would this not be the case even with SCTLR.A bit set? I'm not seeing
> the relation between the crash and SCTLR.A bit. If there are oversights that
> slip through testing and an attacker can cause a crash, there is
> vulnerability/bug.
> > If there is something that slipped through, that causes a data
> abort(perhaps address not mapped in the translation tables), would we turn
> off the MMU ?
>
> Well, my assumption is that performing an unaligned access cannot be a
> vulnerability. If you have examples to the contrary please let me know, but
> as far as I am aware letting an unaligned access through should always work
> and will always result in the behavior the programmer intended (other than
> maybe contrived cases where device address space is mapped with a non-
> Device memory type, which is already very wrong for plenty of other reasons
> and should never happen). The only negative consequence is that the access
> may take slightly longer than if it were aligned. I do understand the desire to
> be able to shake out unaligned accesses during development and testing
>
> I don't think the comparison to a data abort works because obviously with a
> data abort the program usually can't just continue and still assume its internal
> state is valid.