I noticed TF-A currently supports passing in 4 parameters and returning
up to 8. But SMCCC 1.1+ supports passing up to 18 and returning 18 in
AArch64 mode, and passing in/out 8 in AArch32.
I was wondering if there are any plans to add support for handling the
full set of parameters?
--
Rebecca Cran
Hi
I'm new to TF-A and OP Tee.
While I am using qemu to start TF-A, I got BL1 detected and failed to load
BL2, due to BL2 size out of bounds.
I changed TF-A BL1 source code to show more information:
diff --git a/common/bl_common.c b/common/bl_common.c
index 2fcb5385d9..a6239a5257 100644
--- a/common/bl_common.c
+++ b/common/bl_common.c
@@ -110,7 +111,7 @@ static int load_image(unsigned int image_id,
image_info_t *image_data)
/* Check that the image size to load is within limit */
if (image_size > image_data->image_max_size) {
- WARN("Image id=%u size out of bounds\n", image_id);
+ WARN("Image id=%u size(%lu, %u) out of bounds\n", image_id,
image_size, image_data->image_max_size);
io_result = -EFBIG;
goto exit;
}
the log shows:
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.3():v2.3-dirty
NOTICE: BL1: Built : 15:56:43, Apr 20 2020
INFO: BL1: RAM 0xe04e000 - 0xe056000
VERBOSE: BL1: cortex_a57: CPU workaround for 806969 was not applied
WARNING: BL1: cortex_a57: CPU workaround for 813419 was missing!
VERBOSE: BL1: cortex_a57: CPU workaround for 813420 was not applied
VERBOSE: BL1: cortex_a57: CPU workaround for 814670 was not applied
WARNING: BL1: cortex_a57: CPU workaround for 817169 was missing!
INFO: BL1: cortex_a57: CPU workaround for disable_ldnp_overread was
applied
WARNING: BL1: cortex_a57: CPU workaround for 826974 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 826977 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 828024 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 829520 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 833471 was missing!
WARNING: BL1: cortex_a57: CPU workaround for 859972 was missing!
INFO: BL1: cortex_a57: CPU workaround for cve_2017_5715 was applied
INFO: BL1: cortex_a57: CPU workaround for cve_2018_3639 was applied
INFO: BL1: Loading BL2
VERBOSE: Using Memmap
WARNING: Firmware Image Package header check failed.
VERBOSE: Trying alternative IO
VERBOSE: Using Semi-hosting IO
INFO: Loading image id=1 at address 0xe01b000
WARNING: Image id=1 size(4294967295, 151552) out of bounds
ERROR: Failed to load BL2 firmware.
I'm using yocto (dunfell) + meta-arm to build / test TF-A + OP TEE under
qemuarm64.
meta-arm rev: c4f04f3fb66f8f4365b08b553af8206372e90a63
variables defined inside conf/local.conf ( for test )
23 MACHINE ?= "qemuarm64"
25
26 INSANE_SKIP_pn-optee-examples = "ldflags"
27 COMPATIBLE_MACHINE_pn-optee-examples = "qemuarm64"
28 COMPATIBLE_MACHINE_pn-optee-os = "qemuarm64"
29 COMPATIBLE_MACHINE_pn-optee-client = "qemuarm64"
30 COMPATIBLE_MACHINE_pn-trusted-firmware-a = "qemuarm64"
31
32 TFA_PLATFORM = "qemu"
33 TFA_UBOOT = "1"
34 TFA_DEBUG = "1"
35 TFA_SPD = "opteed"
36 TFA_BUILD_TARGET = "bl1 bl2 bl31"
37
38 OPTEEMACHINE:qemuarm64 = "vexpress-qemu_armv8a"
39 OPTEEOUTPUTMACHINE:qemuarm64 = "vexpress"
40
41 UBOOT_MACHINE_qemuarm64 = "qemu_arm64_defconfig"
I started qemu using following command line:
BIOS=tmp/deploy/images/qemuarm64/bl1.bin \
KERNEL=tmp/deploy/images/qemuarm64/Image-qemuarm64.bin \
runqemu mydefined-image-core-image-dev-optee nographic -d \
qemuparams=" \
-machine secure=on \
-m 4096 \
-d unimp -semihosting -semihosting-config enable=on,target=native \
"
Thanks
Hi all,
We made a few changes to the UFS driver. The proposed patches are posted
here:
https://review.trustedfirmware.org/q/topic:%22ufs_patches%22+(status:open%2…
.
The patches mainly consist of the below changes:
1. Delete asserts. Return error values instead.
2. Add retry logic and timeouts.
3. Reuse ufshc_send_uic_cmd() for DME_GET and DME_SET commands.
Any feedback/comments on these patches would be greatly appreciated.
Thanks!
Jorge Troncoso
+ TF-A ML (for the benefit of other trying to use firmware encryption
feature)
Hi Promod,
On Fri, 8 Oct 2021 at 00:09, pramod kumar <pramod.jnumca04(a)gmail.com> wrote:
> Hi Sumit,
>
> This is Pramod, Presently working in Amazon Lab126. I'm working in ATF and
> was going through your patch which provides f/w image encryption/decryption
> support.
>
> commit 7cda17bb0f92db39d123a4f2a1732c9978556453
> Author: Sumit Garg <sumit.garg(a)linaro.org>
> Date: Fri Nov 15 10:43:00 2019 +0530
>
> drivers: crypto: Add authenticated decryption framework
>
> Add framework for autheticated decryption of data. Currently this
> patch optionally imports mbedtls library as a backend if build option
> "DECRYPTION_SUPPORT = aes_gcm" is set to perform authenticated
> decryption
> using AES-GCM algorithm.
>
> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org>
> Change-Id: I2966f0e79033151012bf4ffc66f484cd949e7271
>
> I see that this support comes under DECRYPTION_SUPPORT macro hence can't
> be used dynamically. I see the TBBR spec provides a flag for this which
> could be used to exercise this feature dynamically-
> [image: image.png]
>
>
> Just wanted to understand that did you see any limitation to use this flag
> for making this feature support dynamically? Or do you have any plan to
> push follow up patches for this?
>
>
Actually there are security concerns associated if we use an unsigned
encryption flag in the header (see earlier discussions [1]).
> If this feature is made available, with the help of "disable_auth" flag,
> BL1 would be able to boot plane images even when TRUSTED_BOARD_BOOT is
> enabled in development mode.
>
I agree here that it would be useful to have such a flag in development
mode. For TRUSTED_BOARD_BOOT in development mode, I guess you are referring
to DYN_DISABLE_AUTH. If yes then I think such a macro makes sense for
encryption as well in order to disable decryption at runtime in development
mode, patches are very much welcome.
[1]
https://lists.trustedfirmware.org/pipermail/tf-a/2020-February/000288.html
-Sumit
> Regards,
> Pramod
>
Hi All,
We have refactored/redesigned the existing measured boot driver present in the TF-A repo to support it with multiple backend driver(s) (for example, TCG Event Log, physical TPM, etc) instead of it being strongly coupled with the TCG Event Log driver.
Proposed refactored patches are posted here: https://review.trustedfirmware.org/q/topic:%22refactor-mb%22+(status:open%2…
Any feedback/comments on these patches are much appreciated.
These patches mainly consist of the below changes:
1. Move image measurement in the generic layer, just after loading and authentication of the image. Previously, the platform layer was responsible for the measurement. For example, the Arm FVP platform layer was doing it as part of the post-load hook operation.
2. Measurement and recording of the images loaded by BL1. Previously, DTB config files loaded by BL1 were not part of measured at all. Also, it looks safer and cleaner approach to record the measurement taken by BL1 straightaway in TCG Event log buffer/physical TPM/any other TPM backend instead of deferring these recordings to BL2.
3. Pass Event Log buffer information from BL1 to BL2 so that the TCG Event Log buffer initialised by BL1 extended further with the measurements taken by BL2.
Note: These patches neither add any new functional backend driver for measured boot nor update any existing backend driver functionality (i.e. TCG Event Log driver). These changes only structured the measured boot code to provide a space to plug in any new backend driver(s) in future for the measured boot.
Thanks,
Manish Badarkhe
This event has been canceled with this note:
"Cancelling this weeks TF-A Tech Forum as we have no subjects/topics to
present for this meeting.
The TF-A project community is always looking for subjects/topics so if you
have something to present/discuss please do reach out to me and we can
schedule a session.
Thanks all."
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 Oct 7, 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
Hi all,
I tried submitting a change for review at https://review.trustedfirmware.org,
but I ran into authentication issues.
1. First try (https):
$ git push origin HEAD:refs/for/integration
Username for 'https://review.trustedfirmware.org': jatron
Password for 'https://jatron@review.trustedfirmware.org':
remote: Unauthorized
fatal: Authentication failed for '
https://review.trustedfirmware.org/TF-A/trusted-firmware-a/'
I tried clicking "GENERATE NEW PASSWORD" in
https://review.trustedfirmware.org/settings/, but I got the following
error message:
An error occurred
Error 500 (Server Error): Internal server error
Endpoint: /accounts/self/password.http
2. Second try (ssh):
I got the following error message when I tried registering a new SSH key
for use with Gerrit. This happened when I clicked "ADD NEW SSH KEY" in
https://review.trustedfirmware.org/settings/.
An error occurred
Error 500 (Server Error): Internal server error
Endpoint: /accounts/self/sshkeys
The error message didn't stop the GUI from recording my key though. My new
key was listed under "SSH keys" after the change. When I ran a git push
command using ssh, I got the following error.
$ git push ssh://jatron@review.trustedfirmware.org/TF-A/trusted-firmware-a
HEAD:refs/for/integration
jatron(a)review.trustedfirmware.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Am I doing something incorrectly? Any help would be much appreciated. If
this is not the mailing list for these types of questions, please let me
know so I can reroute my email to the proper destination.
Thanks,
Jorge Troncoso
Hi all,
I'm planning to submit a series of patches that aim to improve the
robustness and reusability of the UFS code. The impacted files
are drivers/ufs/ufs.c and include/drivers/ufs.h. The patches mainly consist
of the below changes:
1. Delete asserts. Return error values instead.
2. Add retry logic and timeouts.
3. Remove infinite loops.
4. Reuse ufshc_send_uic_cmd() for DME_GET and DME_SET commands.
5. Add a function ufs_send_cmd() that can be reused in other places.
ufs_send_cmd() calls four functions in
sequence: get_utrd(&utrd), ufs_prepare_cmd(&utrd,
...), ufs_send_request(utrd.task_tag), and ufs_check_resp(&utrd,
RESPONSE_UPIU).
I wanted to give everyone visibility of what is coming up and hopefully
start a discussion around this work. Any early input to help shape the
design would be much appreciated.
Thanks,
Jorge Troncoso
Hi all,
I want to write a TA which will be called from the Normal World and be
handled by a specific Trusted OS. Currently, I am using 3 Cactus OS
(provided by TF-A-Tests) in SEL1, and a Hafnium in SEL2. Here is my partial
building cmd
make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1
ARM_ARCH_MINOR=4 PLAT=fvp DEBUG=1
BL33=../tf-a-tests/build/fvp/debug/tftf.bin
BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin
SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json all fip
I have created some EL3 services at services/std_svc, but have not created
a TA.
In my view, to call the TA, I think I should pass (1) the ID of the TA (but
I am not sure how to get the ID) (2) several parameters, which may be
loaded into registers. Here may be a calling process.
ldr x0,=0xdeadbeef // loading ID
ldr x1,=0x11111 // input parameters
ldr x2,=0x22222 // input parameters
smc #0
Then I think I should write a corresponding handler (of the TA) in Cactus
OS. When we call "smc #0", EL3 will trap it, and route it to a specific TA.
However, I don't know how to do it. Can you provide some useful examples?
Sincerely,
Wang Chenxu