[PATCH v2 00/16] efi_loader: add secure boot support

[Tom Rini <trini@konsulko.com>]

On Wed, Dec 11, 2019 at 11:10:42AM +0900, AKASHI Takahiro wrote:
> On Tue, Dec 10, 2019 at 08:54:12PM -0500, Tom Rini wrote:
> > On Wed, Dec 11, 2019 at 09:41:56AM +0900, AKASHI Takahiro wrote:
> > > Simon,
> > > 
> > > On Wed, Dec 04, 2019 at 05:28:59PM +0900, AKASHI Takahiro wrote:
> > > > On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote:
> > > > > On 12/4/19 3:43 AM, AKASHI Takahiro wrote:
> > > > > >Tom, Simon, Heinrich,
> > > > > >
> > > > > >I have submitted three major patch sets for UEFI secure boot:
> > > > > >* x509/pkcs7 parser
> > > > > >* RSA library extension
> > > > > >* UEFI secure boot
> > > > > >
> > > > > >I have no technical issues to fix now and have seen only a few minor
> > > > > >comments on them (if I confirm that you have no more comments,
> > > > > >I can submit new version almost immediately).
> > > > > >Considering those, can I expect that those patches be merged
> > > > > >in v2020.01?
> > > > > >
> > > > > >If not, do you need to have more time for your reviewing?
> > > > > >What else do you expect from my side to accelerate the upstream?
> > > > > 
> > > > > We are reaching the end of the release cycle. So do not expect any of
> > > > > these patch series to be merged in v2020.01.
> > > > > cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle
> > > > 
> > > > I have often seen several patches (not bug fix) merged
> > > > even after "merge window".
> > > > Anyway,
> > > > 
> > > > > To my understanding the UEFI secure boot series depends on the other two
> > > > > so it must be merged last.
> > > > 
> > > > So once the first two patch set are accepted by the maintainers,
> > > > do you agree to merging the third one (i.e. secure boot patch itself)
> > > > promptly?
> > > >         -> Heinrich
> > > > 
> > > > As I said, I have had no technical issues on the first two patches
> > > > and haven't heard any comments/objections from the maintainers so far.
> > > > Are you willing to accept them for the next release?
> > > >         -> Tom, Simon
> > > 
> > > Can you confirm that you have queued my "RSA library extension" patch
> > > in your -next(?) branch, please?
> > 
> > Please note that I raised a concern with the RSA patch series that needs
> > to be addressed.  There's unexplained / unexpected size growth on
> > platforms that aren't otherwise enabling new features.  Thanks!
> 
> I misunderstood your statement there.
> Questions:
> 1) How did you measure the size growth?
>    Please specify the exact command(s).
> 2) Did you use T1042RDB_PI_NAND_SECURE_BOOT_defconfig without any change?

So, I have the following script for doing size tests:
#!/bin/bash

# Initial and constant buildman args
ARGS="-devl"
ALL=0
KEEP=0

# Find our arguments
while test $# -ne 0; do
	if [ "$1" == "--all" ]; then
		ALL=1
		shift 1
	elif [ "$1" == "--branch" ]; then
		BRANCH=$2
		shift 2
	elif [ "$1" == "--keep" ]; then
		KEEP=1
		ARGS="$ARGS -k"
		shift 1
	else
		MACHINE=$1
		shift
	fi
done

if [ -z $MACHINE ]; then
	echo Usage: $0 MACHINE [--all] [--keep] [--branch BRANCH]
	exit 1
fi

# If not all, then only first/last
if [ $ALL -ne 1 ]; then
	ARGS="$ARGS --step 0"
fi

if [ ! -z $BRANCH ]; then
	ARGS="$ARGS -b $BRANCH"
else
	ARGS="$ARGS -b `git rev-parse --abbrev-ref HEAD`"
fi

mkdir -p /tmp/$MACHINE

export SOURCE_DATE_EPOCH=`date +%s`
./tools/buildman/buildman -o /tmp/$MACHINE $ARGS -SBC $MACHINE
./tools/buildman/buildman -o /tmp/$MACHINE $ARGS -SsB $MACHINE

[ $KEEP -eq 0 ] && rm -rf /tmp/$MACHINE

And yes, I applied just the series and built the world.  The
T1042RDB_PI_NAND_SECURE_BOOT_defconfig config along with a handful of
other PowerPC platforms (also of the _SECURE_BOOT variety) had the same
size growth.  I didn't bisect down to the specific commit in question at
the time.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191211/6f49addb/attachment.sig>