From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [U-Boot, 1/1] arm: mach-omap2: Fix secure file generation
Date: Fri, 9 Dec 2016 16:30:27 -0500 [thread overview]
Message-ID: <20161209213027.GK4248@bill-the-cat> (raw)
In-Reply-To: <3e2fa7f5-0e25-cf39-5a54-4367e091636d@ti.com>
On Fri, Dec 09, 2016 at 02:24:32PM -0600, Andrew F. Davis wrote:
> On 12/09/2016 02:10 PM, Tom Rini wrote:
> > On Fri, Dec 09, 2016 at 02:05:29PM -0600, Andrew F. Davis wrote:
> >> On 12/09/2016 01:59 PM, Tom Rini wrote:
> >>> On Thu, Dec 08, 2016 at 04:48:07PM -0600, Andrew F. Davis wrote:
> >>>
> >>>> When TI_SECURE_DEV_PKG is not defined we warn that the file '*_HS' was
> >>>> not generated but generate an unsigned one anyway. When TI_SECURE_DEV_PKG
> >>>> is exported and the user re-builds, make will detect this file as
> >>>> unchangedand and so assume it does not need to be re-generated. This
> >>>> causes it to pack unsigned files. Fix this by not generating these
> >>>> fake unsigned *_HS files.
> >>>>
> >>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
> >>>> Reviewed-by: Tom Rini <trini@konsulko.com>
> >>>> ---
> >>>> arch/arm/mach-omap2/config_secure.mk | 4 ++--
> >>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/arch/arm/mach-omap2/config_secure.mk b/arch/arm/mach-omap2/config_secure.mk
> >>>> index 1122439..33c7059 100644
> >>>> --- a/arch/arm/mach-omap2/config_secure.mk
> >>>> +++ b/arch/arm/mach-omap2/config_secure.mk
> >>>> @@ -35,12 +35,12 @@ cmd_omapsecureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
> >>>> else
> >>>> cmd_omapsecureimg = echo "WARNING:" \
> >>>> "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
> >>>> - "$@ was NOT created!"; cp $< $@
> >>>> + "$@ was NOT created!";
> >>>> endif
> >>>> else
> >>>> cmd_omapsecureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
> >>>> "variable must be defined for TI secure devices." \
> >>>> - "$@ was NOT created!"; cp $< $@
> >>>> + "$@ was NOT created!";
> >>>> endif
> >>>> endif
> >>>
> >>> OK, but now that I build test this (without the tools present) this is a
> >>> NAK. The root problem is that if we don't make that dummy file we then:
> >>> arm: + am57xx_hs_evm
> >>> +(am57xx_hs_evm) ./tools/mkimage: Can't open u-boot-nodtb_HS.bin: No such file or directory
> >>> +(am57xx_hs_evm) ./tools/mkimage: failed to build FIT
> >>> +(am57xx_hs_evm) make[1]: *** [u-boot_HS.img] Error 1
> >>> +(am57xx_hs_evm) make: *** [sub-make] Error 2
> >>
> >> Is this not okay? build *should* fail if TI_SECURE_DEV_PKG is not
> >> defined. You cannot sign images that *need* to be signed to work on this
> >> platform, making a fake un-bootable image instead of failing is a hack
> >> and it confuses the make system when you do put the signing tool in-place.
> >
> > Well, I suppose this is a valid question. I run into it failing as I
> > (and travis-ci) build all ARM targets. Maybe we can have the build not
> > happen (and echo a Warning) and then not invoke mkimage later on if the
> > env isn't right?
>
> For test building you can export TI_SECURE_DEV_PKG to point to a dummy
> signing tool which just runs cp $1 $2. For real world building this tool
> is needed just as much as the compiler, if you don't have it you will
> not build working images, build needs to fail here.
Hmmm, OK. But can we not automate that based on TI_SECURE_DEV_PKG being
unset?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161209/5984f608/attachment.sig>
next prev parent reply other threads:[~2016-12-09 21:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 22:48 [U-Boot] [PATCH 1/1] arm: mach-omap2: Fix secure file generation Andrew F. Davis
2016-12-08 23:22 ` Tom Rini
2016-12-09 19:59 ` [U-Boot] [U-Boot, " Tom Rini
2016-12-09 20:05 ` Andrew F. Davis
2016-12-09 20:10 ` Tom Rini
2016-12-09 20:24 ` Andrew F. Davis
2016-12-09 21:30 ` Tom Rini [this message]
2016-12-09 21:39 ` Andrew F. Davis
2016-12-12 15:30 ` Tom Rini
2016-12-12 13:47 ` Tom Rini
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=20161209213027.GK4248@bill-the-cat \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox