From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, Rob Landley <rob@landley.net>,
Matt Fleming <matt.fleming@intel.com>
Subject: Re: [PATCH v3 11/12] x86, boot: add fields to support load bzImage and ramdisk high
Date: Sat, 24 Nov 2012 04:37:12 -0800 [thread overview]
Message-ID: <87haofi3d3.fsf@xmission.com> (raw)
In-Reply-To: <50AE70E7.6060204@zytor.com> (H. Peter Anvin's message of "Thu, 22 Nov 2012 10:37:27 -0800")
"H. Peter Anvin" <hpa@zytor.com> writes:
> On 11/22/2012 10:28 AM, Yinghai Lu wrote:
>>
>> has problem with old kexec, it only copy header from bzImage include
>> setup_header as boot_param.
>>
>
> How old are we talking here? This is a clear and blatant bug, and it would
> affect a whole bunch of things, not just this. In fact, one really has to
> wonder how it can work at all.
>
> One option I guess would be to have a sentinel field which, if it is not zero,
> causes the kernel to zero all of struct setup_info outside of
> setup_header... however, I have a nasty suspicion that this kexec botch might be
> initializing some fields and leaving others unmodified, which basically means
> "there is no hope for sanity and it is just working by pure accident."
>
> Eric, do you have any insight here?
I seem to be missing something.
With respect to boot parameters when we are booting a bzImage
/sbin/kexec initializes the boot parameters with all of the 16bit real
mode code. aka (setup_sects + 1) * 512 bytes.
I remember adding that as soon as we started having to deal with
pre-initialized fields in boot_params.
I don't have a clue what you folks are referring to as a bug.
Looking I see this verbage in boot.txt
> For machine with some new BIOS other than legacy BIOS, such as EFI,
> LinuxBIOS, etc, and kexec, the 16-bit real mode setup code in kernel
> based on legacy BIOS can not be used, so a 32-bit boot protocol needs
> to be defined.
>
> In 32-bit boot protocol, the first step in loading a Linux kernel
> should be to setup the boot parameters (struct boot_params,
> traditionally known as "zero page"). The memory for struct boot_params
> should be allocated and initialized to all zero. Then the setup header
> from offset 0x01f1 of kernel image on should be loaded into struct
> boot_params and examined. The end of setup header can be calculated as
> follow:
>
> 0x0202 + byte value at offset 0x0201
>
> In addition to read/modify/write the setup header of the struct
> boot_params as that of 16-bit boot protocol, the boot loader should
> also fill the additional fields of the struct boot_params as that
> described in zero-page.txt.
Certainly /sbin/kexec isn't bothering to calculate the end of the setup
header and just being far more conservative and using all of the 16bit
real mode code as it's initializer.
Eric
next prev parent reply other threads:[~2012-11-24 12:37 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 7:15 [PATCH v3 00/12] x86, boot, 64bit: Add support for loading ramdisk and bzImage high Yinghai Lu
2012-11-21 7:15 ` [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200 Yinghai Lu
2012-11-21 17:23 ` H. Peter Anvin
2012-11-21 19:45 ` Yinghai Lu
2012-11-21 19:50 ` H. Peter Anvin
2012-11-21 20:15 ` Yinghai Lu
2012-11-22 5:48 ` Eric W. Biederman
[not found] ` <3178cb29-0e9e-44d2-b21f-45c53f38980a@email.android.com>
2012-11-22 11:27 ` Eric W. Biederman
2012-11-24 7:00 ` Yinghai Lu
2012-11-21 7:16 ` [PATCH v3 02/12] x86, boot: Move lldt/ltr out of 64bit code section Yinghai Lu
2012-11-21 7:16 ` [PATCH v3 03/12] x86, 64bit: set extra ident page table for whole kernel range Yinghai Lu
2012-11-21 7:16 ` [PATCH v3 04/12] x86, 64bit: add support for loading kernel above 512G Yinghai Lu
2012-11-21 7:16 ` [PATCH v3 05/12] x86: Merge early_reserve_initrd for 32bit and 64bit Yinghai Lu
2012-11-21 7:40 ` Pekka Enberg
2012-11-21 7:16 ` [PATCH v3 06/12] x86: add get_ramdisk_image/size Yinghai Lu
2012-11-21 7:16 ` [PATCH v3 07/12] x86, boot: add get_cmd_line_ptr() Yinghai Lu
2012-11-21 7:16 ` [PATCH v3 08/12] x86, boot: Don't check if cmd_line_ptr is accessible in misc/decompressor() Yinghai Lu
2012-11-21 17:21 ` H. Peter Anvin
2012-11-21 19:18 ` Yinghai Lu
2012-11-21 7:16 ` [PATCH v3 09/12] x86, boot: update cmd_line_ptr to unsigned long Yinghai Lu
2012-11-21 7:16 ` [PATCH v3 10/12] x86: use io_remap to access real_mode_data Yinghai Lu
2012-11-21 7:16 ` [PATCH v3 11/12] x86, boot: add fields to support load bzImage and ramdisk high Yinghai Lu
2012-11-21 17:17 ` H. Peter Anvin
2012-11-21 18:59 ` Yinghai Lu
2012-11-21 19:18 ` H. Peter Anvin
2012-11-22 5:56 ` Yinghai Lu
[not found] ` <a1ca794a-09d4-4d36-8c8c-67100cb3696e@email.android.com>
2012-11-22 6:47 ` Yinghai Lu
2012-11-22 6:58 ` Yinghai Lu
2012-11-22 15:59 ` H. Peter Anvin
2012-11-22 18:28 ` Yinghai Lu
2012-11-22 18:37 ` H. Peter Anvin
2012-11-22 18:50 ` Yinghai Lu
2012-11-22 18:51 ` H. Peter Anvin
2012-11-22 20:18 ` Yinghai Lu
2012-11-22 20:20 ` H. Peter Anvin
2012-11-22 20:29 ` Yinghai Lu
2012-11-22 20:50 ` H. Peter Anvin
2012-11-22 21:02 ` H. Peter Anvin
2012-11-22 22:13 ` Yinghai Lu
2012-11-24 12:37 ` Eric W. Biederman [this message]
2012-11-24 17:32 ` H. Peter Anvin
[not found] ` <CAE9FiQV0Q0fi7TrNjihdsUt0ueT4LLON4o+JEmX6ry9S6AU-ug@mail.gmail.com>
2012-11-24 18:24 ` H. Peter Anvin
2012-11-24 19:50 ` H. Peter Anvin
2012-11-24 21:30 ` Yinghai Lu
2012-11-24 21:38 ` H. Peter Anvin
2012-11-24 22:18 ` Yinghai Lu
2012-11-24 22:32 ` H. Peter Anvin
2012-11-24 23:24 ` Yinghai Lu
2012-11-24 23:50 ` Eric W. Biederman
2012-11-25 0:04 ` H. Peter Anvin
2012-11-25 0:11 ` Yinghai Lu
2012-11-25 5:50 ` Yinghai Lu
2012-11-25 5:52 ` H. Peter Anvin
2012-11-25 6:09 ` Yinghai Lu
2012-11-25 0:04 ` Yinghai Lu
2012-11-25 0:06 ` H. Peter Anvin
2012-11-21 7:16 ` [PATCH v3 12/12] x86: remove 1024g limitation for kexec buffer on 64bit Yinghai Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87haofi3d3.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mingo@elte.hu \
--cc=rob@landley.net \
--cc=tglx@linutronix.de \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).