I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3. I placed an HS_DEBUG command to print the ID, which returns 1023. The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops.
I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code?
Ian Burres
Cybersecurity R&D
Hi Bin Wu,
Thanks for coming up with this question.
As per the below signature verification code, you raised a valid point that signature gets verified before ROTPK hash verification.
1. Get ROTPK hash from the platform (Using platform implemented method e.g., HW register).
2. Extract ROTPK from the image itself.
3. Use ROTPK to verify the image signature.
4. Calculate the hash of ROTPK and compare it against the hash received in step[1].
But we can't see any concern as the system fails to boot anyways at step [4] if the ROTPK gets corrupted.
Regards
Manish Badarkhe
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of 吴斌(郅隆) via TF-A <tf-a(a)lists.trustedfirmware.org>
Date: Friday, 29 January 2021 at 07:55
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] PK hash verify after signature virified
Hi All,
I am studying tbbr module in ATF recenlty. I have a little confusion about the ROTPK hash verify flow.
In ATF current implementation, we will verify the signature first, then verify the ROTPK hash.
But in my understanding, we should verify ROTPK first then verify signature.
So, what is the consideration that we use current flow in ATF?
Thanks for you patience
BRs，
Bin Wu
Hi All,
I am studying tbbr module in ATF recenlty. I have a little confusion about the ROTPK hash verify flow.
In ATF current implementation, we will verify the signature first, then verify the ROTPK hash.
But in my understanding, we should verify ROTPK first then verify signature.
So, what is the consideration that we use current flow in ATF?
Thanks for you patience
BRs，
Bin Wu
Hi All,
The next TF-A Tech Forum is scheduled for Thu 28th January 2021 16:00 – 17:00 (GMT).
Agenda:
* TF-A: Automotive Enhance (AE) Architecture Support Requirements Discussion
* Presented by Manish Pandy and Manish Badarkhe
* A discussion on the needs for the Automotive Enhance (AE) space and how TF-A can support that with CPU and GIC capabilities. The goal is to follow-up the recent email to the TF-A mailing list and try and understand project needs in this space by talking to the project community.
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: 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 on the TF-A mailing list.
Join Zoom Meeting
https://zoom.us/j/9159704974<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F9159704974&sa=D&us…>
Meeting ID: 915 970 4974
One 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-free
Meeting ID: 915 970 4974
Find your local number: https://zoom.us/u/ad27hc6t7h<https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fu%2Fad27hc6t7h&sa=D&us…>
Thanks
Joanna
<Cc alias>
I guess, something went wrong when I clicked "Reply all" the first time.
Manish, can you also talk about the tasks that Arm is willing to work on? Then we can ask for volunteers for the remaining ones. I'm sure, NVIDIA will contribute as this topic is close to our heart.
-Varun
From: Manish Pandey2 <Manish.Pandey2(a)arm.com>
Sent: Monday, January 25, 2021 8:05 AM
To: Varun Wadekar <vwadekar(a)nvidia.com>
Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com>; Robin Randhawa <Robin.Randhawa(a)ARM.com>; Ed Doxat <Ed.Doxat(a)arm.com>; Joanna Farley <joannafarley(a)icloud.com>; Manish Badarkhe <Manish.Badarkhe(a)arm.com>; Olivier Deprez <Olivier.Deprez(a)arm.com>; Matteo Carlini <Matteo.Carlini(a)arm.com>; Doug Richmond <Doug.Richmond(a)arm.com>
Subject: Re: Gather GIC changes required for safety critical machines
External email: Use caution opening links or attachments
++ Other Arm folks
Just realized that Varun has reduced the recipients(guess that was intentional)
________________________________
From: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>
Sent: 25 January 2021 10:15
To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>
Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>>
Subject: Re: Gather GIC changes required for safety critical machines
Hi Varun,
We are trying to do both, based on interest from community we will prioritize these tasks.
The reason why we can't do all the asks (mentioned in the list) ourselves is, currently we do not have "use cases/platforms" to test all the features, so we would rely on wider community to understand the requirements and work together to develop/test those features.
Thanks
Manish
________________________________
From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>
Sent: 22 January 2021 17:46
To: Manish Pandey2 <Manish.Pandey2(a)arm.com<mailto:Manish.Pandey2@arm.com>>
Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>>
Subject: RE: Gather GIC changes required for safety critical machines
HI Manish,
Thanks for starting this discussion. The list captures all the functionalities that are useful and interesting to us.
Trying to understand the ask - are you trying to get feedback to allow you to prioritize the feature list? Or are you asking for the community to rate importance of these requirements?
I am afraid, if there isn't enough interest the list might be trimmed which would be an absolute shame.
-Varun
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Manish Pandey2 via TF-A
Sent: Friday, January 22, 2021 8:02 AM
To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
Cc: Filipe Rinaldi <Filipe.Rinaldi(a)arm.com<mailto:Filipe.Rinaldi@arm.com>>; Robin Randhawa <Robin.Randhawa(a)ARM.com<mailto:Robin.Randhawa@ARM.com>>; Ed Doxat <Ed.Doxat(a)arm.com<mailto:Ed.Doxat@arm.com>>
Subject: [TF-A] Gather GIC changes required for safety critical machines
External email: Use caution opening links or attachments
Hi,
GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A.
Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned.
We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers.
GIC-600AE feature requirement:
- Inject and detect RAS errors using Fault management unit(FMU)
- Validating feature parity with GIC600
- Running GIC IP in Dual core Lock-step(DCLS) mode.
GIC/RAS driver enhancements:
- Read trace and PMU records
- Keep RAS error records alive across a reset
- Disable GICR frames of fused-off cores
- Support for message signalled interrupts
- Saving/Restoring additional GIC registers during PM events
Feel free to add any additional requirements.
If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail.
Thanks
Manish
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.
v9: - cosmetic changes (move if from patch2 to patch3, rename function name
and define).
v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff,
change define names, trigger on upper front. (Peter Maydell).
v7: - same as v6, but resplit patches: patch 2 no function changes and refactor
gpio setup for virt platfrom and patch 3 adds secure gpio.
v6: - 64k align gpio memory region (Andrew Jones)
- adjusted memory region to map this address in the corresponding atf patch
v5: - removed vms flag, added fdt (Andrew Jones)
- added patch3 to combine secure and non secure pl061. It has to be
more easy to review if this changes are in the separate patch.
v4: rework patches accodring to Peter Maydells comments:
- split patches on gpio-pwr driver and arm-virt integration.
- start secure gpio only from virt-6.0.
- rework qemu interface for gpio-pwr to use 2 named gpio.
- put secure gpio to secure name space.
v3: added missed include qemu/log.h for qemu_log(..
v2: replace printf with qemu_log (Philippe Mathieu-Daudé)
This patch works together with ATF patch:
https://github.com/muvarov/arm-trusted-firmware/commit/886965bddb0624bdf851…
Maxim Uvarov (3):
hw: gpio: implement gpio-pwr driver for qemu reset/poweroff
arm-virt: refactor gpios creation
arm-virt: add secure pl061 for reset/power down
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++--------
hw/gpio/Kconfig | 3 ++
hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++
hw/gpio/meson.build | 1 +
include/hw/arm/virt.h | 2 +
6 files changed, 167 insertions(+), 21 deletions(-)
create mode 100644 hw/gpio/gpio_pwr.c
--
2.17.1
Hi,
GIC600-AE is variant of GIC for safety critical machines, though its TRM is publicly available from quite some time but currently we do not have support in TF-A.
Purpose of this email is to kick start discussions around various possible GIC requirements as far as safety critical machines are concerned.
We have created following list of requirements based on inputs we got so far, changes are either adding new AE features or enhancements to existing drivers.
GIC-600AE feature requirement:
- Inject and detect RAS errors using Fault management unit(FMU)
- Validating feature parity with GIC600
- Running GIC IP in Dual core Lock-step(DCLS) mode.
GIC/RAS driver enhancements:
- Read trace and PMU records
- Keep RAS error records alive across a reset
- Disable GICR frames of fused-off cores
- Support for message signalled interrupts
- Saving/Restoring additional GIC registers during PM events
Feel free to add any additional requirements.
If there is enough community interest during the next Tech-forum meeting(28th Jan) we would like to go through these requirements in more detail.
Thanks
Manish
v8: - use gpio 0 and 1, align dtb with kernel gpio-restart, gpio-poweroff,
change define names, trigger on upper front. (Peter Maydell).
v7: - same as v6, but resplit patches: patch 2 no function changes and refactor
gpio setup for virt platfrom and patch 3 adds secure gpio.
v6: - 64k align gpio memory region (Andrew Jones)
- adjusted memory region to map this address in the corresponding atf patch
v5: - removed vms flag, added fdt (Andrew Jones)
- added patch3 to combine secure and non secure pl061. It has to be
more easy to review if this changes are in the separate patch.
v4: rework patches accodring to Peter Maydells comments:
- split patches on gpio-pwr driver and arm-virt integration.
- start secure gpio only from virt-6.0.
- rework qemu interface for gpio-pwr to use 2 named gpio.
- put secure gpio to secure name space.
v3: added missed include qemu/log.h for qemu_log(..
v2: replace printf with qemu_log (Philippe Mathieu-Daudé)
This patch works together with ATF patch:
https://github.com/muvarov/arm-trusted-firmware/commit/886965bddb0624bdf851…
Maxim Uvarov (3):
hw: gpio: implement gpio-pwr driver for qemu reset/poweroff
arm-virt: refactor gpios creation
arm-virt: add secure pl061 for reset/power down
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 111 ++++++++++++++++++++++++++++++++++--------
hw/gpio/Kconfig | 3 ++
hw/gpio/gpio_pwr.c | 70 ++++++++++++++++++++++++++
hw/gpio/meson.build | 1 +
include/hw/arm/virt.h | 2 +
6 files changed, 167 insertions(+), 21 deletions(-)
create mode 100644 hw/gpio/gpio_pwr.c
--
2.17.1
v7: - same as v6, but resplit patches: patch 2 no function changes and refactor
gpio setup for virt platfrom and patch 3 adds secure gpio.
v6: - 64k align gpio memory region (Andrew Jones)
- adjusted memory region to map this address in the corresponding atf patch
v5: - removed vms flag, added fdt (Andrew Jones)
- added patch3 to combine secure and non secure pl061. It has to be
more easy to review if this changes are in the separate patch.
v4: rework patches accodring to Peter Maydells comments:
- split patches on gpio-pwr driver and arm-virt integration.
- start secure gpio only from virt-6.0.
- rework qemu interface for gpio-pwr to use 2 named gpio.
- put secure gpio to secure name space.
v3: added missed include qemu/log.h for qemu_log(..
v2: replace printf with qemu_log (Philippe Mathieu-Daudé)
This patch works together with ATF patch:
https://github.com/muvarov/arm-trusted-firmware/commit/7556d07e87f755c602cd…
Previus discussion for reboot issue was here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html
Maxim Uvarov (3):
hw: gpio: implement gpio-pwr driver for qemu reset/poweroff
arm-virt: refactor gpios creation
arm-virt: add secure pl061 for reset/power down
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 117 ++++++++++++++++++++++++++++++++++--------
hw/gpio/Kconfig | 3 ++
hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++
hw/gpio/meson.build | 1 +
include/hw/arm/virt.h | 2 +
6 files changed, 174 insertions(+), 20 deletions(-)
create mode 100644 hw/gpio/gpio_pwr.c
--
2.17.1
v6: - 64k align gpio memory region (Andrew Jones)
- adjusted memory region to map this address in the corresponding atf patch
v5: - removed vms flag, added fdt (Andrew Jones)
- added patch3 to combine secure and non secure pl061. It has to be
more easy to review if this changes are in the separate patch.
v4: rework patches accodring to Peter Maydells comments:
- split patches on gpio-pwr driver and arm-virt integration.
- start secure gpio only from virt-6.0.
- rework qemu interface for gpio-pwr to use 2 named gpio.
- put secure gpio to secure name space.
v3: added missed include qemu/log.h for qemu_log(..
v2: replace printf with qemu_log (Philippe Mathieu-Daudé)
This patch works together with ATF patch:
https://github.com/muvarov/arm-trusted-firmware/commit/7556d07e87f755c602cd…
Previus discussion for reboot issue was here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg757705.html
Maxim Uvarov (3):
hw: gpio: implement gpio-pwr driver for qemu reset/poweroff
arm-virt: add secure pl061 for reset/power down
arm-virt: combine code for secure and non secure pl061
hw/arm/Kconfig | 1 +
hw/arm/virt.c | 118 +++++++++++++++++++++++++++++++++++-------
hw/gpio/Kconfig | 3 ++
hw/gpio/gpio_pwr.c | 70 +++++++++++++++++++++++++
hw/gpio/meson.build | 1 +
include/hw/arm/virt.h | 2 +
6 files changed, 175 insertions(+), 20 deletions(-)
create mode 100644 hw/gpio/gpio_pwr.c
--
2.17.1
