[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 12/01/18 11:23, Jan Beulich wrote:
>>>> On 11.01.18 at 15:17, <andrew.cooper3@xxxxxxxxxx> wrote:
>> c/s 1308f0170c merged .init.text and .init.data, because EFI might properly
>> write-protect r/o sections.
>> However, this change makes xen-syms unusable for disassembly analysis.  In
>> particular, searching for indirect branches as part of the SP2/Spectre
>> mitigation series.
>> Revert the relevent bits of 1308f0170c and instead modify the EFI relocation
>> code to disable CR0.WP, which is how we deal with relocations in r/o mappings
>> elsewhere.
> Doing so is a hack, and I dislike spreading hacks without real need.

Its a bona-fide feature of the x86 architecture.

> What's wrong with there being some garbage in the disassembly
> of .init?

`objdump -d xen-syms | grep \*` gives you a huge quantity of data
interpreted as x86 opcode, including the init stringtable.

This isn't the first time I've problems using xen-syms, but it is
definitely a blocker to reasonable development of the SP2 mitigation series.

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.