Hello all,
I have been trying to ease the process of adding a Secure Partition to a system using Secure Hafnium.
There is no way to automatically generate SP's specific configuration into TF-A's code-base. Considering FVP as the target platform, we need to manually add partition's specific configuration to files "fvp_tb_fw_config.dts" and "fvp_spmc_manifest.dts" (files held in FVP platform specific folder of TF-A codebase). The following snippet shows the hypervisor node from "fvp_spmc_manifest.dts", for the simple case of having in the system two Cactus Secure Partitions:
hypervisor {
compatible = "hafnium,hafnium";
vm1 {
is_ffa_partition;
debug_name = "cactus-primary";
load_address = <0x7000000>;
};
vm2 {
is_ffa_partition;
debug_name = "cactus-secondary";
load_address = <0x7100000>;
vcpu_count = <2>;
mem_size = <1048576>;
};
};
Some of the above properties are available in the partition's manifest, for example "debug_name" and "load_address".
If changing one of these values in the partition's manifest or adding another SP, we also need to update the referred files.
In order to avoid the burden of having to manually update partition's specific configuration and to make whole system more scalable, I started to write a script that is able to generate a specific node structure and fetch any property value from a any dts file. Then, applied it to fetch/generate SPs specific configuration and include it in aforementioned configuration files.
Although it is still a Work In Progress, the work can be found in the patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5150.
The implementation is divided between two scripts:
* "dts_gen.py" - This is a generic solution for the problem. It can fetch/generate/alter any configuration using dts files.
* "sp_dts_gen.py" - Uses the previous command to solve the specific problem regarding SPs specific configuration.
Although is still Work In Progress, I am looking to obtain feedback/reviews from anyone that could be interested in using this implementation.
The above files contain a lot of comments on how to use them, and also describing the implementation.
If the obtained feedback is good, I can work on integrating this in TF-A's build-system.
Let me know if anyone has questions.
Best regards,
João Alves
Hi,
On a Stage-2 page fault, Hafnium does not report FAR_EL2 to FAR_EL1 in inject_el1_exception .
As a consequence EL1 is resumed although it cannot determine the faulting address from FAR_EL1 (which likely holds zero or some other remnant value?).
Is this intended?
Regards,
Olivier.
Hi Olivier/Andrew,
> On 22 Jul 2020, at 15:08, Andrew Walbran via Hafnium <hafnium(a)lists.trustedfirmware.org> wrote:
>
> On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium <
> hafnium(a)lists.trustedfirmware.org> wrote:
>
>> Hi,
>>
>> We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented
>> ABIs with the SMC32 convention, but FFA_RXTX_MAP_64:
>> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
Did you mean : https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1510
>>
>> On the other hand ffa_handler discards the SMC convention bit:
>>
>> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h…
What is the rationale behind this? As per the SMCCC: -1 must be returned for an SMC64/HVC64 call from AArch32 state or an unknown function ID. In the latter case, if the spec don’t list it then it ain’t there :)
>>
>> It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail,
>> although this does not prevent effectively calling the same ABI with the
>> SMC32 convention.
>>
>> Is there some fine tuning to do here?
>> Should we just discard the SMC convention bit in api_ffa_features?
>>
>
> I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses
> for the buffers that it passes. We should probably return an error from
> ffa_handler if a VM tries to call FFA_RXTX_MAP_32.
Does Hafnium not intend to work with AArch32 SPs? Is this is a requirement that has been spelt out so the community ensures no AArch32 SPs are presented. The SPM design doc catered for this requirement the last time I checked.
>
> For other functions I guess we could make it support either, by discarding
> the SMC convention bit in FFA_FEATURES as you suggest. Are there any other
> differences between the SMC32 and SMC64 convention which we need to take
> care of?
I think we need to make a more informed choice. For example, what if FFA_FEATURES is called with the non-existent 64-bit FID for FFA_ID_GET, FFA_RXTX_UNMAP, FFA_PARTITION_INFO_GET, FFA_MEM_FRAG_RX, FFA_MEM_FRAG_TX etc.
Cheers,
Achin
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
On Wed, 22 Jul 2020 at 15:01, Olivier Deprez via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented
> ABIs with the SMC32 convention, but FFA_RXTX_MAP_64:
> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
>
> On the other hand ffa_handler discards the SMC convention bit:
>
> https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h…
>
> It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail,
> although this does not prevent effectively calling the same ABI with the
> SMC32 convention.
>
> Is there some fine tuning to do here?
> Should we just discard the SMC convention bit in api_ffa_features?
>
I don't think FFA_RXTX_MAP_32 will work, because we need 64-bit addresses
for the buffers that it passes. We should probably return an error from
ffa_handler if a VM tries to call FFA_RXTX_MAP_32.
For other functions I guess we could make it support either, by discarding
the SMC convention bit in FFA_FEATURES as you suggest. Are there any other
differences between the SMC32 and SMC64 convention which we need to take
care of?
Hi,
We noticed api_ffa_features returns FFA_SUCCESS_32 for all implemented ABIs with the SMC32 convention, but FFA_RXTX_MAP_64:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/api.c#n1430
On the other hand ffa_handler discards the SMC convention bit:
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/src/arch/aarch64/h…
It means one can call FFA_FEATURES(FFA_RXTX_MAP_32) which will fail,
although this does not prevent effectively calling the same ABI with the SMC32 convention.
Is there some fine tuning to do here?
Should we just discard the SMC convention bit in api_ffa_features?
Regards,
Olivier.
Yep, mm_vm_dump sounds like what you're looking for. You can add a call
where you like and it will go to the log UART.
On Thu, 16 Jul 2020 at 19:14, Raghu K via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Quick search indicates mm_vm_dump() and the functions it calls in
> src/mm.c should do what you want. i've not tried it or don't know the
> format, but this may be what you are looking for.
>
> -Raghu
>
> On 7/16/20 11:03 AM, Madhukar Pappireddy via Hafnium wrote:
> > Hi,
> >
> > I was wondering if there is support in Hafnium to dump page tables to a
> log file. I am new to the Hafnium project and would appreciate any help.
> Below is an example from TF-A which provides such provision.
> >
> > ......<snip>
> > VERBOSE: Translation tables state:
> > VERBOSE: Xlat regime: EL3
> > VERBOSE: Max allowed PA: 0xfffffffff
> > VERBOSE: Max allowed VA: 0xfffffffff
> > VERBOSE: Max mapped PA: 0x2f1fffff
> > VERBOSE: Max mapped VA: 0x2f1fffff
> > VERBOSE: Initial lookup level: 1
> > VERBOSE: Entries @initial lookup level: 64
> > VERBOSE: Used 3 sub-tables out of 5 (spare: 2)
> > [LV1] VA:0x0 size:0x40000000
> > [LV2] VA:0x0 size:0x200000
> > [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S
> > [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S
> > [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S
> > [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S
> > [LV3] VA:0xb000 size:0x1000
> > [LV3] (500 invalid descriptors omitted)
> > [LV2] VA:0x200000 size:0x200000
> > [LV2] (30 invalid descriptors omitted)
> > [LV2] VA:0x4000000 size:0x200000
> > ..... <snip>
> >
> > Thanks,
> > Madhukar
> >
>
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
Quick search indicates mm_vm_dump() and the functions it calls in
src/mm.c should do what you want. i've not tried it or don't know the
format, but this may be what you are looking for.
-Raghu
On 7/16/20 11:03 AM, Madhukar Pappireddy via Hafnium wrote:
> Hi,
>
> I was wondering if there is support in Hafnium to dump page tables to a log file. I am new to the Hafnium project and would appreciate any help. Below is an example from TF-A which provides such provision.
>
> ......<snip>
> VERBOSE: Translation tables state:
> VERBOSE: Xlat regime: EL3
> VERBOSE: Max allowed PA: 0xfffffffff
> VERBOSE: Max allowed VA: 0xfffffffff
> VERBOSE: Max mapped PA: 0x2f1fffff
> VERBOSE: Max mapped VA: 0x2f1fffff
> VERBOSE: Initial lookup level: 1
> VERBOSE: Entries @initial lookup level: 64
> VERBOSE: Used 3 sub-tables out of 5 (spare: 2)
> [LV1] VA:0x0 size:0x40000000
> [LV2] VA:0x0 size:0x200000
> [LV3] VA:0x0 PA:0x0 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x1000 PA:0x1000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x2000 PA:0x2000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x3000 PA:0x3000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x4000 PA:0x4000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x5000 PA:0x5000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x6000 PA:0x6000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x7000 PA:0x7000 size:0x1000 MEM-RO-EXEC-S
> [LV3] VA:0x8000 PA:0x8000 size:0x1000 MEM-RO-XN-S
> [LV3] VA:0x9000 PA:0x9000 size:0x1000 MEM-RO-XN-S
> [LV3] VA:0xa000 PA:0xa000 size:0x1000 MEM-RO-XN-S
> [LV3] VA:0xb000 size:0x1000
> [LV3] (500 invalid descriptors omitted)
> [LV2] VA:0x200000 size:0x200000
> [LV2] (30 invalid descriptors omitted)
> [LV2] VA:0x4000000 size:0x200000
> ..... <snip>
>
> Thanks,
> Madhukar
>
Hi All,
The next TF-A Tech Forum is scheduled for Thu 16th July 2020 16:00 – 17:00 (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:
* Secure EL2 SPM (Secure Partition Manager) Hafnium-based
* In this TF-A Tech Forum session we present the status and open roadmap for the Secure Partition Manager firmware development. The TF-A SPM is the reference open source implementation for the PSA FF-A (Platform Security Architecture Firmware Framework for A-class) specification in the Secure world. It leverages the Armv8.4-Secure EL2 extension bringing virtualization technology in the Secure world (S-EL2 exception level). The development derives originally from the Google Hafnium project, which has been recently transitioned to https://www.trustedfirmware.org/ under the BSD 3-Clause license.
* 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
