Hi, I suggest we move the discussion to https://lists.linaro.org/mailman/listinfo/boot-architecture I am sending the subscription link to BKK19 boot sprint attendees.
Cheers FF On Thu, 11 Apr 2019 at 10:31, Francois Ozog <[email protected]> wrote: > > > On Thu, 11 Apr 2019 at 10:23, AKASHI, Takahiro <[email protected]> > wrote: > >> On Thu, 11 Apr 2019 at 16:49, Joakim Bech <[email protected]> wrote: >> > >> > Hi, >> > >> > @Takahiro, thanks for teaching me what is right and wrong :) >> >> No, no. Everything is right, but some are only suitable for a specific >> relationship :) >> >> > @Ilias, @FF, replies inline below. >> > >> > On Thu, 11 Apr 2019 at 09:22, Francois Ozog <[email protected]> >> wrote: >> >> >> >> >> >> >> >> On Thu, 11 Apr 2019 at 08:51, Ilias Apalodimas < >> [email protected]> wrote: >> >>> >> >>> Hi Akashi-san, >> >>> >> >>> > > I'm just drafting a new card for running the Standalone MM >> >>> > > as Trusted Application in OP-TEE. The use case as I understand >> >>> > > it is to call this TA from U-Boot environment (and when Linux is >> >>> > > up and running). >> >>> > >> >>> > I heard the almost same thing from Francois. >> >>> > I don't mind how the service will be implemented in secure world. >> What I'd >> >>> > like to do here is to add an interface for communicating with >> secure world >> >>> > on U-Boot side (normal world). >> >>> Can we try and avoid double and triple Jira epics, while still giving >> credit to >> >>> SIGs/Groups doing the work? >> >>> We already have an initiative up for u-boot relasted issues. >> >>> https://projects.linaro.org/browse/LEDGE-134 >> >>> >> >> >> >> My proposal is that EPICS related to OPTEE are owned by SWG, even if >> they are resourced by LEDGE. >> >> For instance, I can task a LEDGE assignee to do the OPTEE work under >> Joakim guidance and reporting on a SWG EPIC. >> > >> > This is inline with my thoughts. >> > >> >> >> >> LEDGE Initiative would include an EPIC link to the SWG EPIC: LEDGE can >> then track the many tasks done in KWG and SWG. >> >> Actually I proposed the creation of a lead project: dependable boot. >> >> >> >> For the time being, lets create all the Jira cards we think we need to >> address. Lets check each other iniatives to ensure we have identified all >> pieces of work. >> >> https://projects.linaro.org/browse/LEDGE-151 >> >> https://projects.linaro.org/browse/LEDGE-134 >> > >> > As we're speaking I'm drafting the work for a Standalone MM OP-TEE as >> well as the fTPM stuff: >> > https://projects.linaro.org/browse/SWG-372 (I'm going to add more >> details here after having a chat with Ard ... who is travelling to US for >> the moment). >> > https://projects.linaro.org/browse/SWG-373 >> > >> > Note that I'll more and more start creating Initiatives instead of >> Epics, since I believe the consensus after TSC voting is that our current >> Initiatives are too broad containing unrelated features. Having that said, >> beneath the Initiatives I'll split up sub-tasks as Epics. >> >> Let me make clear; I started my UEFI-related tasks almost >> independently from other groups' activities. In this sense, my >> 'initiative' is KWG-339 (I don't care much though). KWG-403 is >> a card where I want to keep my status updated. >> >> >> >> >> >> >>> >> >>> > >> >>> > Yes, I remember that we discussed lots about running Standalone MM >> as >> >>> > OP-TEE application, and what I'm asking is >> >>> > - do you have any chance to use Standalone MM service on SPM, or >> >>> > - do you want to use it solely as OP-TEE application. >> >>> For the moment all LEDGE platforms we know of are based on u-boot. >> >>> The only platform we have that not u-boot based is the SynQuacer box, >> but Ard >> >>> has already finished his StandaloneMM in SPM on that. >> >> >> >> >> >> SPM does not work with ST32MP1 which is a LEDGE 32 bit target platform >> and, AFAIK, will not work with virtualization in trustzone. >> >> So SPD is our way to go. >> > >> > Yes, and IIRC, this is why we need to make Ard's current Standalone MM >> implementation possible to run as an OP-TEE Trusted Application (basically >> SWG-372). It's even useful on Armv8 devices until we have support for >> running multiple SP's. >> >> So even for some sort of prototyping or POC, you won't use Standalone >> MM services >> in the current form and will be willing to wait for the completion of >> SWG-372? >> >> I think we can swap very easily the protocol used between u-boot and the > Standalone MM. You can surely do a first iteration with SPM version as it > exists today and you can just add the u-boot part. > This allows working in parrallel on different aspects of the > implementation. > We will focus on the SPD part. > > I heard from Ard that some assignee has finished porting Standalone MM >> services >> to qemu, and so I will be able to work on it integrating it into my >> current secure boot patch. >> >> > Sounds perfect! > > >> In addition, in my previous e-mail, I think that I raised some topic >> that we should >> discuss, image authentication as well as rolls of secure world and >> non-secure world. >> This will have impacts on my secure boot patch; in some scenario, my >> current work will >> make almost no sense. >> >> That needs proper discussion: > shall we use the boot-arch mail alias as the mailing list so that we reach > a broad community for comments? > shall we setup a weekly call ? (most attendees are europe to asia time > zones I believe) > > >> Thanks, >> -Takahiro Akashi >> >> >> >> >> >>> >> >>> Cheers >> >>> /Ilias >> > >> > >> > Regards, >> > Joakim >> > > > -- > [image: Linaro] > <https://www.linaro.org/assets/content/RGB-Linaro_Standard.png> > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > [email protected] | Skype: ffozog > > -- [image: Linaro] <https://www.linaro.org/assets/content/RGB-Linaro_Standard.png> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
