Re: FIT image: load secure FPGA

["Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>]

On 05/10/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 04/10/21, Alex G. wrote:
> > On 10/4/21 3:32 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > Hello,
> > >
> 
> hi Alex,
> 
> > > We are enabling secure boot on Zynqmp with SPL.
> > > 
> > > The issue however is that during secure boot, the bootrom not only
> > > validates the first loader (SPL and PMUFW combo) but it will also
> > > expect a signed bitstream during load(FPGA).
> > > 
> > > Since currently the SPL load of an FPGA image from FIT does not
> > > support loading images for authentication (fpga_loads), I'd like to
> > > discuss how to best implement such support.
> > 
> > What do you mean by "loading images for authentication" ?
> 
> right, it eventually means executing fpga_loads insted of fpga_load (
> a function that will provide additional params to the PMUFW.
> 
> "loads" will load FPGA bitstreams that are either signed, encrypted or
> both. When they are only signed, they are first authenticated by the
> PMUFW and then loaded.
> 
> > > 
> > > A pretty standard file.its description of the FPGA loadable looks like
> > > this:
> > > 
> > >   fpga {
> > >        description = "FPGA binary";
> > >        data = /incbin/("${DEPLOY_DIR_IMAGE}/${SPL_FPGA_BINARY}");
> > >        type = "fpga";
> > >        arch = "${UBOOT_ARCH}";
> > >        compression = "none";
> > >        load = <${fpgaloadaddr}>;
> > >        hash-1 {
> > >        	     algo = "${FIT_HASH_ALG}";
> > > 	     };
> > >        };
> > > 
> > > We could extend imagetool.h struct image_tool_params to add more
> > > params or perhpas just define different 'types' of fpga?
> > 
> > 
> > Check "4) '/images' node"
> >   in doc/uImage.FIT/source_file_format.txt
> > 
> > The intent is to give either:
> >    * loadaddr="$(addr)" : copy image to $(addr), Done
> >    * compatible="": Use this driver to upload the FPGA
> > 
> > It seems to me like the right way to go is to make a new compatible="" FPGA
> > loader is for fpga_load():
> > 
> > 	fpga {
> > 		description = "FPGA binary";
> > 		data = /incbin/("${YOCTO_BS_PATH}");
> > 		type = "fpga";
> > 		compression = "none";
> > 		compatible = "zynqmp-fancy-fpga",
> 
> so you think we should capture on compatible the characteristics of the FPGA image?


um, right, makes sense then, thanks.

  - compatible : compatible method for loading image.                                                                                       
    Mandatory for types: "fpga", and images that do not specify a load address.                                                             
    To use the generic fpga loading routine, use "u-boot,fpga-legacy"

> 
> > 		hash-1 {
> > 			algo = "${FIT_HASHISH}";
> > 		};
> > 	};
> > 
> > 
> > > Something like:
> > >    "fpga"
> > >    "fpga-auth" : authenticated
> > >    "fpga-enc"  : encrypted
> > >    "fpga-sec"  : encrypted and authenticated
> > 
> > Can these properties be inferred from the FPGA image? If not, they could be
> > required when using a new fpga loader. I don't think they should be added to
> > "fpga-legacy".
> 
> maybe.. with a bit of boot header parsing... But doing so would
> deviate from the current approach making it somewhat inconsistent: ie,
> there is no a common "fpga load" command but instead we have "fpga
> load" and "fpga loads" as separate commands so perhaps the parsing is
> not that obvious or it would have been done differently.
> I'd rather follow the current approach and just explicitly qualify the
> bitstream.
> 
> 
> 
> > 
> > Alex
> > 
> > > Then it would be a matter of modifying
> > > https://github.com/u-boot/u-boot/blob/master/common/spl/spl_fit.c#L572
> > > 
> > > any thoughts?
> > > 
> > > TIA
> > > Jorge
> > >