Re: [Xen-devel] [PATCH] x86/link: Don't merge .init.text and .init.data

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/01/18 16:05, Jan Beulich wrote:
>>>> On 12.01.18 at 16:41, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 12/01/18 11:23, Jan Beulich wrote:
>>> Even it you make .init.data its own section again, some
>>> garbage will remain (mainly due to the trampoline data).
>> That is far easier to spot an isolate, because it is tiny and reasonably
>> obviously bounded.
> Well, I've pointed out where the easy to spot bounding is:
>
>>>  If you
>>> care to use tools to find certain patterns in .init, simply discard
>>> everything following _einittext before giving the tool a go. IOW I
> ^^^

Perhaps easy if you're reading the disassembly, and are one half of the
Xen x86 maintainership.

I know about _einittext, but don't consider this easy, and it certainly
isn't reasonable to expect of anyone trying to use xen-syms.

>
>>> would much prefer for things to be left as they are.
>> No.  We should not be deliberately corrupting the binary to work around
>> a theoretical runtime issue for which there is a perfectly fine runtime
>> solution.  This is the real hack.
> Putting all init-time code and data in a single section is a perfectly
> valid thing to do imo.

Having our debug symbols borderline unusable, isn't valid.

Certainly not to work around what you yourself identify as a theoretical
issue in the first place.

> We don't care about permissions at that
> point in time, so the resulting RWX section is quite fine (and has a
> name much better suitable for a PE image). Otherwise the fact
> that we merge r/o and r/w init time data into a single section
> would need to be called a hack, too.

It is very much a hack.  I don't see what you're getting at.

Other option would be to #ifdef the section handing based on EFI, or
attempt to merge the sections with objcopy before passing mkreloc?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel