Just FYI, the ECR for RISC-V would be released in UEFI spec v2.8C in Jan 2021. The draft one is now released in USWG website.
Abner > -----Original Message----- > From: Chang, Abner (HPS SW/FW Technologist) > Sent: Monday, November 23, 2020 12:11 AM > To: Atish Patra <[email protected]> > Cc: Heinrich Schuchardt <[email protected]>; Ard Biesheuvel > <[email protected]>; Atish Patra <[email protected]>; boot- > [email protected]; Grant Likely <[email protected]>; Rick Chen > <[email protected]> > Subject: RE: EBBR: RISC-V handoff to OS > > The public release date is unsure yet. Some ECRs are still under discussion > for > catching up with UEFI next release. > Will let you know once I know it. > > Abner > > > -----Original Message----- > > From: Atish Patra [mailto:[email protected]] > > Sent: Sunday, November 22, 2020 4:27 PM > > To: Chang, Abner (HPS SW/FW Technologist) <[email protected]> > > Cc: Heinrich Schuchardt <[email protected]>; Ard Biesheuvel > > <[email protected]>; Atish Patra <[email protected]>; boot- > > [email protected]; Grant Likely <[email protected]>; > > Rick Chen <[email protected]> > > Subject: Re: EBBR: RISC-V handoff to OS > > > > On Fri, Nov 20, 2020 at 10:48 PM Chang, Abner (HPS SW/FW Technologist) > > <[email protected]> wrote: > > > > > > Hi Heinrich, > > > This change will be published in UEFI spec 2.8 C and 2.9, FYI. > > > > > > > That's awesome. Thanks for working on this. What is the public release > > date for 2.8 C/2.9 ? > > > > > Abner > > > > > > > -----Original Message----- > > > > From: Chang, Abner (HPS SW/FW Technologist) > > > > Sent: Saturday, October 3, 2020 11:24 AM > > > > To: Heinrich Schuchardt <[email protected]>; Ard Biesheuvel > > > > <[email protected]> > > > > Cc: Atish Patra <[email protected]>; > > > > [email protected]; > > > > Grant Likely <[email protected]>; Rick Chen > > > > <[email protected]>; Atish Patra <[email protected]> > > > > Subject: RE: EBBR: RISC-V handoff to OS > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Heinrich Schuchardt [mailto:[email protected]] > > > > > Sent: Friday, September 25, 2020 10:49 PM > > > > > To: Chang, Abner (HPS SW/FW Technologist) > <[email protected]>; > > > > Ard > > > > > Biesheuvel <[email protected]> > > > > > Cc: Atish Patra <[email protected]>; > > > > > [email protected]; > > > > > Grant Likely <[email protected]>; Rick Chen > > > > > <[email protected]>; Atish Patra <[email protected]> > > > > > Subject: Re: EBBR: RISC-V handoff to OS > > > > > > > > > > On 25.09.20 16:42, Chang, Abner (HPS SW/FW Technologist) wrote: > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Heinrich Schuchardt [mailto:[email protected]] > > > > > >> Sent: Friday, September 25, 2020 6:26 PM > > > > > >> To: Chang, Abner (HPS SW/FW Technologist) > > > > > >> <[email protected]>; > > > > > Ard > > > > > >> Biesheuvel <[email protected]> > > > > > >> Cc: Atish Patra <[email protected]>; > > > > > >> [email protected]; > > > > > >> Grant Likely <[email protected]>; Rick Chen > > > > > >> <[email protected]>; Atish Patra <[email protected]> > > > > > >> Subject: Re: EBBR: RISC-V handoff to OS > > > > > >> > > > > > >> On 9/25/20 8:06 AM, Chang, Abner (HPS SW/FW Technologist) > wrote: > > > > > >>> > > > > > >>> > > > > > >>>> -----Original Message----- > > > > > >>>> From: Heinrich Schuchardt [mailto:[email protected]] > > > > > >>>> Sent: Thursday, September 24, 2020 8:43 PM > > > > > >>>> To: Ard Biesheuvel <[email protected]> > > > > > >>>> Cc: Chang, Abner (HPS SW/FW Technologist) > > > > <[email protected]>; > > > > > >>>> [email protected]; Atish Patra > > > > > >>>> <[email protected]>; Rick Chen <[email protected]>; > > > > > >>>> Atish Patra <[email protected]>; Grant Likely > > > > > >>>> <[email protected]> > > > > > >>>> Subject: Re: EBBR: RISC-V handoff to OS > > > > > >>>> > > > > > >>>> On 24.09.20 14:05, Ard Biesheuvel wrote: > > > > > >>>>> On Thu, 24 Sep 2020 at 08:07, Heinrich Schuchardt > > > > > >>>>> <[email protected]> > > > > > >>>> wrote: > > > > > >>>>>> > > > > > >>>>>> On 9/24/20 5:35 AM, Chang, Abner (HPS SW/FW Technologist) > > > > wrote: > > > > > >>>>>>> Ok Heinrich, thanks for the clarification. I also read > > > > > >>>>>>> through this thread > > > > > >>>> again and understand the intention you would like to have > > > > > >>>> some sentences in the UEFI spec. > > > > > >>>>>>> > > > > > >>>>>>> I realize that we are trying to put sentences in the > > > > > >>>>>>> RISC-V calling > > > > > >>>> convention in UEFI spec to support the specific UEFI > > > > > >>>> firmware implementation of using gp/tp. > > > > > >>>>>>> Uboot UEFI firmware uses tp in HART to record the HART > > > > > >>>>>>> ID and uses gp > > > > > >>>> in the boot-HART to maintain the global data structure of uboot. > > > > > >>>>>> > > > > > >>>>>> tp is only used to store information on the secondary > > > > > >>>>>> harts which does not enter the UEFI payload. So for > > > > > >>>>>> U-Boot the only problematic register is gp. > > > > > >>> If you are using opensbi solution, you should consider to > > > > > >>> use firmware > > > > > >> context mechanism because that is designed for any firmware > > > > > >> solutions to maintain its own data structure for any purposes. > > > > > >> > > > > > >> I will have a look at it. > > > > > > If you would like to know how do we define and initial the > > > > > > firmware > > > > > context, then you can check https://github.com/tianocore/edk2- > > > > > platforms/blob/master/Platform/RISC- > > > > > V/PlatformPkg/Universal/Sec/SecMain.c and > > > > > https://github.com/tianocore/edk2-platforms/blob/master/Silicon/ > > > > > RI > > > > > SC- V/ProcessorPkg/Include/IndustryStandard/RiscVOpensbi.h. > > > > > > Thus the data structure you put in gp could be in firmware > > > > > > context, also > > > > > means that we don’t need that much constraints mentioned in UEFI > > spec. > > > > > > We can still submit that paragraph to USWG, but it would be > > > > > > hard to > > > > > remove it from UEFI spec if once day we don’t need it for the > > > > > backward compatibility. > > > > > > > > > > > >> Thanks for the link below. > > > > > > Below link is for the edk2 opensbi firmware extensions. > > > > > > > > > > > >> > > > > > >>> > > > > > >>>>>> > > > > > >>>>> > > > > > >>>>> Secondary CPUs could be used to invoke runtime services, > > though. > > > > > >>>>> > > > > > >>>>>>> The reason I can think of the reason to use tp/gp is > > > > > >>>>>>> because S-Mode > > > > > >>>> UEFI firmware (or S-mode payload?) is not able to get > > > > > >>>> mhartid, so uboot stores HART ID in tp. Because there is > > > > > >>>> nowhere to maintain the global data structure for uboot and > > > > > >>>> the mscratch is occupied by opensbi, thus uboot uses gp to > > > > > >>>> maintain the pointer to global > > > > context. > > > > > >>>>>>> Because both tp and gp are non-privileged registers so > > > > > >>>>>>> uboot (or > > > > > >>>>>>> payload?) can get the information from those registers > > > > > >>>>>>> easily, right? (But is this a security hole that any > > > > > >>>>>>> software can hack tp/gp? However, this is the different > > > > > >>>>>>> topic, just ignore this) > > > > > >>>>>> > > > > > >>>>>> As said U-Boot restores value of gp when entered from > > > > > >>>>>> UEFI via the > > > > > >> API. > > > > > >>>>>> > > > > > >>>>>> We should do the same when serving interrupts and > > exceptions. > > > > > >>>>>> > > > > > >>>>> > > > > > >>>>> When? > > > > > >>>>> > > > > > >>>>> We should carefully consider the difference between > > > > > >>>>> before-EBS and after-EBS here: > > > > > >>>>> > > > > > >>>>> Before EBS: > > > > > >>>>> Interrupt/exception handlers are owned by the UEFI > > > > > >>>>> firmware (Uboot or EDK2). The OS or any other EFI payload > > > > > >>>>> must not interfere with this, and only use function call > > > > > >>>>> interfaces to interact > > > > with the system. > > > > > >>>> > > > > > >>>> There is a gap in U-Boot for interrupts/exceptions before > > > > > >>>> ExitBootServices() that I will have to close. > > > > > >>>> > > > > > >>>> Best regards > > > > > >>>> > > > > > >>>> Heinrich > > > > > >>>> > > > > > >>>>> > > > > > >>>>> After EBS: > > > > > >>>>> Interrupt/exception handlers are owned by the OS. The UEFI > > > > > >>>>> firmware can be entered on any CPU with interrupts enabled > > > > > >>>>> or disabled, and the UEFI firmware should not interfere > > > > > >>>>> with interrupt handling or exception vectors etc. > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>> Concerning security we have to remember that an UEFI > > > > > >>>>>> payload has the same powers as the firmware itself. When > > > > > >>>>>> it comes to hacking you have lost once you execute a > > > > > >>>>>> hostile payload. What we can try to guard against to some > > > > > >>>>>> degree are non-compliant > > > > payloads. > > > > > >>>>>> > > > > > >>>>> > > > > > >>>>> Agreed. Everything runs at the same permission level, so > > > > > >>>>> any software running under UEFI has the same powers as the > > > > > >>>>> UEFI firmware > > > > > >> itself. > > > > > >>>>> > > > > > >>>>>>> Did we spec out above behavior in uboot RISC-V spec or > > > > > >>>>>>> the > > > > > >>>> implementation design guide at somewhere? I am not quite > > > > > >>>> familiar with uboot area though. > > > > > >>>>>> > > > > > >>>>>> The patch series > > > > > >>>>>> > > > > > >>>>>> doc: global data pointer > > > > > >>>>>> INVALID URI REMOVED > > > > > >>>> 3A__patchwork.ozlabs > > > > > >>>>>> .org_project_uboot_list_-3Fseries- > > > > > >>>> 3D202971&d=DwIFaQ&c=C5b8zRQO1miGmBe > > > > > >>>>>> > > > > > >>>> > > > > > >> > > > > > > > > > > > > VZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=QMu > > > > > >>>> q0JhboDWbE > > > > > >>>>>> qbx6d4dZeXY2Pk0-PICJzRJKNT4wRY&s=UjTczoF1vjt5- > > > > > >>>> uUzkvB6QFgGIsCUpuTMrSjX > > > > > >>>>>> Zh8LbGA&e= > > > > > >>>>>> > > > > > >>>>>> starts closing the documentation gap in U-Boot. > > > > > >>>>>> > > > > > >>>>>>> > > > > > >>>>>>> Another problem comes to my mind is even though we save > > > > gp/tp > > > > > >> upon > > > > > >>>> the entry of ExitBootService (or other UEFI APIs) and > > > > > >>>> replaced with the uboot ones, what if the > > > > > >>>> interrupt/exception happens and delegated to the payload > > > > > >>>> event handler during ExitBootService (or other UEFI APIs)? > > > > > >>>> The ownership is messed up > > at this point, right? > > > > > >>>>>> > > > > > >>>>>> UEFI spec 2.8B chapter 2.3.7 "RISC-V Platforms" has: > > > > > >>>>>> > > > > > >>>>>> The processor is in the following execution mode during > > > > > >>>>>> boot > > > > service: > > > > > >>>>>> The machine mode interrupt is enabled during boot service > > > > > >>>>>> in > > UEFI. > > > > > >>>>>> Two kinds of interrupts are enabled, one is for timer > > > > > >>>>>> interrupt and another is software interrupt > > > > > >>>>>> > > > > > >>>>>> All other architectures except RISC-V describe the usage > > > > > >>>>>> of runtime services by the OS with the following sentences: > > > > > >>>>>> > > > > > >>>>>> For an operating system to use any runtime services, it must: > > > > > >>>>>> Call the runtime service functions, with the following > conditions: > > > > > >>>>>> Interrupts may be disabled or enabled at the discretion > > > > > >>>>>> of the > > > > caller. > > > > > >>>>>> > > > > > >>>>>> So the rule of thumb is: Until ExitBootServices() returns > > > > > >>>>>> the firmware serves interrupts and exceptions. After > > > > > >>>>>> ExitBootServices() returns it is the operating system. > > > > > >>>>>> > > > > > >>>>>> In the AAarch64 chapter I found: > > > > > >>>>>> > > > > > >>>>>> "An alternate execution environment can restore the > > > > > >>>>>> firmware environment before each UEFI call. However the > > > > > >>>>>> possibility of preemption may require the alternate > > > > > >>>>>> execution-enabled application to disable interrupts while > > > > > >>>>>> the alternate execution environment is active. It's legal > > > > > >>>>>> for the alternate execution environment enabled > > > > > >>>>>> application to enable interrupts if the application > > > > > >>>>>> catches the interrupt and restores the EFI firmware > > > > > >>>>>> environment prior to calling the > > > > > >>>> UEFI interrupt ISR." > > > > > >>>>>> > > > > > >>>>>> I am not aware of an implementation of such an "alternate > > > > > >>>>>> execution environment". But an alternative execution > > > > > >>>>>> environment serving interrupts while calling the UEFI API > > > > > >>>>>> and relying on values that it has put into gp would not > > > > > >>>>>> work on current > > > > U-Boot. > > > > > >>>>>> > > > > > >>>>>>> > > > > > >>>>>>> In edk2 RISC-V port, we use "firmware_context" in > > > > > >>>>>>> sbi_platforms which > > > > > >>>> provided opensbi through mscratch to maintain the firmware > > > > > >>>> specific > > > > > >> context. > > > > > >>>> With this, firmware can maintain its own data structure > > > > > >>>> without bothering any other industrial specs. Because > > > > > >>>> S-Mode firmware can't access to mhartid and the > > > > > >>>> sbi-scratch which is stored in mscratch, so we have > > > > > >>>> Edk2OpensbiLib that registers the firmware specific sbi > > > > > >>>> extension functions using "Firmware Code Base Specific SBI > > > > > >>>> Extension Space, Extension Ids 0x0A000000 through > > > > 0x0AFFFFFF" > > > > > >>>> defined in sbi spec. That is a separate spec for RISC-V > > > > > >>>> edk2 firmware sbi extension > > > > > >> function (This reminds me I forget to document it). > > > > > >>>> Then edk2 can get the necessary information using edk2 > > > > > >>>> extension sbi > > > > > call. > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>>> Thank you for pointing me at Edk2OpensbiLib. Where can I > > > > > >>>>>> find the > > > > > >> code? > > > > > >>> Here it is, > > > > > >>> https://github.com/tianocore/edk2-platforms/tree/master/Sili > > > > > >>> co n/RI SC -V /ProcessorPkg/Library/RiscVEdk2SbiLib > > > > > >>> > > > > > >>>>>> > > > > > >>>>>> I will have to keep in mind that U-Boot can be used both > > > > > >>>>>> with and without an SEE. > > > > > >>>>>> > > > > > >>>>>>> You would agree with that we don’t have to mention the > > > > > >>>>>>> gp/tp usage in > > > > > >>>> the calling convention just because of the uboot > implementation. > > > > > >>>> And we don’t have mention any connection/relationship > > > > > >>>> between gp/tp usage and the specific UEFI firmware > > > > > >>>> implementation. The sentence must be also generic to other > > > > > >>>> UEFI firmware solutions such as edk2 which doesn't care > > > > > >>>> about > > destroying gp/tp (so far). > > > > > >>>>>> > > > > > >>>>>> I fully agree that specifications precede implementations. > > > > > >>>>>> > > > > > >>>>>>> > > > > > >>>>>>> In the RISC-V assembly programmer's handbook in RISC-V > > > > > >>>>>>> spec, gp/tp > > > > > >>>> are not given either the caller or callee to save the > > > > > >>>> value, so we can spec out something in UEFI spec based on > > > > > >>>> this calling > > > > convention. > > > > > >>>>>> > > > > > >>>>>> Jessica Clarke pointed me to the "RISC-V ELF psABI > > specification" > > > > > >>>>>> (https://github.com/riscv/riscv-elf-psabi-doc/blob/master > > > > > >>>>>> /r > > > > > >>>>>> iscv > > > > > >>>>>> -e > > > > > >>>>>> lf > > > > > >>>>>> .m > > > > > >>>>>> d) which defines the usage of tp and gp in the RISC-V world: > > > > > >>>>>> > > > > > >>>>>> "In the standard ABI, procedures should not modify the > > > > > >>>>>> integer registers tp and gp, because signal handlers may > > > > > >>>>>> rely upon their > > > > > >> values." > > > > > >>>>>> > > > > > >>>>>> So here the idea is that whoever serves interrupts and > > > > > >>>>>> exceptions is the owner of gp and tp. > > > > > >>>>>> > > > > > >>>>>> After ExitBootServices() signals are served by the > > > > > >>>>>> operating > > system. > > > > > >>>>>> It takes hold of the values of tp and gp. See these lines > > > > > >>>>>> of the Linux > > > > > >> kernel: > > > > > >>>>>> > > > > > >>>>>> arch/riscv/kernel/entry.S:97: > > > > > >>>>>> la gp, __global_pointer$ > > > > > >>>>>> > > > > > >>>>>> arch/riscv/kernel/head.S:253: > > > > > >>>>>> la tp, init_task > > > > > >>>>>> > > > > > >>>>>> Every time Linux enters kernel mode it again sets its own > > > > > >>>>>> values of gp and tp. This addresses the security problem > > > > > >>>>>> that you mentioned > > > > > >> above. > > > > > >>>>>> > > > > > >>>>>>> > > > > > >>>>>>> The sentence which I consider reasonable is , "In view > > > > > >>>>>>> of gp and tp registers are not assigned the specific > > > > > >>>>>>> owner to save and restore their > > > > > >>>> values in the calling convention (refer to "RISC-V assembly > > > > > >>>> programmer's handbook" section in RISC-V Unprivileged ISA > > > > > >>>> specification), UEFI firmware must not having assumption of > > > > > >>>> owning the write access to these register at any > > > > > >>>> circumstances such as in EFI Boot service, EFI Runtime > > > > > >>>> service, EFI Management Mode service and in any UEFI > > > > > >>>> firmware interfaces which may invoked by the external > > > > > >>>> firmware payload, or altering the values of gp/tp > > > > > >>>> registers results in the interference in the asynchronous > > > > > >>>> callback to the external firmware payload . Whether and how > > > > > >>>> to preserve gp and tp during UEFI firmware environment is > > > > > >>>> UEFI firmware implementation-specific. RISC- V platform > > > > > >>>> firmware integrator should refer to the corresponding > > > > > >>>> design > > > > > >> specification of the particular UEFI firmware solution." > > > > > >> > > > > > >> Thanks for this description which looks fine to me. > > > > > > I think you are fine with the below description but not the > > > > > > above one, > > > > right? > > > > > >> Maybe a native English speaker can clean it up a bit. > > > > > > > > > > > >> > > > > > >> Best regards > > > > > >> > > > > > >> Heinrich > > > > > >> > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>>> We should start with a reference of the "RISC-V ELF psABI > > > > > >> specification" > > > > > >>>>>> to explain the usage of gp and tp. > > > > > >>>>>> > > > > > >>>>>> It seems to be necessary and sufficient for the firmware > > > > > >>>>>> to > > follow: > > > > > >>>>>> > > > > > >>>>>> * Don't trust the values of tp and gp when entered > > > > > >>>>>> from the payloads world. > > > > > >>>>>> * If you need to change them, restore the values before > > returning. > > > > > >>>>>> * Never touch tp and gp after ExitBootServices(). > > > > > >>>>>> > > > > > >>>>>> The same should be observed by an interrupt or exception > > > > > >>>>>> handler provided by an "alternative execution environment". > > > > > >>>>>> > > > > > >>>>>> Best regards > > > > > >>> How about this, > > > > > >>> > > > > > >>> In view of the statement "In the standard ABI, procedures > > > > > >>> should not > > > > > >> modify the integer registers tp and gp, because signal > > > > > >> handlers may rely upon their values." mentioned in RISC-V EFL > > > > > >> psABI Specification (See “Link to UEFI Specification-Related > > > > > >> Document” on https://uefi.org/uefi under the heading “RISC-V > > > > > >> EFL psABI > > > > > >> Specification”) and the RISC-V calling convention that gp and > > > > > >> tp registers are not assigned the specific owner to save and > > > > > >> restore their > > > > > values (refer to "RISC-V assembly programmer's handbook" > > > > > >> section in RISC-V Unprivileged ISA specification). UEFI > > > > > >> firmware must neither trusting the values of tp and gp nor > > > > > >> having assumption of owning the write access to these > > > > > >> register at any circumstances (Such as in EFI Boot service, > > > > > >> EFI Runtime service, EFI Management Mode service and any UEFI > > > > > >> firmware interfaces which may invoked by the EFI drivers, OS > > > > > >> or external firmware payload). Preserve the values in gp or > > > > > >> tp register if UEFI firmware needs to change them and > > > > > never touches them after ExitBootServices(). > > > > > >> Whether and how to preserve gp and tp during UEFI firmware > > > > > >> environment is UEFI firmware implementation-specific. > > > > > > > > > > > > > > > Sorry my review commet got misplaced. Yes the text above this > > > > > line is > > fine. > > > > > > > > > > Best regards > > > > > > > > > > Heinrich > > > > The revised ECR was uploaded to USWG last week, however the > > > > meeting was canceled. I will update the status to this loop if we > > > > have progresses on this. > > > > Thanks > > > > > > > > > > > > > > > >>> > > > > > >>> > > > > > >>>>>> > > > > > >>>>>> Heinrich > > > > > >>>>>> > > > > > >>>>>>> I believe this initial sentence still needs some > > > > > >>>>>>> revises, please just modify > > > > > >>>> above paragraph if you don't like it. We can keep > > > > > >>>> discussing this based on above paragraph. > > > > > >>>>>>> > > > > > >>>>>>> Thanks > > > > > >>>>>>> > > > > > >>>>>>>> -----Original Message----- > > > > > >>>>>>>> From: Heinrich Schuchardt [mailto:[email protected]] > > > > > >>>>>>>> Sent: Thursday, September 24, 2020 2:20 AM > > > > > >>>>>>>> To: Chang, Abner (HPS SW/FW Technologist) > > > > > >> <[email protected]>; > > > > > >>>>>>>> [email protected]; Atish Patra > > > > > >>>>>>>> <[email protected]> > > > > > >>>>>>>> Cc: Rick Chen <[email protected]>; Atish Patra > > > > > >>>>>>>> <[email protected]>; Grant Likely > > > > > >>>>>>>> <[email protected]>; > > > > > Ard > > > > > >>>>>>>> Biesheuvel <[email protected]> > > > > > >>>>>>>> Subject: Re: EBBR: RISC-V handoff to OS > > > > > >>>>>>>> > > > > > >>>>>>>> On 9/23/20 5:01 PM, Chang, Abner (HPS SW/FW > > Technologist) > > > > > wrote: > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>>> -----Original Message----- > > > > > >>>>>>>>>> From: Chang, Abner (HPS SW/FW Technologist) > > > > > >>>>>>>>>> Sent: Wednesday, September 23, 2020 10:55 PM > > > > > >>>>>>>>>> To: 'Heinrich Schuchardt' <[email protected]>; boot- > > > > > >>>>>>>>>> [email protected]; Atish Patra > > > > > >>>>>>>>>> <[email protected]> > > > > > >>>>>>>>>> Cc: Rick Chen <[email protected]>; Atish Patra > > > > > >>>>>>>>>> <[email protected]>; Grant Likely > > > > <[email protected]>; > > > > > >> Ard > > > > > >>>>>>>>>> Biesheuvel <[email protected]> > > > > > >>>>>>>>>> Subject: RE: EBBR: RISC-V handoff to OS > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>>> -----Original Message----- > > > > > >>>>>>>>>>> From: Heinrich Schuchardt > > > > > >>>>>>>>>>> [mailto:[email protected]] > > > > > >>>>>>>>>>> Sent: Wednesday, September 23, 2020 3:42 PM > > > > > >>>>>>>>>>> To: Chang, Abner (HPS SW/FW Technologist) > > > > > >>>> <[email protected]>; > > > > > >>>>>>>>>>> [email protected]; Atish Patra > > > > > >>>>>>>>>>> <[email protected]> > > > > > >>>>>>>>>>> Cc: Rick Chen <[email protected]>; Atish Patra > > > > > >>>>>>>>>>> <[email protected]>; Grant Likely > > > > > <[email protected]>; > > > > > >>>>>>>>>>> Ard Biesheuvel <[email protected]> > > > > > >>>>>>>>>>> Subject: Re: EBBR: RISC-V handoff to OS > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> On 23.09.20 08:51, Chang, Abner (HPS SW/FW > > > > > >>>>>>>>>>> Technologist) > > > > > >> wrote: > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>>> -----Original Message----- > > > > > >>>>>>>>>>>>> From: Heinrich Schuchardt > > > > > >>>>>>>>>>>>> [mailto:[email protected]] > > > > > >>>>>>>>>>>>> Sent: Wednesday, September 23, 2020 2:18 PM > > > > > >>>>>>>>>>>>> To: Chang, Abner (HPS SW/FW Technologist) > > > > > >>>>>>>> <[email protected]>; > > > > > >>>>>>>>>>>>> [email protected]; Atish Patra > > > > > >>>>>>>>>>>>> <[email protected]> > > > > > >>>>>>>>>>>>> Cc: Rick Chen <[email protected]>; Atish Patra > > > > > >>>>>>>>>>>>> <[email protected]>; Grant Likely > > > > > >> <[email protected]>; > > > > > >>>>>>>>>>>>> Ard Biesheuvel <[email protected]> > > > > > >>>>>>>>>>>>> Subject: Re: EBBR: RISC-V handoff to OS > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> On 9/23/20 7:24 AM, Chang, Abner (HPS SW/FW > > > > > Technologist) > > > > > >>>> wrote: > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>> -----Original Message----- > > > > > >>>>>>>>>>>>>>> From: Heinrich Schuchardt > > > > [mailto:[email protected]] > > > > > >>>>>>>>>>>>>>> Sent: Tuesday, September 22, 2020 5:30 PM > > > > > >>>>>>>>>>>>>>> To: [email protected]; Chang, > > > > > >>>>>>>>>>>>>>> Abner (HPS SW/FW > > > > > >>>>>>>>>>>>>>> Technologist) <[email protected]>; Atish > > Patra > > > > > >>>>>>>>>>>>>>> <[email protected]> > > > > > >>>>>>>>>>>>>>> Cc: [email protected]; Rick > > > > > >>>>>>>>>>>>>>> Chen <[email protected]>; Atish Patra > > > > > >> <[email protected]>; > > > > > >>>>>>>>>>>>>>> Grant Likely <[email protected]>; Ard > > > > > >>>>>>>>>>>>>>> Biesheuvel <[email protected]> > > > > > >>>>>>>>>>>>>>> Subject: RE: EBBR: RISC-V handoff to OS > > > > > >>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>> Am 22. September 2020 08:30:57 MESZ schrieb > > > > > >>>>>>>>>>>>>>> "Chang, > > > > > >> Abner > > > > > >>>>>>>>>>>>>>> (HPS > > > > > >>>>>>>>>>>>> SW/FW > > > > > >>>>>>>>>>>>>>> Technologist)" <[email protected]>: > > > > > >>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>> -----Original Message----- > > > > > >>>>>>>>>>>>>>>>> From: Atish Patra > > > > > >>>>>>>>>>>>>>>>> [mailto:[email protected]] > > > > > >>>>>>>>>>>>>>>>> Sent: Tuesday, September 22, 2020 2:08 PM > > > > > >>>>>>>>>>>>>>>>> To: Chang, Abner (HPS SW/FW Technologist) > > > > > >>>>>>>>>>> <[email protected]> > > > > > >>>>>>>>>>>>>>>>> Cc: Heinrich Schuchardt > <[email protected]>; > > > > Atish > > > > > >>>> Patra > > > > > >>>>>>>>>>>>>>>>> <[email protected]>; > > > > > >>>>>>>>>>>>>>>>> [email protected]; > > > > > >>>>>>>>>>>>>>>>> Grant > > > > > >>>>>>>>>>>>>>>> Likely > > > > > >>>>>>>>>>>>>>>>> <[email protected]>; Ard Biesheuvel > > > > > >>>> <[email protected]>; > > > > > >>>>>>>> Rick > > > > > >>>>>>>>>>>>> Chen > > > > > >>>>>>>>>>>>>>>>> <[email protected]> > > > > > >>>>>>>>>>>>>>>>> Subject: Re: EBBR: RISC-V handoff to OS > > > > > >>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>> On Mon, Sep 21, 2020 at 6:11 PM Chang, Abner > > > > > >>>>>>>>>>>>>>>>> (HPS > > > > > >>>> SW/FW > > > > > >>>>>>>>>>>>>>>>> Technologist) <[email protected]> wrote: > > > > > >>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> -----Original Message----- > > > > > >>>>>>>>>>>>>>>>>>> From: Atish Patra > > > > > >>>>>>>>>>>>>>>>>>> [mailto:[email protected]] > > > > > >>>>>>>>>>>>>>>>>>> Sent: Tuesday, September 22, 2020 2:28 AM > > > > > >>>>>>>>>>>>>>>>>>> To: Heinrich Schuchardt > > <[email protected]> > > > > > >>>>>>>>>>>>>>>>>>> Cc: Atish Patra <[email protected]>; > > > > > >>>>>>>>>>>>>>>>>>> [email protected]; > > > > > >>>>>>>>>>>>>>>>>>> Grant Likely <[email protected]>; Ard > > > > > Biesheuvel > > > > > >>>>>>>>>>>>>>>>>>> <[email protected]>; Rick Chen > > > > > >> <[email protected]>; > > > > > >>>>>>>>>>>>>>>>>>> Chang, > > > > > >>>>>>>>>>>>> Abner > > > > > >>>>>>>>>>>>>>>>> (HPS > > > > > >>>>>>>>>>>>>>>>>>> SW/FW Technologist) > > <[email protected]> > > > > > >>>>>>>>>>>>>>>>>>> Subject: Re: EBBR: RISC-V handoff to OS > > > > > >>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> On Mon, Sep 21, 2020 at 9:23 AM Heinrich > > > > > Schuchardt > > > > > >>>>>>>>>>>>>>>>>>> <[email protected]> wrote: > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> Hello Atish, > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> the UEFI spec has this sentence: > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> "When UEFI firmware handoff control to > OS, > > > > > >>>>>>>>>>>>>>>>>>>> the > > > > > >> RISC-V > > > > > >>>>>>>>>>>>>>>>>>>> is > > > > > >>>>>>>>>>>>>>>> operated > > > > > >>>>>>>>>>>>>>>>>>>> in machine-mode privilege." (M-mode is > the > > > > > >> equivalent > > > > > >>>>>>>>>>>>>>>>>>>> to > > > > > >>>>>>>>>>>>>>>>>>>> EL3 in > > > > > >>>>>>>>>>>>>>>> ARM). > > > > > >>>>>>>>>>>>>>>>>> Yes, this is a pretty old section in UEFI > > > > > >>>>>>>>>>>>>>>>>> spec even before OpenSBI > > > > > >>>>>>>>>>>>>>>> as I can > > > > > >>>>>>>>>>>>>>>>> remember and haven't been updated to sync > > with > > > > > latest > > > > > >>>>>>>>>>>>>>>>> status RISC-V > > > > > >>>>>>>>>>>>>>>> works. > > > > > >>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> This does not make any sense to me when > > using > > > > a > > > > > >>>> secure > > > > > >>>>>>>>>>>>>>>> execution > > > > > >>>>>>>>>>>>>>>>>>>> environement (SEE) like OpenSBI. > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> The hand-off should occur in S-Mode if the > > > > > >>>>>>>>>>>>>>>>>>>> CPU > > > > > >>>> supports > > > > > >>>>>>>>>>>>>>>>>>>> it and only in M-Mode when the CPU only > > > > > supports > > > > > >> M- > > > > > >>>> mode. > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> +Abner > > > > > >>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> Yes. Abner has already submitted an ECR for > > > > > >>>>>>>>>>>>>>>>>>> this > > > > & > > > > > >> few > > > > > >>>>>>>>>>>>>>>>>>> other > > > > > >>>>>>>>>>>>>>>> RISC-V > > > > > >>>>>>>>>>>>>>>>>>> related changes to UEFI spec. I am not sure > > > > > >>>>>>>>>>>>>>>>>>> about the current > > > > > >>>>>>>>>>>>>>>> status > > > > > >>>>>>>>>>>>>>>>> though. > > > > > >>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> @Abner: Do you know the latest status ? > > > > > >>>>>>>>>>>>>>>>>> Yes, the ECR was submitted to USWG for > > review, > > > > > >> however > > > > > >>>>>>>>>>>>>>>>>> the > > > > > >>>>>>>>>>>>> meeting > > > > > >>>>>>>>>>>>>>>>>> canceled often recently and the process goes > > slow. > > > > > >>>>>>>>>>>>>>>>>> I will keep following up > > > > > >>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> Maybe you also attach the latest ECR here > > > > > >>>>>>>>>>>>>>>>>>> for a broader > > > > > >>>>>>>> review. > > > > > >>>>>>>>>>>>>>>>>> I may not allowed to public ECR here unless > > > > > >>>>>>>>>>>>>>>>>> all people in the > > > > > >>>>>>>>>>>>>>>> mailing > > > > > >>>>>>>>>>>>>>>>>> list are the members of UEFI org… but the > > > > sentence > > > > > we > > > > > >>>>>>>>>>>>>>>>>> revised in > > > > > >>>>>>>>>>>>>>>> ECR > > > > > >>>>>>>>>>>>>>>>>> is as below, > > > > > >>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>> "When UEFI firmware handoff control to > > > > Supervisor > > > > > >> mode > > > > > >>>>>>>>>>>>>>>>>> OS, RISC-V > > > > > >>>>>>>>>>>>>>>> boot > > > > > >>>>>>>>>>>>>>>>> hart must be operated in Supervisor mode, > and > > > > > >>>>>>>>>>>>>>>>> the > > > > > >>>> memory > > > > > >>>>>>>>>>>>> addressing > > > > > >>>>>>>>>>>>>>>>> must be operated in Bare mode which is no > > memory > > > > > >>>> address > > > > > >>>>>>>>>>>>>>>>> translation > > > > > >>>>>>>>>>>>>>>> or > > > > > >>>>>>>>>>>>>>>>> protection through the virtual page table > entry." > > > > > >>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>> Thanks. > > > > > >>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>> We didn’t mention hand-off to M-Mode if > CPU > > > > only > > > > > >>>> support > > > > > >>>>>>>>>>>>>>>>>> M- > > > > > >>>>>>>>>>> Mode > > > > > >>>>>>>>>>>>>>>>> because we only verified edk2 RISC-V port in > > > > > >>>>>>>>>>>>>>>>> S- > > > > Mode > > > > > >> with > > > > > >>>>>>>>>>>>>>>>> OpenSBI, but didn’t try it on M-Mode even > > though > > > > > the > > > > > >>>> code > > > > > >>>>>>>>>>>>>>>>> is > > > > > >>>>>>>>>> ready there. > > > > > >>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>> That's correct. We can't run UEFI applications > > > > > >>>>>>>>>>>>>>>>> run time services in > > > > > >>>>>>>>>>>>>>>> M-mode as > > > > > >>>>>>>>>>>>>>>>> it requires virtual memory in current setup. > > > > > >>>>>>>>>>>>>>>>> I think it is better to keep that way there is > > > > > >>>>>>>>>>>>>>>>> a specific demand and > > > > > >>>>>>>>>>>>>>>> value in > > > > > >>>>>>>>>>>>>>>>> running UEFI applications in M-mode. > > > > > >>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> We should prescribe this in the EBBR and > > > > > somehow > > > > > >> get > > > > > >>>>>>>>>>>>>>>>>>>> the UEFI > > > > > >>>>>>>>>>>>>>>> spec > > > > > >>>>>>>>>>>>>>>>>>>> fixed afterwards. > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> I will add it to the RISC-V EBBR PR (haven't > > > > > >>>>>>>>>>>>>>>>>>> sent it > > > > > yet). > > > > > >>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> An other issue is the calling convention. > > > > > >>>>>>>>>>>>>>>>>>>> Chapter > > > > > >>>>>>>>>>>>>>>>>>>> "2.3.7.3 Detailed Calling Convention" does > > > > > >>>>>>>>>>>>>>>>>>>> not describe which registers > > > > > >>>>>>>>>>>>>>>> are > > > > > >>>>>>>>>>>>>>>>>>>> saved by the UEFI payload's entry point > and > > > > > >>>>>>>>>>>>>>>>>>>> restored > > > > > >>>> by > > > > > >>>>>>>>>>>>>>>>>>>> the payload before calling the UEFI API or > > > > > >>>>>>>>>>>>>>>>>>>> returning to the UEFI payload. This > > > > > >>>>>>>>>>>>>>>>>>>> concerns especially registers gp > > > > > >>>>>>>>>>>>>>>>>>>> (x3) and tp > > > > > >>>>>>>>>>>>>>>> (x4). > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> Into the EBBR or UEFI spec we should put a > > > > > >>>>>>>>>>>>>>>>>>>> link to the "RISC-V > > > > > >>>>>>>>>>>>>>>> ELF > > > > > >>>>>>>>>>>>>>>>>>>> psABI specification" > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>> https://github.com/riscv/riscv-elf-psabi- > > > > > >> doc/blob/master/ > > > > > >>>>>>>>>>>>>>>> ri > > > > > >>>>>>>>>>>>>>>> scv- > > > > > >>>>>>>>>>>>>>>> e > > > > > >>>>>>>>>>>>>>>> lf > > > > > >>>>>>>>>>>>>>>>>>>> .md which is referenced by "The RISC-V > > > > > Instruction > > > > > >>>>>>>>>>>>>>>>>>>> Set > > > > > >>>>>>>>>> Manual". > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> From the "RISC-V ELF psABI specification" > > one > > > > > might > > > > > >>>>>>>>>>>>>>>>>>>> conclude > > > > > >>>>>>>>>>>>>>>> that > > > > > >>>>>>>>>>>>>>>>>>>> the UEFI payload should not be allowed to > > > > change > > > > > gp > > > > > >>>> and > > > > > >>>>>>>>>>>>>>>>>>>> tp > > > > > >>>>>>>>>>>>>>>> before > > > > > >>>>>>>>>>>>>>>>>>>> calling > > > > > >>>>>>>>>>>>>>>>>>>> ExitBootServices() or > > > > > >>>>>>>>>>>>>>>>>>>> SetVirtualAddressMap() > > > > > >>>> whichever > > > > > >>>>>>>>>>>>>>>>>>>> occurs > > > > > >>>>>>>>>>>>>>>> last. > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>> Agreed. Thanks for pointing this out. I > > > > > >>>>>>>>>>>>>>>>>>> think this should go into the UEFI spec > > > > > >>>>>>>>>>>>>>>>>>> instead of > > EBBR spec. > > > > > >> Any > > > > > >>>> suggestions ? > > > > > >>>>>>>>>>>>>>>>>> To have this external link is good, I will > > > > > >>>>>>>>>>>>>>>>>> add this link in > > > > > >> ECR. > > > > > >>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>> Thanks again :). As per Heinrich's suggestion, > > > > > >>>>>>>>>>>>>>>>> it would also be good > > > > > >>>>>>>>>>>>>>>> to add > > > > > >>>>>>>>>>>>>>>>> some text about the state of gp & tp. > > > > > >>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>> Ok. I add some text, copied from psABI spec. :) > > > > > >>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>> "........ Registers tp and gp should not be > > > > > >>>>>>>>>>>>>>>> modified in the function, > > > > > >>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>> I would not know what "in the function" refers > > > > > >>>>>>>>>>>>>>> to > > here. > > > > > >>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>> We have a value of tp and gp passed from the > > > > firmware > > > > > to > > > > > >>>>>>>>>>>>>>> the entry-point of the firmware. We need a > > > > > >>>>>>>>>>>>>>> definition describing what assumptions the > > > > > >>>>>>>>>>>>>>> firmware may or may > > > > > not > > > > > >>>>>>>>>>>>>>> make about > > > > > >>>> the > > > > > >>>>>>>>>>>>>>> value of tp and gp up to ExitBootServices and in > > > > > >>>>>>>>>>>>>>> SetVirtualAddressMap. I would not assume gp > and > > tp > > > > to > > > > > >> have > > > > > >>>>>>>>>>>>>>> any firmware related value > > > > > >>>>>>>>>> afterwards. > > > > > >>>>>>>>>>>>>> Ok, I got your point. But do we mention "value > > > > > >>>>>>>>>>>>>> of tp and gp passed from > > > > > >>>>>>>>>>>>> the firmware to the entry-point of the firmware" > > > > > somewhere > > > > > >>>>>>>>>>>>> in the particular spec? What is the spec of values > > > > > >>>>>>>>>>>>> you pass in tp/gp to the entry point of firmware? > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>> It would be perfectly ok if the spec said that > > > > > >>>>>>>>>>>>>>> the firmware should make no assumptions about > > > > > >>>>>>>>>>>>>>> the value > > > > > of > > > > > >>>>>>>>>>>>>>> these registers > > > > > >>>>>>>>>>>>>> I don’t think firmware has assumption of value in > > > > > >>>>>>>>>>>>>> these registers because the calling convention > > > > > >>>>>>>>>>>>>> doesn't use these two regs. Maybe the assembly > > code > > > > > >>>>>>>>>>>>>> use these > > > > two > > > > > >>>>>>>>>>>>>> regs for > > > > > >>>> some > > > > > >>>>>>>>>>>>>> purpose but firmware has to preserve it. The > > > > > >>>>>>>>>>>>>> revised version in below, > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>> but has to keep the values intact during an API > call. > > > > > >>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>> The important thing is that we have a clear > > > > > >>>>>>>>>>>>>>> definition of the interface between the firmware > > > > > >>>>>>>>>>>>>>> and the > > > > payload. > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>> How about this, > > > > > >>>>>>>>>>>>>> "Registers tp and gp are unallocatable and not > > > > > >>>>>>>>>>>>>> preserved across the > > > > > >>>>>>>>>>>>> function calls, UEFI firmware implementation of > > > > > >>>>>>>>>>>>> RISC-V platform should keep the values in these > > > > > >>>>>>>>>>>>> two registers intact during entire UEFI firmware > > > > > >>>>>>>>>>>>> boot process, UEFI boot service and > > > > > >>>> runtime service. > > > > > >>>>>>>>>>>>> See “Link to UEFI Specification-Related Document” > > > > > >>>>>>>>>>>>> on https://uefi.org/uefi under the heading “RISC-V > > > > > >>>>>>>>>>>>> EFL psABI Specification” for the more descriptions > > > > > >>>>>>>>>>>>> of RISC-V calling > > > > > >>>> convention." > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Current situation in U-Boot > > > > > =========================== > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> With U-Boot we currently have the following boot > > flows: > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> U-Boot -> payload > > > > > >>>>>>>>>>>>> OpenSBI -> payload U-Boot SPL -> OpenSBI -> U- > Boot > > > > > >>>>>>>>>>>>> -> payload > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Upon entry U-Boot overwrites tp with the HART id > > > > > >>>>>>>>>>>>> on all HARTs and the boot HART's gp with a pointer > > > > > >>>>>>>>>>>>> to U-Boot's global data > > > > > >>>> structure. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> At boot time when the payload makes an API call > > > > > >>>>>>>>>>>>> U-Boot replaces the payload's gp by its own value > > > > > >>>>>>>>>>>>> upon entry and restores the payload's gp before > > > > > >>>>>>>>>>>>> returning to the > > > > payload. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> At runtime UBoot neither touches gp nor tp. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Interrupt handling ================== > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Before ExitBootServices() handling of interrupts > > > > > >>>>>>>>>>>>> and exceptions is the task of the firmware. As > > > > > >>>>>>>>>>>>> both may rely on the values of tp and gp the > > > > > >>>>>>>>>>>>> payload should not overwrite > > > > > >> them. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> When the operating system takes over it also has > > > > > >>>>>>>>>>>>> gets the responsibility for handling interrupts > > > > > >>>>>>>>>>>>> and exceptions and will set its own > > > > > >>>>>>>>>>> values of tp and gp. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Some operating systems call SetVirtualAddressMap() > > > > after > > > > > >>>>>>>>>>>>> ExitBootServices(), others don't. On Linux this is > > > > > >>>>>>>>>>>>> controlled by kernel command line parameter > > > > efi=novamap. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Conclusion > > > > > >>>>>>>>>>>>> ========== > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> I would suggest the following rules: > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> Until ExitBootServices() returns to the payload > > > > > >>>>>>>>>>>>> the firmware is the owner of registers gp and tp. > > > > > >>>>>>>>>>>>> The payload MUST NOT alter these > > > > > >>>>>>>> values. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> This implies that when handling > > > > > >>>> EVT_SIGNAL_EXIT_BOOT_SERVICES > > > > > >>>>>>>>>>> events > > > > > >>>>>>>>>>>>> the payload MUST NOT alter gp and tp. > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> After ExitBootServices() the payload is the owner > > > > > >>>>>>>>>>>>> of registers gp and tp. The firmware MUST NOT > > > > > >>>>>>>>>>>>> alter these > > > > > >> values. > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> The firmware solution you mentioned above is the > > > > > >>>>>>>>>>>> payload solution with > > > > > >>>>>>>>>>> either uboot or opensbi. However, edk2 firmware > > > > > >>>>>>>>>>> solution is not the > > > > > >>>>>>>> same. > > > > > >>>>>>>>>>> RISC-V edk2 firmware solution uses OpenSBI as the > > library. > > > > > >>>>>>>>>>> Thus we don't have to mention specific firmware > > > > > >>>>>>>>>>> solution in UEFI > > > > > >> spec. > > > > > >>>>>>>>>>>> I think the final sentence already covered all use > > > > > >>>>>>>>>>>> cases you mentioned > > > > > >>>>>>>>>>> above, that includes the EFI POST time and the UEFI > > > > > >>>>>>>>>>> service exposed to user such as EFI boot service and > > > > > >>>>>>>>>>> EFI runtime service. We don’t have to mention > > > > > >>>>>>>>>>> specific rule in > > > > the spec. > > > > > >>>>>>>>>>> I revised it again and add EFI Management Mode > service. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> My references to U-Boot where not meant for > > > > > >>>>>>>>>>> inclusion in any spec but as background information > only. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> "Registers tp and gp are unallocatable and not > > > > > >>>>>>>>>>>> preserved across the > > > > > >>>>>>>>>>> function calls, UEFI firmware implementation of > > > > > >>>>>>>>>>> RISC-V platform should keep the values in these two > > > > > >>>>>>>>>>> registers intact during entire UEFI firmware boot > > > > > >>>>>>>>>>> process, EFI boot services, EFI runtime services and > > > > > >>>>>>>>>>> EFI management mode services. See “Link to UEFI > > > > > >>>>>>>>>>> Specification-Related > > Document” > > > > > >>>>>>>>>>> on https://uefi.org/uefi under the heading “RISC-V > > > > > >>>>>>>>>>> EFL psABI Specification” for the more descriptions > > > > > >>>>>>>>>>> of > > > > > >>>>>>>> RISC-V calling convention." > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Please, have a look at RFC 2119 "Key words for use > > > > > >>>>>>>>>>> in RFCs to Indicate Requirement Levels" [INVALID URI > > > > > >>>>>>>>>>> REMOVED > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>> > > > > > >>>> > > > > > >> > > > > > > > > > > > > 3A__tools.ietf.org_html_rfc2119&d=DwIFaQ&c=C5b8zRQO1miGmBeVZ2LFW > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>> > > > > > >>>> > > > > > >> > > > > > > > > > > > > g&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=M_APpMPr8z > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>> > > > > > >>>> > > > > > >> > > > > > > > > > > > > v5FK0ys5Noq10akQQqL0eNc9vlZqmOkpw&s=DBCkr05bpuKrQWdyNn5bJSow > > > > > >>>>>>>>>>> sLV7UDvDJIJc3nT4jd0&e= ]. Here "should" > > > > > >>>>>>>>>>> has the meaning of "recommended" and may be > > ignored > > > > > >>>>>>>>>>> "in particular circumstances". > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Did you mean SHOULD or MUST? > > > > > >>>>>>>>>> MUST is better, to make UEFI firmware solution simple. > > > > > >>>>>>>>>> UEFI > > > > > >>>>>>>>>> edk2 implementation could be a stand along firmware > > > > > >>>>>>>>>> or to be built as the payload (we don’t have this > > > > > >>>>>>>>>> implementation > > > > yet). > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> "are unallocatable" is vague. It does not describe > > > > > >>>>>>>>>>> who is not allowed to change the values. Is it the > > > > > >>>>>>>>>>> firmware or is it the > > > > > >> payload? > > > > > >>>>>>>>>> From UEFI perspective, UEFI firmware payload is not > > > > > >>>>>>>>>> allowed to change the value. I will rephrase this > sentence. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> "keep the values intact" is vague. It could mean > > > > > >>>>>>>>>>> that the firmware SHOULD reset gp and tp to the > > > > > >>>>>>>>>>> values they had > > > > had > > > > > >>>>>>>>>>> before > > > > > >>>>>>>>>>> StartImage() whenever an API call is made. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> We need a definition that cannot be misunderstood. > > > > > >>>>>>>>>>> In my definition it is at least clear who is the > > > > > >>>>>>>>>>> owner of tp > > and gp. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Please, consider that before ExitBootServices() many > > > > > >>>>>>>>>>> different payloads may be loaded by the firmware: > > > > > >>>>>>>>>>> applications, boot service drivers, runtime service > drivers. > > > > > >>>>>>>>>>> This is why to me it does not make sense to allow > > > > > >>>>>>>>>>> any other software but the firmware to define the > > > > > >>>>>>>>>>> values of > > > > > >>>>>>>>>> tp and gp before ExitBootServices(). > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> I am not against that firmware to define the values > > > > > >>>>>>>>>> of tp and gp. I think the "firmware" you mentioned > > > > > >>>>>>>>>> here refer to uboot but not edk2 > > > > > >>>>>>>> firmware. > > > > > >>>>>>>> > > > > > >>>>>>>> I refer to the firmware providing the UEFI API. U-Boot > > > > > >>>>>>>> and EDK II are alternative implementations. > > > > > >>>>>>>> > > > > > >>>>>>>>>> I am also fine to mention UEFI firmware should not > > > > > >>>>>>>>>> (Must > > > > > >>>>>>>>>> not) use gp and tp in spec. I would like to restrict > > > > > >>>>>>>>>> using these two registers in UEFI firmware no matter > > > > > >>>>>>>>>> the RISC-V UEFI firmware implementation is a stand > > > > > >>>>>>>>>> along system firmware or a payload for other firmware > > > > > >>>>>>>>>> such as uboot/opensbi, this would be easier for us to > > > > > >>>>>>>>>> maintain RISC-V edk2 port. Hope I don’t misunderstand > > > > > >>>>>>>> > > > > > >>>>>>>> Both U-Boot and EDK II may be started by an SEE, e.g. > > OpenSBI. > > > > > >>>>>>>> > > > > > >>>>>>>>>> the intention which you brought up here, which is the > > > > > >>>>>>>>>> UEFI firmware payload must not altering the value of > > > > > >>>>>>>>>> gp and tp, > > > > right? > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> However, I don’t want to see that we list the > > > > > >>>>>>>>>> specific functions such as ExitBootServices, > > > > > >>>>>>>>>> startImage, SetVirtualAddress in the UEFI spec, we > > > > > >>>>>>>>>> can just give the strict criteria to UEFI firmware to > > > > > >>>>>>>>>> not > > > > > >>>> using gp/tp. > > > > > >>>>>>>>>> Says UEFI firmware can't alter tp/gp values, > > > > > >>>>>>>>>> - After firmware enters UEFI firmware payload and > > > > > >>>>>>>>>> before returning to > > > > > >>>>>>>>>> firmware>> - In BS > > > > > >>>>>>>>>> - In RTS > > > > > >>>>>>>>>> - In SMM service > > > > > >>>>>>>> > > > > > >>>>>>>> Everytime U-Boot code is entered during boot services > > > > > >>>>>>>> the payloads gp is saved. When returning to the payload > > > > > >>>>>>>> the payloads value of the gp is restored. So the > > > > > >>>>>>>> payload cannot observe any > > > > > >> change in gp. > > > > > >>>>>>>> At runtime U- Boot does not touch gp. > > > > > >>>>>>>> > > > > > >>>>>>>> I hope that is in line with your suggestion. > > > > > >>>>>>>> > > > > > >>>>>>>> Best regards > > > > > >>>>>>>> > > > > > >>>>>>>> Heinrich > > > > > >>>>>>>> > > > > > >>>>>>>>>> These should cover all possibilities of gp/tp value > > > > > >>>>>>>>>> changed in UEFI > > > > > >>>>>>>> firmware. > > > > > >>>>>>>>>> We don’t even have to define the ownership of these > > > > > >>>>>>>>>> registers in UEFI > > > > > >>>>>>>> spec. > > > > > >>>>>>>>> BTW, above is based on the edk2 UEFI implementation. I > > > > > >>>>>>>>> am not sure if > > > > > >>>>>>>> other UEFI firmware implementation can avoid to use > > > > > >>>>>>>> these > > > > > >> registers. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Best regards > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Heinrich > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>> because signal handlers may rely upon their > > values. > > > > > >>>>>>>>>>>>>>>> See “Link to UEFI Specification-Related > Document” > > > > > >>>>>>>>>>>>>>>> on https://uefi.org/uefi under the heading > > > > > >>>>>>>>>>>>>>>> “RISC-V EFL psABI Specification” for the more > > > > > >>>>>>>>>>>>>>>> descriptions of RISC-V calling > > > > > >>>>>>>> convention." > > > > > >>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>> I will upload this update to USWG once Heinrich > > > > > >>>>>>>>>>>>>>>> agrees with > > > > > >>>>>>>> above. > > > > > >>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>>>>>>>>> Due to this missing clarification U-Boot is > > > > > >>>>>>>>>>>>>>>>>>>> currently saving gp before calling the > > > > > >>>>>>>>>>>>>>>>>>>> entry point of the payload and restores it > > > > > >>>>>>>>>>>>>>>> on > > > > > >>>>>>>>>>>>>>>>>>>> reentry or on entry of an API call. Nothing > > > > > >>>>>>>>>>>>>>>>>>>> is done for > > > > > >> tp. > > > > > >>>>>>>>>>>>>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> boot-architecture mailing list > > > > > >>> [email protected] > > > > > >>> https://lists.linaro.org/mailman/listinfo/boot-architecture > > > > > >>> > > > > > > > > > > > > > > > -- > > Regards, > > Atish _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
