linux-kernel - Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

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, 29 Apr 2007 09:11:52 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Jeff Garzik <jeff@...zik.org>, Andi Kleen <ak@...e.de>,
	patches@...-64.org, Vivek Goyal <vgoyal@...ibm.com>,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	virtualization <virtualization@...ts.linux-foundation.org>
Subject: Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

Jeremy Fitzhardinge <jeremy@...p.org> writes:

> Eric W. Biederman wrote:
>> All it does is set a flag that tells a bootloader.
>> "Hey. I can run when loaded a non-default address, and this is what
>>  you have to align me to."
>>
>> All relocation processing happens in the kernel itself.
>>   
>
> Is it possible to decompress and extract the kernel image from the
> bzImage without executing it?  Ie, is there enough information to find
> the compressed data part of the bzImage by inspection?
>
> At some point we'll need to change the Xen domain builder to handle
> bzImage files, and it would be best if we didn't need to run them.

/sbin/kexec bzImage ....

There is a 32bit entry point that is reasonably well specified
you can use.  I'm guessing you want to recover the 64bit ELF,
with all of your nice ELF notes etc.  vmlinux is run through
"objcopy -O binary" as part of the bzImage build process so all
of the ELF metadata is lost.

I have several ideas on how we can make this work but first I have to
ask what is it that you are trying to accomplish?

<rant>
  Right now I'm a little frustrated that insanity below slipped into
  head.S right after the 32bit entry point after the review said
  use the normal linux parameters for parameter passing.

  > #ifdef CONFIG_PARAVIRT
  >         movl %cs, %eax
  >         testl $0x3, %eax
  >         jnz startup_paravirt
  > #endif

  The whole thing should be based on a value in the linux parameter block
  pointed to by %esi, instead of the insane preserve all registers and
  attempt to be super compatible with everyone.

  Yes we do need a branch there, but no we don't need to be changing 
  the format we pass arguments to the kernel in.
</rant>

Anyway since it seems there is interest in going farther in tweaking
the linux boot process let's open thread up to what is needed/wanted
for future enhancements to linux booting, and let's see if we can
design something that works and isn't brain dead.

Eric
-
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/