All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>
To: "Alex G." <mr.nuke.me@gmail.com>
Cc: "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>,
	michal.simek@xilinx.com, trini@konsulko.com, sjg@chromium.org,
	u-boot@lists.denx.de, ricardo@foundries.io, mike@foundries.io,
	igor.opaniuk@foundries.io
Subject: Re: FIT image: load secure FPGA
Date: Tue, 5 Oct 2021 07:45:43 +0200	[thread overview]
Message-ID: <20211005054543.GA4478@trex> (raw)
In-Reply-To: <b77928d7-6ebc-0931-37dd-35fa6eb77ede@gmail.com>

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?

> 		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
> > 

  reply	other threads:[~2021-10-05  5:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04 20:32 FIT image: load secure FPGA Jorge Ramirez-Ortiz, Foundries
2021-10-04 20:54 ` Alex G.
2021-10-05  5:45   ` Jorge Ramirez-Ortiz, Foundries [this message]
2021-10-05  6:08     ` Jorge Ramirez-Ortiz, Foundries
2021-10-05 12:14       ` Michal Simek
2022-01-19 16:03 ` Adrian Fiergolski
2022-01-19 16:44   ` Jorge Ramirez-Ortiz, Foundries
2022-01-19 16:51     ` Jorge Ramirez-Ortiz, Foundries
2022-01-19 17:22       ` Jorge Ramirez-Ortiz, Foundries
2022-01-19 17:48         ` Oleksandr Suvorov
2022-02-07 12:24           ` Adrian Fiergolski
2022-02-09  7:51             ` Jorge Ramirez-Ortiz, Foundries
2022-02-09 12:20               ` Adrian Fiergolski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211005054543.GA4478@trex \
    --to=jorge@foundries.io \
    --cc=igor.opaniuk@foundries.io \
    --cc=michal.simek@xilinx.com \
    --cc=mike@foundries.io \
    --cc=mr.nuke.me@gmail.com \
    --cc=ricardo@foundries.io \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.