linux-kernel - Re: [PATCH v7u1 22/31] x86, boot: add fields to support load bzImage and ramdisk above 4G

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]

Message-ID: <CAE9FiQUz6t_hK11X9ra5pj2DwJsNCu=cZJ7TYGR1ry-rvwSmjg@mail.gmail.com>
Date:	Tue, 15 Jan 2013 10:43:38 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Borislav Petkov <bp@...en8.de>, Yinghai Lu <yinghai@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jan Kiszka <jan.kiszka@....de>,
	Jason Wessel <jason.wessel@...driver.com>,
	linux-kernel@...r.kernel.org, Rob Landley <rob@...dley.net>,
	Matt Fleming <matt.fleming@...el.com>,
	Gokul Caushik <caushik1@...il.com>,
	Josh Triplett <josh@...htriplett.org>,
	Joe Millenbach <jmillenbach@...il.com>
Subject: Re: [PATCH v7u1 22/31] x86, boot: add fields to support load bzImage
 and ramdisk above 4G

On Tue, Jan 15, 2013 at 8:48 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Tue, Jan 15, 2013 at 08:03:49AM -0800, Yinghai Lu wrote:
>> Come on, are you serious? almost none?
>
> Of course I'm serious - the fact that I'm diddling with your patchset
> for weeks now should tell you I'm f*cking serious about this.
>
>> I took the comments about sentinel.
>> but did not take your comments about change kernel_ident_mapping_init.
>
> Because... ? I saw that you didn't take it but why, you didn't even say
> why you didn't take it. And I asked you at the beginning: should we
> review this patchset or do you simply ignore comments.

No, I didn't.

I only change lines according to the response that i could understand
and i think that is right.

>
> Let's see:
>
> * [PATCH 06/31] x86, 64bit, realmode: use init_level4_pgt to set trapmoline_pgt directly
>         - typo still there

are you looking wrong place?

http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=fd6da054a055aea9cf265a005563073ada6e1af0

 x86, 64bit, realmode: Use init_level4_pgt to set trapmoline_pgd directly
author	Yinghai Lu <yinghai@...nel.org>	
	Tue, 15 Jan 2013 05:11:07 +0000 (21:11 -0800)
committer	Yinghai Lu <yinghai@...nel.org>	
	Tue, 15 Jan 2013 05:11:07 +0000 (21:11 -0800)
with #PF handler way to set early page table, level3_ident will go away with
64bit native path.

So just use entries in init_level4_pgt to set them in tramopline_pgd


>
> * [PATCH 08/31] x86, 64bit: early #PF handler set page table
>         - almost no changes, SOB chain still wrong

HPA and I have explained that to you.

http://lkml.org/lkml/2013/1/12/115

>
> * [PATCH 12/31] x86: add get_ramdisk_image/size()
>        - no change

I respond: will insert other lines between them.

>
> * [PATCH 13/31] x86, boot: add get_cmd_line_ptr()
>         - no change

same above

>
> * [PATCH 14/31] x86, boot: move checking of cmd_line_ptr out of common path
>         - no change

same above

>
> * [PATCH 20/31] x86, kexec: replace ident_mapping_init and init_level4_page
>         - no change

https://patchwork.kernel.org/patch/1930741/

I pointed you about the grammar. ...

>
> * [PATCH 21/31] x86, kexec: only set ident mapping for ram.
>         - almost

almost what?

https://lkml.org/lkml/2013/1/14/325

I said I would  not add commit it for that.

>
> * [PATCH 22/31] x86, boot: add fields to support load bzImage and ramdisk above 4G
>         - except sentinel, almost no change

?

>
> * [PATCH 23/31] x86, boot: update comments about entries for 64bit image
>         - almost no change

I explained that i copied that from 32bit, and if you want to change
with 32bit need to do that later.

>
> How's that for "almost none"?!
>
> Oh, and also, some of the suggestions you've taken but then changed
> again making them wrong. Here's an example:
>
> Your initial change had:
>
>> +The memory for struct boot_params should be allocated under or above
>> +4G and initialized to all zero.
>
> I suggested:
>
> "Memory for struct boot_params may be allocated anywhere (even above
> 4G). This memory must be zeroed out."
>
> You changed it to:
>
> "The memory for struct boot_params could be allocated anywhere (even
> above 4G) and initialized to all zero."
>
> which still reads funny and has a couple of issues.

did not see anything wrong.
--
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/