Cross-posting on the TF-A mailing list too for interested people to attend the kickoff meeting listed below hosted by Linaro.
Thanks
Matteo
-----Original Message-----
From: Linaro-open-discussions <linaro-open-discussions-bounces(a)op-lists.linaro.org> On Behalf Of Ulf Hansson via Linaro-open-discussions
Sent: 10 November 2020 10:21
To: linaro-open-discussions(a)op-lists.linaro.org
Subject: [Linaro-open-discussions] Kickoff: Extend PSCI with OS-initiated mode in TF-A
Hi all,
As previously announced we are hosting a kickoff meeting for the above topic/project.
The meeting has been added to the linaro-open-discussions calendar, according to the below. Feel free to join us on Thursday this week!
Kind regards
Ulf Hansson, Linaro KWG
When:
Thursday Nov 12, 16:00-17:00 CET.
Agenda:
1. Introduction.
2. Update of the current support in Linux.
3. Collaborations.
4. Technical things.
5. Other matters.
To join the Zoom Meeting:
https://linaro-org.zoom.us/j/97261221687
Meeting ID: 972 6122 1687
One tap mobile
+13462487799,,97261221687# US (Houston)
+16465588656,,97261221687# US (New York)
Dial by your location
+1 346 248 7799 US (Houston)
+1 646 558 8656 US (New York)
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
Meeting ID: 972 6122 1687
Find your local number: https://linaro-org.zoom.us/u/acg3UrpmdE
--
Linaro-open-discussions mailing list
https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Homehttps://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions
> >>. What I am worried about is mistakes and
> >>oversights that slip through testing and then cause random or even
> >>attacker-controllable crashes in production
>
> Why would this not be the case even with SCTLR.A bit set? I'm not seeing the relation between the crash and SCTLR.A bit. If there are oversights that slip through testing and an attacker can cause a crash, there is vulnerability/bug.
> If there is something that slipped through, that causes a data abort(perhaps address not mapped in the translation tables), would we turn off the MMU ?
Well, my assumption is that performing an unaligned access cannot be a
vulnerability. If you have examples to the contrary please let me
know, but as far as I am aware letting an unaligned access through
should always work and will always result in the behavior the
programmer intended (other than maybe contrived cases where device
address space is mapped with a non-Device memory type, which is
already very wrong for plenty of other reasons and should never
happen). The only negative consequence is that the access may take
slightly longer than if it were aligned. I do understand the desire to
be able to shake out unaligned accesses during development and
testing, but at least in a production build I think taking that
performance hit would always be preferable to a crash.
I don't think the comparison to a data abort works because obviously
with a data abort the program usually can't just continue and still
assume its internal state is valid.
Hi Julius,
A lot of the rationale for the default initialization is not listed in the documentation and I do think perhaps we can do better as at the end of the day it’s decisions around platform ports and how they are going to be deployed in products that may influence decisions here for changing the defaults.
Your thoughts around attacker control able crashes are a valid one. I don’t think any one setting is all pros with no cons and platform providers need to make decisions but I think the default code with the settings is more likely to flush out alignment bugs and although I don’t have specific examples any bug could play a part in future vulnerability so best to flush them out rather than lie hidden.
It could be said that in the reference implementation a known crash may be better than a more nebulous unknown behaviour that could come with an undetected bug that could later be taken advantage of.
The use a DEBUG flag is an idea but we have all seen debug builds not operating like production builds so the value may be lost here.
It’s why on reviewing our documentation on seeing your post I think we could do better to explain the rationale for the settings in TF-A so platform owners can be better informed and override default settings if they really feel they have the need.
Cheers
Joanna
________________________________
From: Julius Werner
Sent: Monday, November 9, 2020 10:42 PM
To: Joanna Farley
Cc: raghu.ncstate(a)icloud.com; tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] Alignment fault checking in EL3
Hi Joanna,
Thank you for your detailed response. I was mostly wondering if this
was a deliberate choice or just something someone wrote this way once
and nobody ever thought about again. Since it sounds like it is
intentional, I'll try to understand your rationale better.
> Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them.
I'm curious, can you elaborate on that? I can't really think of a
scenario where lack of alignment checking can really make code behave
in an unintentional way. (I don't think Raghu's scenario of accessing
MMIO registers works because those registers should be mapped with a
Device memory type anyway, and that memory type enforces aligned
accesses regardless of the SCTLR.A flag.) If there truly are security
concerns with this I can understand your approach much better.
> Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward.
There are scenarios where unaligned accesses can be intentional, but I
am not too worried about those -- there are ways to work around that,
and if we make it policy that those accesses always need to be written
that way I'm okay with that. What I am worried about is mistakes and
oversights that slip through testing and then cause random or even
attacker-controllable crashes in production. If the main reason you're
enabling this flag is to help with early detection of coding mistakes,
I wonder if the best approach would be to enable it for DEBUG=1 and
disable it for DEBUG=0 (of course, if there are really security issues
associated with it like you mentioned above, that wouldn't make
sense).
Hi Julius,
Talking to the team here its has always been felt it is best practise to forbid unaligned data accesses in Arm's embedded projects. That's the reason TF-A also enforces the build options: -mno-unaligned-access (AArch32) and -mstrict-align (AArch64). In the TF-A documentation [1] SCTLR_EL3.A and other settings are listed in the Architectural Initialisation section.
There is thought to be only a few cases where unaligned access are correct and intentional and most are defects that should be caught early and not in production and as such it is better to detect unaligned data access conditions early in a platform porting, rather than in the field especially if there is no firmware update capability. Alignment faults should be treated as fatal as they should never happen in production when components have been designed as such from the beginning. Maintaining these settings in production is also advised as best practice as it is known any such defects can possibly play a part in allowing an actor to take advantage of the defect as part of a vulnerability and memory related defects in particular can be taken advantage of. So it seems prudent to guard against them.
We can of course provide better rationalisation based on the above in our documentation to provide platforms porting efforts better guidance. It is after all up to partners in their platform ports to make appropriate decisions for their ports where settings could be changed however the upstreamed reference code should follow the settings we have which are felt to be best practices for TF-A.
It is known other projects follow other practices and that is fine if that works for them. Once a project enables unaligned accesses, it's very hard to go back again since it's likely that code that does unaligned accesses will slowly get added to the project. However for TF-A maintaining the current settings is felt to be the best approach when weighing up the costs and benefits.
Saying all this for those few cases where unaligned accesses are correct and intentional we could look to define better ways to handle these and provide that in reference code as an option to try and get the best for robustness and debuggability which seemed a big part of the concern in your post. Team members in Arm have ideas on how that could be provided but it needs broader discussion on the implications for security and performance before taking forward.
Thanks
Joanna
[1] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.h…
On 09/11/2020, 17:47, "TF-A on behalf of Raghu Krishnamurthy via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hi Julius,
I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset.
Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior.
So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks.
>> I am still wondering why we choose to set the SCTLR_EL3.A
I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0.
Thanks
Raghu
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A
Sent: Friday, November 6, 2020 6:38 PM
To: tf-a <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Alignment fault checking in EL3
Hi,
I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers.
Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.)
For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Julius,
I tend to agree with your argument about not using SCTLR.A bit but I think the unexpected crashes or instability is due buggy code and insufficient validation of invariants such as aligned pointers, irrespective of whether SCTRLR.A is set or unset.
Even if we allow unaligned accesses, we could have buggy code that access registers that typically have to be size aligned and we wouldn’t catch those bugs with SCTLR.A. Worse, some hardware implementations have undefined/impdef behavior when there are unaligned access to MMIO registers for ex, in which case, I would rather take an alignment fault at the core than allow triggering of undefined behavior.
So I don’t think stability/reliability and the use of SCTLR.A bit are related. If TF-A's position is that we want to allow only aligned accesses in EL3(for whatever reason, I can only think of efficiency), it is the code's responsibility to enforce this invariants using asserts or explicit checks.
>> I am still wondering why we choose to set the SCTLR_EL3.A
I think this is the relevant question. If there are good security reasons(which I don’t know about), I would say we should keep it. If it is for efficiency, given the way recent ARM64 cores are performing, I wouldn't have a problem with SCTLR.A=0.
Thanks
Raghu
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius Werner via TF-A
Sent: Friday, November 6, 2020 6:38 PM
To: tf-a <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Alignment fault checking in EL3
Hi,
I just debugged a TF-A boot crash that turned out to be caused by an alignment fault in platform code. Someone had defined some static storage space as a uint8_t array, and then accessed it by dereferencing uint16_t pointers.
Of course this is ultimately a bug in the platform code that should be fixed, but I am still wondering why we choose to set the SCTLR_EL3.A (Alignment fault checking) flag in TF-A? In an ideal world, maybe we could say that code which can generate alignment faults should not exist -- but, unfortunately, people make mistakes, and this kind of mistake may linger unnoticed for a long time in the codebase before randomly getting triggered due to subtle shifts in the binary's memory layout. (Worse, in some situations this could get affected by SMC parameters passed in from lower exception levels, so it would only be noticeable and could possibly be intentionally triggered if the lower exception level passes in just the right values.)
For that reason, most other environments I know (e.g. Linux) always keep that flag cleared. There's no harm in that -- as far as I'm aware all aarch64 cores are required to support unaligned accesses to cached memory types, and the worst that would happen is a slight performance penalty for the access. I think that flag is mostly meant as a debugging feature to be able to shake out accidental unaligned accesses from your code? If our goal is to be stable and reliable firmware, shouldn't we disable it to reduce the chance of unexpected crashes?
Hi,
I just debugged a TF-A boot crash that turned out to be caused by an
alignment fault in platform code. Someone had defined some static
storage space as a uint8_t array, and then accessed it by
dereferencing uint16_t pointers.
Of course this is ultimately a bug in the platform code that should be
fixed, but I am still wondering why we choose to set the SCTLR_EL3.A
(Alignment fault checking) flag in TF-A? In an ideal world, maybe we
could say that code which can generate alignment faults should not
exist -- but, unfortunately, people make mistakes, and this kind of
mistake may linger unnoticed for a long time in the codebase before
randomly getting triggered due to subtle shifts in the binary's memory
layout. (Worse, in some situations this could get affected by SMC
parameters passed in from lower exception levels, so it would only be
noticeable and could possibly be intentionally triggered if the lower
exception level passes in just the right values.)
For that reason, most other environments I know (e.g. Linux) always
keep that flag cleared. There's no harm in that -- as far as I'm aware
all aarch64 cores are required to support unaligned accesses to cached
memory types, and the worst that would happen is a slight performance
penalty for the access. I think that flag is mostly meant as a
debugging feature to be able to shake out accidental unaligned
accesses from your code? If our goal is to be stable and reliable
firmware, shouldn't we disable it to reduce the chance of unexpected
crashes?
If we're emulating EL3 then the EL3 guest firmware is responsible for
providing the PSCI ABI, including reboot, core power down, etc.
sbsa-ref machine has an embedded controller to do reboot, poweroff. Machine
virt,secure=on can reuse this code to do reboot inside ATF.
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
---
Hello,
This patch implements reboot for the secure machine inside ATF firmware. I.e. current qemu
patch should be used with [1] ATF patch. It looks like that Embedded Controller qemu
driver (sbsa-ec) can be common and widely used for other emulated machines. While if
there are plans to extend sbsa-ec then we might find some other solution.
So for the long term it looks like machine virt was used as an initial playground for secure
firmware. While the original intent was a runner for kvm guests. Relation between kvm guest
and firmware is not very clear now. If everyone agree it might be good solution to move secure
firmware things from virt machine to bsa-ref and make this machine reference for secure boot,
firmware updates etc.
[1] https://github.com/muvarov/arm-trusted-firmware/commit/6d3339a0081f6f2b45d9…
Best regards,
Maxim.
hw/arm/virt.c | 9 +++++++++
include/hw/arm/virt.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index e465a988d6..6b77912f02 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -152,6 +152,7 @@ static const MemMapEntry base_memmap[] = {
[VIRT_ACPI_GED] = { 0x09080000, ACPI_GED_EVT_SEL_LEN },
[VIRT_NVDIMM_ACPI] = { 0x09090000, NVDIMM_ACPI_IO_LEN},
[VIRT_PVTIME] = { 0x090a0000, 0x00010000 },
+ [VIRT_EC] = { 0x090c0000, 0x00001000 },
[VIRT_MMIO] = { 0x0a000000, 0x00000200 },
/* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */
[VIRT_PLATFORM_BUS] = { 0x0c000000, 0x02000000 },
@@ -1729,6 +1730,13 @@ static void virt_cpu_post_init(VirtMachineState *vms, int max_cpus,
}
}
+static void init_ec_controller(VirtMachineState *vms)
+{
+ vms->ec = qdev_new("sbsa-ec");
+
+ sysbus_mmio_map(SYS_BUS_DEVICE(vms->ec), 0, vms->memmap[VIRT_EC].base);
+}
+
static void machvirt_init(MachineState *machine)
{
VirtMachineState *vms = VIRT_MACHINE(machine);
@@ -1797,6 +1805,7 @@ static void machvirt_init(MachineState *machine)
*/
if (vms->secure && firmware_loaded) {
vms->psci_conduit = QEMU_PSCI_CONDUIT_DISABLED;
+ init_ec_controller(vms);
} else if (vms->virt) {
vms->psci_conduit = QEMU_PSCI_CONDUIT_SMC;
} else {
diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
index aad6d69841..6f2ce4e4ff 100644
--- a/include/hw/arm/virt.h
+++ b/include/hw/arm/virt.h
@@ -85,6 +85,7 @@ enum {
VIRT_ACPI_GED,
VIRT_NVDIMM_ACPI,
VIRT_PVTIME,
+ VIRT_EC,
VIRT_LOWMEMMAP_LAST,
};
@@ -163,6 +164,7 @@ struct VirtMachineState {
DeviceState *gic;
DeviceState *acpi_dev;
Notifier powerdown_notifier;
+ DeviceState *ec;
};
#define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM)
--
2.17.1
Hi All,
The next TF-A Tech Forum is scheduled for Thu 5th November 2020 16:00 – 17:00 (GMT).
Please note UK entered Daylight Saving on 25th October when clocks went back one hour to go to GMT from 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:
* TF-A Tests Framework Overview
* Presented by Varun Wadekar
* Summary
* Trusted Firmware-A Tests (TF-A Tests) is a suite of baremetal tests to exercise the Trusted Firmware-A (TF-A) features from the Normal World.
* 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
Hi All,
Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT.
See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/
Thanks,
Shebu
-----Original Appointment-----
From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>
Sent: Friday, October 23, 2020 12:32 AM
To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman
Subject: Mbed TLS Virtual Workshop
When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London.
Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
You have been invited to the following event.
Mbed TLS Virtual Workshop
When
Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix
Where
Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>)
Calendar
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
Who
•
Don Harbin - creator
•
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
•
mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>
•
psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org>
•
dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com>
more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Hi,
Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop.
The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss
* The future direction of the project and
* Ways to improve community collaboration
Here is the agenda for the workshop.
Topic Time (in GMT)
Welcome 2.00 - 2.10pm
Constant-time code 2.10 – 2.30pm
Processes - how does work get scheduled? 2.30 – 2.50pm
PSA Crypto APIs 2.50 – 3.20pm
PSA Crypto for Silicon Labs Wireless
MCUs - Why, What, Where and When 3.20 – 3.50pm
Break
Roadmap, TLS1.3 Update 4.10 – 4.30pm
Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm
How do I contribute my first review
and be an effective Mbed TLS reviewer 5.00 – 5.30pm
Regards,
Don Harbin
Trusted Firmware Community Manager
==============Zoom details below:====================
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: Mbed TLS Virtual Workshop
Time: Nov 3, 2020 02:00 PM Greenwich Mean Time
Join Zoom Meeting
https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…>
Meeting ID: 953 1520 0315
Passcode: 143755
One tap mobile
+16699009128,,95315200315# US (San Jose)
+12532158782,,95315200315# US (Tacoma)
Dial by your location
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 953 1520 0315
Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…>
Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Invitation from Google Calendar<https://www.google.com/calendar/>
You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> 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://www.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<https://support.google.com/calendar/answer/37135#forwarding>.
Hi,
*For [1] - Would be good if the test infrastructure(the TPM TA) can compile
in AARCH64. I thought I heard on the tf-a call that there already is a
Microsoft FW TPM port for aarch64 already. Please let me know if I
misunderstood.*
You can check the implementation at
https://github.com/microsoft/MSRSec
This compiles for aarch64.
I had a few queries for chips having physical TPM.
Case 1. Should all entities doing the measurement (BL1, BL2) have the TPM
driver to extend the measurements as they are done. This would be the most
secure flow.
Case 2. If BL1 and BL2 don't have the TPM driver as mentioned in Case 1
above, who would be responsible for extending the measurements for secure
world entities.
-- Should there be a TPM driver in Secure EL0/EL1 which does this ?
-- Event log is also passed to the BL33. In case there is no TPM driver at
all in the secure world - is it expected that BL33 should extend the
measurements in PCR ?
Regards,
Ruchika
On Mon, 26 Oct 2020 at 21:03, Stuart Yoder via TF-A <
tf-a(a)lists.trustedfirmware.org> wrote:
> Regarding measuring TB_FW_CONFIG--
>
> BL1 could measure the unmodified TB_FW_CONFIG image as it was loaded from
> flash. It could then update TB_FW_CONFIG with that measurement which
> reflects the image as it was on flash. This could allow detection of
> tampering with flash. I would recommend doing this, as TB_FW_CONFIG is
> critical data.
>
> BL2 could make a measurement of the TB_FW_CONFIG image as it was passed to
> it in memory.
>
> Thanks,
> Stuart
>
>
> On 10/26/20 6:16 AM, Alexei Fedorov wrote:
>
> Hi Javer,
>
> Please see my comments below.
>
> [3] Provide platform hooks in tpm_record_measurement function for a
> platform to actually extend those measurements to a physical TPM right when
> they are measured.
>
> These hooks can be implemented in the next phase #2 of Measured Boot
> implementation.
>
> [4] On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should
> also be measured since they are images being loaded as well. See
> arm_bl1_setup.c where these images are loaded but not measured(unless I’m
> missing something).
>
> FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2.
> BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG.
> It can also pass FW_CONFIG hash in the same DTB, but it is not clear how
> own TB_FW_CONFIG hash can be passed in itself.
>
> Stuart, do you have opinion on that?
>
> Regards.
>
> Alexei
> ------------------------------
> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org>
> <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Javier Almansa
> Sobrino via TF-A <tf-a(a)lists.trustedfirmware.org>
> <tf-a(a)lists.trustedfirmware.org>
> *Sent:* 26 October 2020 10:25
> *To:* raghu.ncstate(a)icloud.com <raghu.ncstate(a)icloud.com>
> <raghu.ncstate(a)icloud.com>
> *Cc:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
> <tf-a(a)lists.trustedfirmware.org>
> *Subject:* Re: [TF-A] Questions raised about Measured Boot + fTPM test
> case
>
> Hi Raghu,
>
> Thank you very much for your comments and for your feedback.
>
> With regards to the (f)TPM service and as discussed during the last TF-A
> Tech Forum call, we will discuss internally the need of a new
> implementation, probably after the next TF-A release, and we will schedule
> the work (in case we decide to go ahead with it) for the upcoming months.
> We will announce any decision we make through the mailing list and/or on
> future TF-A Tech Forum calls .
>
> Regarding to changes to TF-A to include extra functionality/APIs/hooks, I
> guess my colleague Alexei can provide further details about the next
> features planned for Measured Boot, if any.
>
> To finish, I would just like to clarify one of the questions raised on
> your email:
>
> [1] Would be good if the test infrastructure(the TPM TA) can compile in
> AARCH64. I thought I heard on the tf-a call that there already is a
> Microsoft FW TPM port for aarch64 already. Please let me know if I
> misunderstood.
>
>
> - Microsoft has a reference implementation of the TPM 2.0
> specification. That implementation is in the form of an architecture
> agnostic library that implements the specification. Along with the library,
> there are a couple of example applications for different platforms built
> around the former, one of them being the fTPM we used for testing. That
> application was written for AARCH32 and seemed to be outdated (I don't know
> if it was abandoned, actually), so we updated it and added support for
> Measured Boot to it.
>
>
> Best regards,
> Javier
>
> -----Original Message-----
> *From*: raghu.ncstate(a)icloud.com
> *To*: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino(a)arm.com
> <'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino(a)arm.com%3e>>
> *Cc*: tf-a(a)lists.trustedfirmware.org
> *Subject*: RE: [TF-A] Questions raised about Measured Boot + fTPM test
> case
> *Date*: Sun, 25 Oct 2020 14:31:10 -0700
>
> Hi Javier,
>
>
>
> As discussed during the TF-A call, here are some suggestions/feedback that
> can be incorporated when time permits based on priorities, schedule,
> resources etc:
>
> 1. Would be good if the test infrastructure(the TPM TA) can compile in
> AARCH64. I thought I heard on the tf-a call that there already is a
> Microsoft FW TPM port for aarch64 already. Please let me know if I
> misunderstood.
> 2. Would be good if the TPM TA works on FF-A as opposed to proprietary
> OPTEE API’s.
> 3. Provide platform hooks in tpm_record_measurement function for a
> platform to actually extend those measurements to a physical TPM right when
> they are measured. This is a requirement from a security perspective to not
> wait until the tpm TA is loaded to be able to extend the measurements into
> a tpm. I understand this can be done in the platform hook that calls
> tpm_record_measurement but it is convenient place to put tpm related
> platform hooks.
> 4. On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should
> also be measured since they are images being loaded as well. See
> arm_bl1_setup.c where these images are loaded but not measured(unless I’m
> missing something).
>
>
>
> Thanks
>
> Raghu
>
>
>
> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org>
> <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Javier Almansa
> Sobrino via TF-A
> *Sent:* Friday, October 9, 2020 10:51 AM
> *To:* tf-a(a)lists.trustedfirmware.org
> *Subject:* [TF-A] Questions raised about Measured Boot + fTPM test case
>
>
>
> Hello all,
>
>
>
> Following up the question raised yesterday during the TF-A Tech Forum with
> regards to any modification needed on the Linux Kernel to run the test case
> that I was presenting (Measured Boot + fTPM service), I double checked
> today and I ran some tests on system and I can confirm that the test case
> works with the mainline Linux Kernel, with no modification other than
> enabling the driver on the DTB.
>
>
>
> The modules involved on the interaction with the fTPM (for this particular
> example) are:
>
>
>
> * optee.ko: Allows communication between the REE (unsecure world), the
> Trusted OS (secure world) and the tee-supplicant (unsecure world).
>
> * tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a
> char device. This also includes the reference implementation used on the
> test case.
>
>
>
> In order to use the fTPM service, the test case makes use of IBM's TPM 2.0
> TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM.
>
>
>
> I would also like to highlight the following points:
>
>
>
> A) The test case is only meant to test the ability of the Measured Boot
> Driver and a TPM 2.0 compliant device to interact with each other. As such,
> we are not providing an fTPM meant to be used on a production environment.
> Instead, we are using an existing reference implementation to which we
> added support for Measured Boot to fulfil our needs for the test and use it
> as a functional example. The implementation details on how to interact with
> a particular TPM device (either firmware or discrete) can differ from the
> ones used on the test case as those details can be platform dependent. For
> example, we use an OPTEE TA fTPM on this example, but other platforms might
> use a discrete TPM or an fTPM running on a different Trusted OS.
>
>
>
> B) As stated on the presentation, we are undergoing internal review of the
> contributions done for the fTPM service to make it compatible with Measured
> Boot. Once the review is completed and the changes merged into the TPM repo
> mainline, we will update the TF-A documentation with instructions on how to
> download and build all the components to run the tests manually.
>
>
>
> Please, let me know in case you have any more questions.
>
>
>
> Best regards,
>
> Javier
>
>
>
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
