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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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