linux-kernel - Re: [patches] [PATCH] [18/19] x86_64: Overlapping program headers in physical addr space fix

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: <20061023144145.GB15532@in.ibm.com>
Date:	Mon, 23 Oct 2006 10:41:45 -0400
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Jan Beulich <jbeulich@...ell.com>
Cc:	Andi Kleen <ak@...e.de>, Magnus Damm <magnus@...inux.co.jp>,
	linux-kernel@...r.kernel.org, patches@...-64.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Ian.Campbell@...Source.com
Subject: Re: [patches] [PATCH] [18/19] x86_64: Overlapping program headers in physical addr space fix

On Mon, Oct 23, 2006 at 08:20:38AM +0100, Jan Beulich wrote:
> >@@ -17,6 +17,7 @@ PHDRS {
> > 	text PT_LOAD FLAGS(5);	/* R_E */
> > 	data PT_LOAD FLAGS(7);	/* RWE */
> > 	user PT_LOAD FLAGS(7);	/* RWE */
> >+	data.init PT_LOAD FLAGS(7);	/* RWE */
> > 	note PT_NOTE FLAGS(4);	/* R__ */
> > }
> > SECTIONS
> 
> Even though it's only cosmetic, I think it would have been
> more than appropriate to remove the ill 'E' permission on data
> with that change.

May be. I just kept it because already data segment had 'E' permissions.
Ian, any reason why did you keep 'E' on data segment? If it is not
intentional, I will get rid of it.

>(Btw., why does 'note' need 'R'?)

I went through the comments Ian had put in his patch. There also he 
mentions that people objected to 'R' permissions for note segment as
it is read only by boot loader. He kept it because i386 had the similar
thing. 

Ian, again if there is no specific reason to keep 'R' for note, I will
get rid of it.

> Also, I
> consider the naming of the new segment misleading - just 'init'
> would have been more correct.
> 

I think plain "init" also does not reflect the correct name as this section
is also mapping .data.init_task, .data.page_aligned and .data_nosave, which
will probably never get freed. It maps smp alternatives sections which will
not be freed if CPU_HOTPLUG is enabled. It also maps .bss, which will never
get freed.

I think, the sections which are not being freed, should be moved up and
made part of 'data' segment. Then create a segment 'init' for all the init
text/data and finally create another segment say 'bss' to map bss at the
end. How does this sound?

Thanks
Vivek

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