linux-kernel - Re: [PATCH] kbuild: correct size calculation of bzImgae / fix x86 boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 20 Dec 2009 14:19:41 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Sam Ravnborg <sam@...nborg.org>
CC:	Michal Marek <mmarek@...e.cz>,
	Michael Guntsche <mike@...loops.com>,
	Oliver Hartkopp <oliver@...tkopp.net>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kbuild: correct size calculation of bzImgae / fix x86
 boot

Sam Ravnborg wrote:
> We use ... printf \x ... when calculating the size of the
> compressed kernel.
> Unfortunately dash built-in printf does not support this notation
> resulting in a non-bootable kernel.
> 
> Fix this by always using the external version of printf.
> 
> The commit that introduced this bug was:
> 4a2ff67c88211026afcbdbc190c13f705dae1b59: "kbuild: fix bzImage
> build for x86"

It's not that simple Sam.  This commit is a part of the game.
It works neither with printf as after my commit above, nor with
original fix with `/bin/echo -ne'.  In neither case the fix is
complete or robust.  Because there are two places in the few lines,
around this, both affected and both are non-POSIX-conformant.

> Reported-by: Michael Guntsche <mike@...loops.com>
> Cc: Oliver Hartkopp <oliver@...tkopp.net>
> Cc: Johannes Stezenbach <js@...21.net>
> Signed-off-by: Sam Ravnborg <sam@...nborg.org>
> ---
> 
> This should fix it but it would be great if it is tested.
> Michal Marek, I think this needs to go upstream pretty quickly.

This whole issue only affects debian and ubuntu for now.
But the bug is very difficult to track down, since the prob
happens on early boot.

For now, I think, the best is to ensure we're building with
bash not dash.  Ie, SHELL=/bin/bash make ... will work.
Because even with this second fix, it still does not work
correctly with dash's echo and printf behaving differently
than bash's (but still conforming to POSIX).  It produces
good kernel, or at least I don't see any obvious probs with
the resulting kernel, but at least `make V=1' output looks
all wrong in this area (since dash's echo interpret \nnn
by default and make uses echo to print commands as they're
executed).

The right fix is to eliminate all this hack altogether.
Imho anyway.

/mjt

> 	Sam
> 
>  scripts/Makefile.lib |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index cd815ac..bd201d9 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -213,13 +213,14 @@ cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
>  
>  # Bzip2 and LZMA do not include size in file... so we have to fake that;
>  # append the size as a 32-bit littleendian number as gzip does.
> +# Note: dash built-in printf does not support \x so use /usr/bin version
>  size_append = printf $(shell						\
>  dec_size=0;								\
>  for F in $1; do								\
>  	fsize=$$(stat -c "%s" $$F);					\
>  	dec_size=$$(expr $$dec_size + $$fsize);				\
>  done;									\
> -printf "%08x" $$dec_size |						\
> +/usr/bin/printf "%08x" $$dec_size |						\
>  	sed 's/\(..\)\(..\)\(..\)\(..\)/\\\\x\4\\\\x\3\\\\x\2\\\\x\1/g'	\
>  )
>  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/