linux-kernel - Re: 2.6.33-rc1 Reboot right after bootloader

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 13:38:47 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Johannes Stezenbach <js@...21.net>
CC:	Sam Ravnborg <sam@...nborg.org>,
	Michael Guntsche <mike@...loops.com>,
	Oliver Hartkopp <oliver@...tkopp.net>,
	linux-kernel <linux-kernel@...r.kernel.org>, mmarek@...e.cz
Subject: Re: 2.6.33-rc1 Reboot right after bootloader

Johannes Stezenbach wrote:
> On Sun, Dec 20, 2009 at 09:46:56AM +0100, Sam Ravnborg wrote:
>> On Sun, Dec 20, 2009 at 12:34:57AM +0100, Michael Guntsche wrote:
>>> I took me some time but I tracked down my reboot problem. The culprit is
>>> commit 
>>>
>>> 4a2ff67c88211026afcbdbc190c13f705dae1b59: kbuild: fix bzImage build for
>>> x86
>> Just to check what is going wrong here could you try to execute the following two commands:
>> printf \\xa8\\x51\\x37\\x00 > x ; hexdump x
>> /usr/bin/printf \\xa8\\x51\\x37\\x00 > x ; hexdump x
>> echo -ne \\xa8\\x51\\x37\\x00 > x ; hexdump x
>>
>> Please try as above and also with full path to printf (/usr/bin/printf)
> 
> Debian dash has a built-in printf which doesn't support \x.
> /usr/bin/printf works fine.

So it looks like I was wrong with the last patch here.
I changed `/bin/echo -ne' to printf.  And while it worked
for me at that time, apparently it does not work for others.

Now I wonder why it worked for me.  I can confirm that
in current debian testing (dash-0.5.5.1-3) and in debian
stable (dash-0.5.4-12) dash's built-in printf does not
interpret \x escape sequence.  I sure verified the fix
I proposed, rebuilding kernels in a freshly-installed
debian testing with /bin/sh pointing to dash.  I'll try
to investigate this.  (Side note: since the time this
issue first hit me, I carry 4a2ff67c88211026afcbdbc190c13f705dae1b59
locally.)

It is even more interesting.  I re-read POSIX description
of printf, see
http://www.opengroup.org/onlinepubs/000095399/utilities/printf.html
And this one, too, does NOT mention \x at all.  Printf is
still "better" than echo because for echo _no_ interpretation
of escape sequences is mandated -- see
http://www.opengroup.org/onlinepubs/000095399/utilities/echo.html
but that does not help much since for printf, while \-sequences
are mandated, particular \x is not, so \x is a {GNU|common sense|...}
extension.

What the...

So now I don't know what to do.  According to the standard, there's
no utility that will work here. ;)  Maybe the attached (together
with 4a2ff67c88211026afcbdbc190c13f705dae1b59) will make everyone happy?

/mjt

View attachment "use-printf-octal.diff" of type "text/x-patch" (424 bytes)