Hi,
I am trying to identify a mechanism to enforce a form of two-way
isolation between BL33 runtime services in OS, for instance:
- a pair of 2MB areas that could be RO by one entity and RW by the other
- an execute only BL33 2MB area?
This is similar to hypervisor except it only deals with memory, no
vCPU, no GIC virtualization...
Could EL3 or EL2 install protective mappings ? BL33 could ask either
EL2 hypervisor or SecureMonitor to actually install them.
Cordially,
FF
Hi,
As part of integrating Hafnium within Trusted Firmware projects, a new mailing list has been created:
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
You can register this list to participate to Hafnium in general, and coming S-EL2 firmware design discussions.
Regards,
Olivier.
Hi @François<mailto:francois.ozog@linaro.org>,
<quote>
Now, I changed U-Boot to Image, added code to ensure arg0 is 0 (DTB) but Linux does not start (zero printk visible).
I don't find kernel text base anymore, may be it disappeared: any suggestion to get the kernel start when loaded at 64KB offset?
the kernel image with embedded initrd is 10MB, SRAM is at 64MB so there should be enough space to decompress initrd...
</quote>
I recommend reading through the arm64 Linux booting requirements if you haven’t already; you’ll need to ensure all of those conditions are met before entering the kernel [1].
For example have you correctly set text_offset in the image header?
<quote>
u32 code0; /* Executable code */
u32 code1; /* Executable code */
u64 text_offset; /* Image load offset, little endian */
u64 image_size; /* Effective Image size, little endian */
u64 flags; /* kernel flags, little endian */
u64 res2 = 0; /* reserved */
u64 res3 = 0; /* reserved */
u64 res4 = 0; /* reserved */
u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
u32 res5; /* reserved (used for PE COFF offset) */
</quote>
<quote>
The Image must be placed text_offset bytes from a 2MB aligned base address anywhere in usable system RAM and called there.
</quote>
Kind regards,
Ash.
[1] https://elixir.bootlin.com/linux/latest/source/Documentation/arm64/booting.…
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Feng,
This is standard practice for operating systems, hypervisors, and firmware running on Armv8-A systems. A key distinction between SPSel,#0 and SPSel,#1 is that you can tell which stack pointer you were using when you took an exception as they correspond to different offsets in the vector table. Often times, taking an exception from the same EL when using SPSel,#0 is non-terminal whereas taking an exception from the same EL when already using SPSel,#1 is considered terminal.
Take for example the scenario where your operating system, hypervisor, or firmware is running some task/thread code at EL1/EL2/EL3 and runs out of stack space, triggering a translation fault and attempting to stack some data (we’ll probably be using unmapped guard pages at the stack boundaries). The first thing the exception handler will try to do is stack the GPRs. If the reason you took the exception is because the stack pointed to by SP_EL1/2/3 has itself overflowed, this attempt to stack the GPRs will itself cause a translation fault and you’ll get stuck in a recursive exception.
In contrast, if the reason you took the exception is because the stack pointed to by SP_EL0 has overflowed, the exception handler will successfully stack the GPRs to the SP_EL1/2/3 stack and be able to diagnose + log what went wrong before rebooting gracefully.
Hope that helps,
Ash.
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chen Feng via TF-A <tf-a(a)lists.trustedfirmware.org>
Reply to: Chen Feng <puck.chen(a)hisilicon.com>
Date: Friday, 17 April 2020 at 09:02
To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org>, Alexei Fedorov <Alexei.Fedorov(a)arm.com>, Yatharth Kochar <Yatharth.Kochar(a)arm.com>, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>
Cc: "puck.chen(a)hisilicon.com" <puck.chen(a)hisilicon.com>, "lizhong11(a)hisilicon.com" <lizhong11(a)hisilicon.com>
Subject: [TF-A] sp select in atf
Hello all,
I see the atf use different sp, and special for smc64 it use the sp_el0.
So for the unhandled-exception handler, it must switch to sp_el0 to do
the back-trace-dump. Since it default used sp_el3 when exception happen.
My question here is why using different sp in atf code? Just use the
sp_el3 for all scenes seems more simpler.
Cheers,
- feng
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello all,
I see the atf use different sp, and special for smc64 it use the sp_el0.
So for the unhandled-exception handler, it must switch to sp_el0 to do
the back-trace-dump. Since it default used sp_el3 when exception happen.
My question here is why using different sp in atf code? Just use the
sp_el3 for all scenes seems more simpler.
Cheers,
- feng
As of now ARM_LINUX_KERNEL_AS_BL33 is only supported when RESET_TO_BL31=1, along with it you need to pass PRELOADED_BL33_BASE as well as ARM_PRELOADED_DTB_BASE.
AFAIK This feature is not tested for platforms which uses all the BL(1/2/31) stages from TF-A . The most likely reason for this is loading and authentication of Linux Image.
BL2 which is responsible for loading of various images, does not have support to load linux image.
With platforms having RESET_TO_BL31, TF-A relies on prior loader which loads kernel and device tree blobs at respective address.
In short, if your platform has RESET_TO_BL31=1, it will be quite easy else you need to understand the BL2 loading mechanism and see if you can extend it for loading Linux and DTB.
Kernel Output format zImage/Image should work.
Hope this helps!
________________________________
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: 15 April 2020 13:31
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Linux as BL33
I want to use Linux as BL33 on a Marvell Macchiatobin.
Currently I have the successful boot flow:
TFA (mainline v2.2) -> U-Boot (Mainline 2020.04rc5) -> Kernel (5.6.3)
with U-root initrd (6.0.0, https://github.com/u-root/u-root ) ->
Ubuntu 19.10
The 5.6.3 "intermediary" kernel is 5.5MB uncompressed , u-root initrd
is 3.5MB compressed (some form of golang based busybox).
I was pointed to the ARM_LINUX_KERNEL_AS_BL33 option which is not
supported on the Macchiatobin.
It does not look too difficult to add, but I'd like to have some
feedback/guidance on how to do it:
- how to add the option to the TFA platform
- how to generate a usable kernel (compile options? non relocatable
kernel? output format, i.e. Image, zImage, uImage...)
Thanks for your help
-FF
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
+Harb
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Vivek Prasad via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: Thursday, April 16, 2020 10:19 AM
To: Stuart Yoder <stuart.yoder(a)arm.com>; Alexei Fedorov <Alexei.Fedorov(a)arm.com>; tf-a <tf-a(a)lists.trustedfirmware.org>; Raghu Krishnamurthy <raghu.ncstate(a)icloud.com>
Cc: Loc Ho <loc.ho(a)amperecomputing.com>; Vivek Kumar <vivek(a)amperecomputing.com>; Benjamin Chaffin <bchaffin(a)amperecomputing.com>; Ard Biesheuvel <Ard.Biesheuvel(a)arm.com>; Mohamad Ammar <moe(a)amperecomputing.com>; Charles Garcia-Tobin <Charles.Garcia-Tobin(a)arm.com>
Subject: Re: [TF-A] Proposal for Measured Boot Implementation
Hello Stuart, Alexei,
Chiming-in here on Ampere's behalf...
We analysed this proposal internally. And we see a number issues with this, some of which was already raised by Raghu in the previous threads.
Here is a summary of the main issues that we see.
* Only supporting mbedtls, and this is fixed config at compile time.
* We propose that there should be a variable for the algorithm to be used, which can be setup at initialization time.
* This solution relies on taking the hash directly from the digest as the measurement, instead of the computed hash. This is not safe, especially considering measured boot may use a different hash bank, so digest hash may not be correct/valid.
* Only measuring the BL2 image, per the ARM SBSG we must be measuring and logging *all* images/boot phases
* BL31
* BL32 (all secure partitions)
* BL33 (UEFI or any other non-secure boot loader)
* Once we ERET into BL33, the measure boot flow continues and is owned by that boot loader
* Only see support for PCR0, any/all unsigned config data must be logged to PCR1.
* Passing PCRs to non-secure software before logging is not compliant with TCG Static-Root-of-Trust Measurement (SRTM) requirements
* It was discussed before in separate conversations… especially in systems where you are talked about two different signing domains where BL33 is a different trust/signing domain.
* BL33 should only do hash-log-extend… there is no need for BL33 to be aware of the current PCR value (beyond what is provided in the boot event log).
* Based on comments on the mail thread, there seem to be bad assumptions/expectations around TPM accessibility from non-secure world.
* Expecting SPI/I2C TPMs to be directly accessed from non-secure world instead of abstracting hardware details via the TCG CRB interface (which has been already standardized as the defacto mechanism for ARM on past mobile, client, and server solutions).
* CRB will "just work" for Aptio/EDK2/Linux/Windows/Hyper-V/VMWare
* NOTE: This goes back to what is a “productizable” TPM solution. We want it to be turn-key solution for customers without having to support/develop proprietary drivers.
-Vivek/Harb
Hi all,
Thanks to all who have commented on this proposal so far. I've edited
the original document to try and incorporate all feedback gathered so
far (through the TSC meeting, this email thread and the TF-A tech call).
Please have another look and flag anything I might have missed:
https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…
The major changes are:
== Removed concept of self-review ==
This is proving too controversial, several people do not want to allow
self-review.
Roles of maintainer and code owner are still cumulative but cannot be
both exercised for the same patch.
The exact method of dealing with review bottleneck is still to be
decided. In addition to the current proposal of increasing the
maintainers pool, the most popular alternatives mentioned so far are:
- Set a minimum wait time for feedback before a patch can be merged
without any further delay.
- Mandate distinct reviewers for a patch.
== Enhanced the section "Patch contribution Guidelines" ==
Mentioned that patches should be small, on-topic, with comprehensive
commit messages.
== Added a note about how to deal with disagreement ==
If reviewers cannot find a common ground, the proposal is to call out a
3rd-party maintainer.
== Removed "out-of-date" platform state ==
Squashed it into "limited support" to reduce the number of states.
== Removed "orphan" state from platform support life cycle ==
This concept is orthogonal to the level of functionality.
Added a note in the "Code Owner" section instead.
== Per-project guidelines as a complementary document ==
Added a list of things that it would typically cover.
== Added requirement on fully supported platforms to document the
features they support ==
== Added todo mentioning that the proposal might cover branching
strategies in the future ==
The full diff may be seen here:
https://developer.trustedfirmware.org/phriction/diff/73/?l=4&r=5
This proposal is still open for discussion at this stage and further
feedback is most welcome!
Regards,
Sandrine
I want to use Linux as BL33 on a Marvell Macchiatobin.
Currently I have the successful boot flow:
TFA (mainline v2.2) -> U-Boot (Mainline 2020.04rc5) -> Kernel (5.6.3)
with U-root initrd (6.0.0, https://github.com/u-root/u-root ) ->
Ubuntu 19.10
The 5.6.3 "intermediary" kernel is 5.5MB uncompressed , u-root initrd
is 3.5MB compressed (some form of golang based busybox).
I was pointed to the ARM_LINUX_KERNEL_AS_BL33 option which is not
supported on the Macchiatobin.
It does not look too difficult to add, but I'd like to have some
feedback/guidance on how to do it:
- how to add the option to the TFA platform
- how to generate a usable kernel (compile options? non relocatable
kernel? output format, i.e. Image, zImage, uImage...)
Thanks for your help
-FF
