From: Lukasz Majewski <lukma@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
Date: Thu, 6 Jun 2019 09:02:21 +0200 [thread overview]
Message-ID: <20190606090221.0cb5f36b@jawa> (raw)
In-Reply-To: <AM0PR04MB4481443BB7A30E2FAA94377088170@AM0PR04MB4481.eurprd04.prod.outlook.com>
On Thu, 6 Jun 2019 02:33:14 +0000
Peng Fan <peng.fan@nxp.com> wrote:
> > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support
> > loading i.MX container format file
> >
> > On Wed, Jun 05, 2019 at 03:24:40PM +0200, Marek Vasut wrote:
> > > On 6/5/19 5:03 AM, Peng Fan wrote:
> > > [...]
> > > >>>>> It is not duplication of FIT. Container support the similar
> > > >>>>> function of FIT image, but it is not only that.
> > > >>>>
> > > >>>> So what is it ?
> > > >>>
> > > >>>
> > > >>
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > >>>
> > > >>
> > nxp.com%2Fdocs%2Fen%2Freference-manual%2FIMX8DQXPRM.pdf&da
> > > >> ta=02%7C
> > > >>>
> > > >>
> > 01%7Cpeng.fan%40nxp.com%7C72216052f4234a93ad1f08d6e95ed782%7C6
> > > >> 86ea1d3b
> > > >>>
> > > >>
> > c2b4c6fa92cd99c5c301635%7C0%7C1%7C636952990895125305&sdat
> > > >> a=KO%2B0e
> > > >>>
> > > >>
> > E3v%2FkHuJ%2BhR7mBgc4NWXxbMUupfubXXu%2BueIWo%3D&reserv
> > > >> ed=0
> > > >>> Chapter 5 has information about container set and container.
> > > >>
> > > >> Thanks, any specific part of those 80 pages ?
> > > >
> > > > Figure 5-24. Container Format has a picture about a single
> > > > container. i.MX8 container also support container sets, support
> > > > encrypt blob, certificates, SRK management. Support signature
> > > > to the whole container, no need single image inside container.
> > >
> > > Isn't that all supported in fitImage too ?
> >
> > This is neither the first nor last time functionality has been
> > essentially duplicated, sadly, for reasons.
>
> I'll share the fit things to our ROM stakeholders, but they take
> decision on new SoC design.
>
> >
> > > >>>> I don't think I get it. Why would I, as an iMX8 user, want to
> > > >>>> pick custom new vendor-specific format over years-proven
> > > >>>> generic
> > fitImage?
> > > >>>
> > > >>> We not against FIT, we already use FIT on i.MX8M, to let spl
> > > >>> to authenticate FIT image using ROM HAB, not using crypto
> > > >>> driver.
> > > >>
> > > >> Great
> > > >>
> > > >>>> What is the selling point here ?
> > > >>>
> > > >>> We would not introduce cypto driver in SPL stage, that means
> > > >>> HAB FIT and AHAB container needs to be dropped when SPL
> > > >>> loading other
> > images.
> > > >>> ROM already provides API for bootloader to authenticate
> > > >>> images, introducing complex crypto driver in SPL could
> > > >>> enlarge code size and make things complicated.
> > > >>
> > > >> Ah I see, so it's all making the whole crypto simpler by
> > > >> offloading the hard parts into the firmware, which just
> > > >> magically handles everything , without having much extra code
> > > >> in the SPL ?
> > > >
> > > > Yes. Use what ROM provides will make things easier for U-Boot.
> > >
> > > Is it possible to perform a security audit on the ROM as easily
> > > as on U-Boot ? I mean, U-Boot is free software, the source is
> > > available, so security researchers can easily scrutinize it. Is
> > > the ROM ?
> >
> > So, here's my two cents (and it may or may not seem contradictory
> > with my opinions in the secure boot thread going on currently on
> > the Linaro Boot Architecture list). Yes, it would and IMHO is
> > better when we use free and open software to solve our problems
> > (and an aside to the RISC-V folks as this is yet another area they
> > can make the world a better place in). But I am a believe in
> > dealing with the world as it stands at times too. The question
> > isn't "can we get NXP to re-spin i.MX8 to use the FIT image
> > format?" as that's obviously going to be "No.". The question is,
> > "can we support this format in a clean manner?" and the answer is
> > obviously "Yes.". So please lets keep that in mind with reviewing
> > the code as at the end of the day it is more beneficial for this to
> > be supported in mainline U-Boot than only supported in the vendor
> > tree.
>
> Thanks. So I think you agree the current approach. Could I get any
> A-b or R-b tags from the list?
Just to add my 2 cents...
Please if possible provide a good (and as much verbose as possible)
entry to ./doc/README.imx_image (or something) regarding the i.MX8
format.
Thanks in advance,
>
> Thanks,
> Peng.
>
> > Thanks!
> >
> > --
> > Tom
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190606/f1e73b6d/attachment.sig>
next prev parent reply other threads:[~2019-06-06 7:02 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 12:52 [U-Boot] [PATCH 0/6] imx8: support container Peng Fan
2019-05-07 12:52 ` [U-Boot] [PATCH 1/6] imx: mach-imx: clean up Makefile Peng Fan
2019-05-07 12:52 ` [U-Boot] [PATCH 2/6] spl: Add function to get u-boot raw sector Peng Fan
2019-05-07 12:52 ` [U-Boot] [PATCH 3/6] imx8: support parsing i.MX8 Container file Peng Fan
2019-05-07 12:52 ` [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX container format file Peng Fan
2019-05-18 16:09 ` Simon Glass
2019-05-20 1:30 ` Peng Fan
2019-05-20 1:45 ` Marek Vasut
2019-05-20 1:54 ` Peng Fan
2019-05-20 10:36 ` Marek Vasut
2019-05-21 2:31 ` Peng Fan
2019-05-21 2:49 ` Marek Vasut
2019-05-21 2:55 ` Peng Fan
2019-05-21 3:03 ` Marek Vasut
2019-05-21 3:19 ` Peng Fan
2019-05-21 8:32 ` Lukasz Majewski
2019-05-21 12:41 ` Marek Vasut
2019-05-21 13:13 ` Lukasz Majewski
2019-05-22 4:18 ` Peng Fan
2019-05-22 6:02 ` Lukasz Majewski
2019-05-22 6:15 ` Peng Fan
2019-05-22 6:46 ` Lukasz Majewski
2019-05-22 7:22 ` Peng Fan
2019-05-22 7:34 ` Lukasz Majewski
2019-05-22 11:41 ` Marek Vasut
2019-05-24 1:59 ` [U-Boot] [EXT] " Ye Li
2019-05-27 9:49 ` Peng Fan
2019-05-27 11:31 ` Marek Vasut
2019-05-30 7:06 ` Ye Li
2019-05-30 8:19 ` Marek Vasut
2019-06-04 3:27 ` Peng Fan
2019-06-04 11:24 ` Marek Vasut
2019-06-05 1:18 ` Peng Fan
2019-06-05 1:30 ` Marek Vasut
2019-06-05 1:59 ` Peng Fan
2019-06-05 2:38 ` Marek Vasut
2019-06-05 3:03 ` Peng Fan
2019-06-05 13:24 ` Marek Vasut
2019-06-05 13:52 ` Tom Rini
2019-06-05 13:55 ` Marek Vasut
2019-06-06 2:33 ` Peng Fan
2019-06-06 7:02 ` Lukasz Majewski [this message]
2019-06-06 7:23 ` Peng Fan
2019-06-06 7:12 ` Marek Vasut
2019-06-06 7:54 ` Peng Fan
2019-06-06 8:05 ` Marek Vasut
2019-05-22 2:56 ` [U-Boot] " Peng Fan
2019-05-07 12:52 ` [U-Boot] [PATCH 5/6] imx: add container target Peng Fan
2019-05-07 12:52 ` [U-Boot] [PATCH 6/6] imx8qxp_mek: switch to use container image Peng Fan
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=20190606090221.0cb5f36b@jawa \
--to=lukma@denx.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox