linux-kernel - Re: [PATCH 2/2] x86, boot: Optimize the elf header handling.

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, 01 Jul 2012 13:40:05 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Tejun Heo <tj@...nel.org>, hacklu <embedway.linux@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86, boot: Optimize the elf header handling.

"H. Peter Anvin" <hpa@...or.com> writes:

> On 07/01/2012 12:20 PM, Eric W. Biederman wrote:
>> 
>> Grumble Grumble.
>> 
>> If I force a 2M alignment, poffsets and paddrs align and my previous
>> patches work.  Although I don't expect that to be more than a testing
>> hack.
>> 
>> Meanwhile if I force a 4K max page size for most purposes things look
>> better from a file offset perspective.  But the data segment is now less
>> aligned in the file than it is in memory and my patches don't work.
>> 
>> Sigh.
>> 
>> I feel like I have stumbled into pandoras box.
>> 
>
> Last I looked at this we didn't actually have a general PHDR parser...
> are you running into its limitations?

Sort of.  It was my premise that we should not need a general PHDR
parser, or even a parser at all , especially since a general PHDR parser
is hard to fit into the existing bzImage protocol.  So far emperically
except when dealing with the weird percpu section we don't need a 
general PHDR parser.

There is just enough weirdness that it makes sense to have a
phdr parser that just verifies it doesn't need to do anything.

So I have tracked down part of the crazyness.
CONFIG_RODATA actually uses 2MB alignment, making
-z max_page_size=4096 a bit questionable.

In practice I'm not concerned with a few extra zero's in the file
because giant runs of zeros compress very well.

I am going to play with the percpu section a bit more and see if
I can remove the need for magic to get it's p_offset and p_paddr
to be aligned in the file, as that comes for free with everything
else.

Hmm.  I think I see why the percpu section is problematic.  We have to
specify AT on all of our sections and the usual formula is
".section : AT(.section - LOAD_OFFSET)".  Unfortunately that doesn't
work when we we set the virtual address to zero.

I will play with it a little more and see if I can come up with
something interesting.

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/