[Xen-devel] [RFC] PV guest kernel address randomization

["Jan Beulich" <JBeulich@xxxxxxxx>]

All,

Linux, at least for some arches, has been doing this for a while, yet
the way it's implemented means kernels running in PV Xen guests
can't leverage that functionality. Obviously the whole relocation
process could be carried out in the guest, but it seems like Xen (for
Dom0) or libxc (for DomU) are in much a better position to do at least
the initial placement right at a randomized address. That's what the
attached patch attempts to implement (which appears to be working
fine from the limited testing I can do without a full Linux side
implementation) via two new ELF notes; the other attached patch is
a mechanical prereq, just for reference.

The more interesting question is that of who to have do the
necessary relocations. Native Linux derives a custom format table
from the ELF binary, which it attaches to the end of the ELF image.
Having Xen consume such a custom format (which may change)
doesn't seem like a good idea. It being attached to the end also
means that it won't get loaded by the domain loaders, so for it to
become consumable by the guest kernel it would need to be made
part of the actual ELF image (as e.g. a new section).

The alternative I see would be to require full symbol tables and
relocation sections to be retained in the ELF binary, in which case
Xen / libxc could do the relocations, and no guest OS changes
beyond the respective build logic adjustment and the addition of
the ELF notes would be necessary.

Keeping in mind history, either guest adjustment may be a difficult
sell to Linux maintainers. How would other OSes (e.g. the BSDs)
view this? Do people have preferences either way, or other
suggestions (other than "PV is almost dead, let's not touch it")?

Jan

Attachment: libelf-generalize-store-field.patch
Description: Text document

Attachment: libelf-randomize-base.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel