Re: FIT image: load secure FPGA

[Michal Simek <michal.simek@xilinx.com>]

Hi,

On 10/5/21 8:08 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> 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.
>>

In past when I was adding support for bitstreams in 2016 by commit
62afc601883e ("image: Add boot_get_fpga() to load fpga with bootm")
you can see that the problem was sort of the same as this one. But with
handling different bitstream types. Because there are two types of
bistreams in bin format and bit format.
At that time I solved it by calling function in bit format first. If
failed in bin format. And by comparing sizes it was determined if
bitstream is in bit or bin format.

I would say that this algorithm is not valid anymore because you can
also have compressed bistreams which are smaller then device itself but
still they are full bistreams.

That being said I think when new types should be defined we should also
optimized origin code for fpga loading to cover also partial bistreams
and bistreams in bin and bit formats.

Thanks,
Michal