Re: [tegrarcm PATCH v1 2/4] Add option --ml_rcm <rcm_ml_blob>

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]

On Sat, Mar 05, 2016 at 02:35:51AM +0000, Jimmy Zhang wrote:
> 
> 
> > -----Original Message-----
> > From: Allen Martin
> > Sent: Friday, March 04, 2016 5:25 PM
> > To: Jimmy Zhang
> > Cc: Stephen Warren; alban.bedel-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org; linux-
> > tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Subject: Re: [tegrarcm PATCH v1 2/4] Add option --ml_rcm <rcm_ml_blob>
> > 
> > On Fri, Mar 04, 2016 at 03:44:45PM -0800, Jimmy Zhang wrote:
> > > This option along with "--pkc <keyfile>" allows user to generate
> > > signed query version rcm, miniloader rcm and signed bootloader
> > > (flasher). With these signed blob, user will then be able to run
> > > tegrarcm on a fused system without keyfile.
> > >
> > > Command syntax:
> > >  $ ./tegrarcm --ml_rcm <ml_rcm_blob> --pkc <keyfile>
> > >
> > > Example:
> > > 1. connect usb cable to recovery mode usb port 2. put target in
> > > recovery mode 3. run command as below:
> > > $ sudo ./tegrarcm --ml_rcm t124_ml_rcm.bin --pkc rsa_priv.der
> > >
> > 
> > Why this extra step to write the signed miniloader to a separate file?
> > Why not just sign the miniloader in memory when using the --signed
> > option?  It looks like this is also generating a file for the signed
> > RCM messages, which should just be done in memory as well like we do
> > when using CMAC signing.
> > 
> This is for production purpose for fused board. User can run this step to generate all signed blobs
> from a secured server. On production server, assuming non secured, user uses previous signed
> blobs to download flasher on fused board. By doing so, we can avoid to send rsa keyfile to
> production server.

I don't like how this makes people jump through hoops to use this
feature. Couldn't we instead implement infrastructure for both
workflows?

For example, the standard behaviour could be to sign everything in
memory, which would allow developers to use this in the most
straightforward way. A command-line option could be added to switch
into "production" mode, where the necessary files are generated and
later used, which would allow the kind of setup that you describe
where the signing and flashing machines are separate.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]