Hello tf experts,
I've been studying the PIE support in TF-A recently, and there is one thing
I'm confused about.
One is GOT table entry, is there any difference between this and .rela.dyn?
I have done some homework, but I didn't find the answer. If someone can
tell me, thanks a lot.
It looks like the current got segment is only 8 byte, so why must I need
this section? Which kind of code will put into this section?
Apologies we don't have any topics to present this week so I am cancelling the TF-A Tech forum for 17th June 2021.
We do however we have an exciting topic coming up for Thursday 1st July 2021 which we will share more about nearer the time.
In addition I’ll also like to promote this separate Linaro and Arm CCA Tech Event - Deep dive into Arm Confidential Compute Architecture the details of which can be found here https://www.linaro.org/events/linaro-and-arm-cca-tech-day-deep-dive-into-ar… Registration is free for this event which will begin at 14:00 UTC on June 23rd .
Thanks all.
Joanna
This event has been canceled with this note:
"Apologies we don't have any topics to present this week so I am cancelling
the Tech forum for 17th June 2021 however we have an exciting topic coming
up for Thursday 1st July 2021 which we will share near the time."
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 Jun 17, 2021 4pm – 5pm 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 organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hello,
We (Nico/Raghu) have been implementing SEL0 partitions for Tegra platforms and recently hit an issue, where the "entrypoint-offset" field of the SP manifest [1] cannot cope with increasing manifest blobs. The way the SP manifest is created today, the "entrypoint-offset" field is set to a value *statically* by the implementer. Down the line if the manifest grows past the value written in the "entrypoint-offset", we must manually update it. This needs to be fixed.
We believe there is an opportunity to upgrade the sptool to handle this situation during SP package creation, where sptool calculates the manifest size and bumps the "entrypoint-offset" past the end of the manifest. There are other ways of patching the SP manifest at runtime, but they seem sub-optimal.
Please let me know if there are other ideas to solve this problem. I will post a patch to update the sptool shortly but wanted to get the ball rolling.
Cheers.
[1] 14. FF-A manifest binding to device tree - Trusted Firmware-A documentation<https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-…>
Hi Francois,
The blobs are passed in memory only when the primary core boots. The linear id is required when both primaries and secondaries boot.
Secondly, the linear id is used to reference per-cpu structures in memory during very early initialisation. Putting the linear id in a memory structure would either require a per-cpu structure (chicken and egg) or a read-only global structure (to avoid complicated locks with the MMU turned off).
It seems to me that the linear id should be passed in an unused register specified by the partition manifest.
Passing it in the blob list seems a bit counter intuitive to me but happy to understand your thoughts better.
cheers,
Achin
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of François Ozog via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 14 June 2021 16:29
To: Lukas Hanel <lukas.hanel(a)trustonic.com>
Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: Re: [TF-A] Support for Kinibi in ATF/SPMD - linear ID
This looks like a good candidate for the bloblist discussion we have on other mail thread.
Why not aggregating "topology" metadata in a block rather than passing "random" information elements in registers?
On Thu, 10 Jun 2021 at 13:57, Lukas Hanel via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote:
Hi,
in this PR, I propose a first change to the SPMD to better support Kinibi, the TEE from Trustonic.
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235
The idea here is to pass the core linear id in the x3 register in the boot of secondary cores.
In the past, the Kinibi SPD was not public and so some requirements to TF-A were not visible to the wider community.
For Kinibi, one binary should run on a multitude of platforms.
For that reason, many platform-specific settings are shared by TF-A with Kinibi: at boot, in registers and in a boot datastructure, and at runtime.
In the line of work of making Kinibi compatible with FFA APIs, I moved some bits from the Kinibi SPD to the SPMD.
Instead of sharing such patches only with our customers, we would like to upstream the patches to the generic code.
For this particular patch, it is really simple and changes the interface SPMD-to-SPMC in a somewhat adhoc manner.
There is some discussion within ARM to standardize such behavior and to propose configuration options, i.e. within a manifest.
That way, you could change what register the linear id, if at all, should be transferred in.
A first tour of the CI showed that there seem to be no consequences to hafnium and optee.
I guess, question to the mailing list, is there something that this patch breaks?
Greetings,
Lukas
Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia Antipolis 06560 Valbonne, France – SAS au capital de 3 038 000€ - RCS Grasse – SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
[https://drive.google.com/a/linaro.org/uc?id=0BxTAygkus3RgQVhuNHMwUi1mYWc&ex…]
François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog
This looks like a good candidate for the bloblist discussion we have on
other mail thread.
Why not aggregating "topology" metadata in a block rather than passing
"random" information elements in registers?
On Thu, 10 Jun 2021 at 13:57, Lukas Hanel via TF-A <
tf-a(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> in this PR, I propose a first change to the SPMD to better support Kinibi,
> the TEE from Trustonic.
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235
>
> The idea here is to pass the core linear id in the x3 register in the boot
> of secondary cores.
>
> In the past, the Kinibi SPD was not public and so some requirements to
> TF-A were not visible to the wider community.
> For Kinibi, one binary should run on a multitude of platforms.
> For that reason, many platform-specific settings are shared by TF-A with
> Kinibi: at boot, in registers and in a boot datastructure, and at runtime.
>
> In the line of work of making Kinibi compatible with FFA APIs, I moved
> some bits from the Kinibi SPD to the SPMD.
> Instead of sharing such patches only with our customers, we would like to
> upstream the patches to the generic code.
>
> For this particular patch, it is really simple and changes the interface
> SPMD-to-SPMC in a somewhat adhoc manner.
> There is some discussion within ARM to standardize such behavior and to
> propose configuration options, i.e. within a manifest.
> That way, you could change what register the linear id, if at all, should
> be transferred in.
>
> A first tour of the CI showed that there seem to be no consequences to
> hafnium and optee.
> I guess, question to the mailing list, is there something that this patch
> breaks?
>
> Greetings,
> Lukas
>
>
> Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia
> Antipolis 06560 Valbonne, France – SAS au capital de 3 038 000€ - RCS
> Grasse – SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hi,
in this PR, I propose a first change to the SPMD to better support Kinibi, the TEE from Trustonic.
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235
The idea here is to pass the core linear id in the x3 register in the boot of secondary cores.
In the past, the Kinibi SPD was not public and so some requirements to TF-A were not visible to the wider community.
For Kinibi, one binary should run on a multitude of platforms.
For that reason, many platform-specific settings are shared by TF-A with Kinibi: at boot, in registers and in a boot datastructure, and at runtime.
In the line of work of making Kinibi compatible with FFA APIs, I moved some bits from the Kinibi SPD to the SPMD.
Instead of sharing such patches only with our customers, we would like to upstream the patches to the generic code.
For this particular patch, it is really simple and changes the interface SPMD-to-SPMC in a somewhat adhoc manner.
There is some discussion within ARM to standardize such behavior and to propose configuration options, i.e. within a manifest.
That way, you could change what register the linear id, if at all, should be transferred in.
A first tour of the CI showed that there seem to be no consequences to hafnium and optee.
I guess, question to the mailing list, is there something that this patch breaks?
Greetings,
Lukas
Trustonic SAS - 535 route de Lucioles, Les Aqueducs Batiment 2, Sophia Antipolis 06560 Valbonne, France - SAS au capital de 3 038 000EUR - RCS Grasse - SIRET 480 011 998 00055 - TVA intracommunautaire : FR02 480 011 998
Hi,
Can you try below steps, try with fresh pull?
1. Login with your github account on https://review.trustedfirmware.org/admin/repos/TF-A%2Ftrusted-firmware-a
2.
git clone "ssh://<user>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a
3. git push <remote-name> HEAD:refs/for/integration
4. While pushing if it complains about git hooks, run scp -p -P 29418 <user>@review.trustedfirmware.org:hooks/commit-msg "trusted-firmware-a/.git/hooks/" and amend your commit (it will give you this hint)
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Nicolas Boulenguez via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 03 April 2021 13:02
To: raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com>
Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; 'Benjamin Copeland' <ben.copeland(a)linaro.org>
Subject: Re: [TF-A] please fix incomplete distclean Makefile target
raghu.ncstate(a)icloud.com:
> Are you pushing ssh://<username>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration?
> Note that 29418 port. That tripped me up initially. It is not clear from your earlier emails where you cloned from(review.trustedfirmware.org or git.trustedfirmware.org).
[α] links to [β] which recommends
# git clone "https://review.trustedfirmware.org/TF-A/trusted-firmware-a"
I had an existing repository (most contributors probably do) and used
'git add remote' and 'git fetch' instead.
[α] recommends
# git push <remote-name> HEAD:refs/for/integration%<topic-branch>
As expected, the host requires a password.
# git push ssh://<user>@review.trustedfirmware.org:29418/TF-A/trusted-firmware-a HEAD:refs/for/integration?
-> fatal: invalid refspec 'HEAD:refs/for/integration?'
Anyhow, the host would require an SSH key.
[α] https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/
[β] https://review.trustedfirmware.org/admin/repos/TF-A%2Ftrusted-firmware-a
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
HI Hiren,
Can you please add more color to “even if I provide large enough string to hold the number, it does not print it”?
Are you saying that the library prints a partial value? If the calculation is off by 1, I assume, the library should at least print a partial value.
-Varun
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Hiren Mehta via TF-A
Sent: Saturday, May 29, 2021 9:41 AM
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] issue with vsnprintf() and unsigned_num_print()
External email: Use caution opening links or attachments
Hi All,
We are using the snprintf() (which uses vsnprintf() and unsigned_num_print()) from libc of ATF version 2.4
and running into an issue for printing a number into a string where even if I provide large enough string to hold the
number, it does not print it. I don't see that issue with it when I try to print a string using the same snprintf().
I understand that, as per the documentation use of snprintf is "banned or discouraged". But for the use case,
that we are using for, it is safe enough to use it assuming that it does it what it is supposed to do.
I am not sure if this is a known bug or what, but upon a further inspection, I found that there seems be a small bug
in the unsigned_num_print() for one of the 'if' condition given below which is causing the issue in terms of calculating
the available space in the string.
if (*chars_printed < n) {
.... do the prinring....
}
I believe it is supposed to be
if (*chars_printed <= n) { ----------------->> Notice '<=' instead of '<'
}
Any comment on whether this is on purpose or really a small bug?
The calling routine (vsnprintf) is already reducing 'n' by 1 for the terminating null character.
Thank you very much for your support.
-hiren