Eugene and I usually attend, and it is Andrew Sloss running it on the ARM side.
Sent from my iPhone > On Dec 6, 2013, at 2:14 PM, "Pant, Alok" <[email protected]> wrote: > > >>. But as suggested Eugene, a discussion can be started in the UEFI Forum > >>working groups. ABST (ARM Binding Sub-Team) might be a good place to get > >>the initial feedbacks. > Hi Olivier, > Thanks. Would you be able to bring this to ABST? Or what do you suggest the > next steps? > > From: Olivier Martin [mailto:[email protected]] > Sent: Friday, December 06, 2013 2:05 PM > To: Pant, Alok; Cohen, Eugene; 'Tim Lewis'; [email protected] > Cc: [email protected] > Subject: RE: ARM UEFI BIOS & Trusted firmware (SMM / Trustzone similitudes) > > I have not necessary got the background and the full picture of the industry > in term of production firmware compare to some of you. But I have tried to > give some answers to your questions. > > # Alok, two directions for Secure Monitor implementation? > The ARM recommendation is everything concerning secure world (EL3, > Secure-EL1, Secure-EL0) should be implemented as part of the Trusted Firmware > project. > ArmPlatformPkg/Sec has been ported to AArch64 as a temporary solution while > waiting for an appropriate Trusted Firmware implementation. There is no plan > to have a Secure Monitor implementation (BL31) in Tianocore project. > And I will not accept any patch that implements such feature in Tianocore. > The reason is I do not think it is good thing to duplicate code between both > projects supported by ARM. And the Trusted Firmware project is a better place > for such features. > > # Alok, some implementation starts the Trusted Firmware (in EL3) that > launches SEC in El1/2 mode > ArmPlatformPkg/Sec should not run in EL2/EL1. As I said earlier, this is only > a temporary solution that should be replaced by the Trusted Firmware project > on most ARMv8 platforms. > The Trusted Firmware should launch UEFI that starts with either > ArmPlatformPkg/PrePeiCore (if the UEFI firmware in XIP ROM) or > ArmPlatformPkg/PrePi (if the UEFI firmware is started from DRAM). > > # Alok, Should secure monitor (bl31) be launched before or during SEC phase? > Secure Monitor (BL31) is one of the first components loaded by the Trusted > Firmware. The Secure Monitor will be available before the UEFI firmware > starts. > > # Alok/Eugene, Extending the PI SMM specification (Volume 4) for Trustzone > I had a look at the SMM PI spec. I can see a lot of similitude to the UEFI > spec (an architecture and implementation agnostic interface). > I can also see some similitude between SMM and Trustzone technology (based on > the ARM Secure Extension). And I am sure some SMM drivers will be ported to > ARM Secure components (eg: authentification variable for secure boot). > > One notable difference between SMM and ‘Trustzone’ is the initialization. SMM > seems to be initialized during the DXE phase while the ARM Secure/Trusted > environment is initialized prior to start the Non Secure/Non Trusted > environment (including UEFI, u-boot bootloaders). And I do not see this > initialization phase to be changed for the reason that the secure environment > (Trusted Firmware, Trusted OS, SiP/ODM/OEM secure components) will setup the > appropriate hardware privileges and initialize their environment prior to > switch to the Non-Secure environment. > > The concept of ‘extending the PI SMM spec to Trustzone’ or 'some form of SMM > foundation glue code' is interesting. But it might be difficult to implement > in the current situation (most of the solutions seem to be highly integrated > without much interoperability). The level of standardization of the > Secure/Trusted environment has not reached the API yet. > Obviously, to create a standard an initiative has to be started. I am > probably not the best person (due to my limited knowledge of SMM and their > real use cases) to start this initiative. But as suggested Eugene, a > discussion can be started in the UEFI Forum working groups. ABST (ARM Binding > Sub-Team) might be a good place to get the initial feedbacks. > > # Tim, What happens when the secure OS is performing a secure task, but the > other OS asks for a shutdown? > As you know PSCI (Power State Coordination Interface) is recommended by ARM > for OS Power Management (OSPM). In this case, the Secure world is aware of > the shutdown. > But the PSCI spec says 'a Trusted OS must not rely on the use of any > notification, and must be resistant to any sudden loss of context'. > Trusted OS vendors are expected to provide a Rich OS driver to invoke their > services. There are probably ways to signal a Rich OS shutdown to the Trusted > OS using this driver. > > Thanks, > Olivier > > > From: Pant, Alok [mailto:[email protected]] > Sent: 05 December 2013 18:08 > To: [email protected]; Olivier Martin > Subject: RE: ARM UEFI BIOS & Trusted firmware > > Hi Tim & Eugene, > Thanks for the response. I agree current SMM foundation code gas some IA > specific and there are various gotchas around SMM entry/exit (sync core , > save restore etc, base protocol), however most of SMM foundation is generic > and it provides a nice framework of independent driver and interaction via > protocol and use common services; granted the DXE SMMipl role of launching > and building initial SMM environment does not mesh well on ARM. In parallel > there is separate work on ARM trusted firmware and seems there is no common > ground between two. I am very must interested to hear how others are > attempting to address such feature porting issue and the direction from > industry toward runtime EL3 support (single monolithic TF binary+some > proprietary form of RTOS “vs.” attempt to integrate UEFI SMM with trusted fw > core). I am sure I am not the first one stumbling on this question and > seeking how others attempted to solve the above and if this a broader issue > that need to be further discussed in this forum. > > Thanks > -Alok > > > > From: Tim Lewis [mailto:[email protected]] > Sent: Thursday, December 05, 2013 11:39 AM > To: [email protected]; [email protected] > Subject: Re: [edk2] ARM UEFI BIOS & Trusted firmware > > Eugene – > > One of the issues for the SMM specification and TZ is the single-threaded > nature. While most of ARM’s TrustZone infrastructure can be mapped easily to > SMM, the possibility of having cores in TZ and out of TZ simultaneously, or > more than one core in TZ at the same time raises some interesting issues > (resource contention, etc.) > > Tim > > From: Cohen, Eugene [mailto:[email protected]] > Sent: Thursday, December 05, 2013 9:29 AM > To: [email protected]; [email protected] > Subject: Re: [edk2] ARM UEFI BIOS & Trusted firmware > > Alok, > > I agree -- there is value in the modular nature of the PI component approach > extending to the ARM trusted firmware environment. > > For SMM this is supported in the PI spec’s SMM core interface specification > and in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE > and PEI, the SMM core, at least in name, is IA-specific as it refers to SMM, > SMIs, SMRAM, etc. When you look past the names though you can see that the > functions it is providing is really architecture independent -- IO protocols, > secure memory allocation, protocol management, and handler registration. > Given the current IA-specific naming, it would be difficult to recommend that > ARM should simply adopt the “SMM” core architecture for the > TZ/EL3/SecureMonitor implementation. > > Perhaps this should be raised in the PI working group, specifically “is the > SMM core interface spec really an IA-specific concept or something that > should become architecture agnostic?” > > Eugene > > From: Pant, Alok [mailto:[email protected]] > Sent: Thursday, December 05, 2013 8:42 AM > To: [email protected]; [email protected] > Subject: [edk2] ARM UEFI BIOS & Trusted firmware > > Changing topic.. > > Hi Oliver, Thanks. I also I have few separate questions wrt to Trusted > firmware & UEFI ARM code and hope you/others can help answer > > · It seems there are two direction for SecureMonitor implementation. > In one implementation the SEC code (ArmPlatformPkg\Sec\Sec.c) install the > secure monitor ( when SEC start in El3) ; In other implementation the Trusted > firmware start first install secure monitor (bl31) and launch SEC in El1/2 > mode. My question is what is the preferred direction when both are possible? > Should secure monitor (bl31) be launched before or during SEC phase? > · Historically in x86 implementation the SMM mode hosts various > runtime platform BIOS driver for feature such as authentication variable (for > secure boot), platform runtime handing handling etc. EDKII has a good > framework for SMM kernel and loading various independent SMM driver and > interaction among those driver via protocol etc. In ARM based UEFI/Trusted > firmware implementation what may be preferred way to deal with such need. > Should all those UEFI SMM driver be ported to Trusted firmware which "today" > is in primitive framework compare to SMM EDKII foundation code, or some form > of SMM foundation can gel with trusted firmware design to allow independent > platform el3 code be developed at independent driver. Curious how others have > attempted to solve this problem and if there can be standard way for all of > us to adopt here. Before creating yet another method I was hoping to hear > from experts on any common ground for such feature implementation > > Thanks again for all your help and comments > -Alok > > -----Original Message----- > From: Olivier Martin [mailto:[email protected]] > Sent: Wednesday, December 04, 2013 7:40 AM > To: [email protected]; [email protected] > Subject: Re: [edk2] SEC code support big.LITTLE tech? > > Hi Tiger, > > The ARM recommendation to manage secondary CPUs (the primary CPU is the CPU > that runs UEFI and starts your OS kernel) is to use PSCI (Power State > Coordination Interface - > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0022b/index.h > tml). > PSCI uses SMCs (Secure Memory Calls) to bring up secondary CPUs (CPU_UP / > CPU_DOWN). This code runs in Secure World while UEFI runs in Non-Secure World. > > For the story... I started to implement PSCI support in Tianocore source code > (in ArmPlatformPkg/Sec). But the EDK2 framework (PCD/Library/INF/FDF > etc) had made the code quite hard to maintain. > So, I wrote a new secure firmware framework project to handle this support. > This firmware is not Open Source (available in binary format for TC2 only). > A new project has been started by ARM Ltd last month. It is an Open Source > implementation of the Trusted/Secure Firmware: > https://github.com/ARM-software/arm-trusted-firmware > Unfortunately at this stage, 32bit is not supported (only AArch64 is > supported). And as far as I know there is no plan to add 32bit support by ARM > Ltd in the short term. > > The current ArmPlatformPkg/Sec has support to hold the secondary cores in > WFI. But it does not support PSCI. The current support might be sufficient > enough for you at this stage. > > Thanks, > Olivier > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: 04 December 2013 01:51 > > To: [email protected] > > Cc: Olivier Martin > > Subject: [edk2] SEC code support big.LITTLE tech? > > > > Hi, Oliver: > > Does current ArmPlatformPackage's sec code support big.LITTLE tech? > > Such as : > > An ARM SOC --- with 4 Cores Cortex-A15, 4 Cores Cortex-A7 > > > > So, if sec code support big.LITTLE tech, how does it let one core as > > boot strap cpu, others go into wfe(or other sleeping state)? > > > > Best wishes, > > > > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel _______________________________________________ boot-architecture mailing list [email protected] http://lists.linaro.org/mailman/listinfo/boot-architecture
