Re: [Xen-devel] [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Konrad Rzeszutek Wilk writes ("[PATCH v3 2/3] XENVER_build_id: Provide 
ld-embedded build-ids (v8)"):
> The mechanism to get this is via the XENVER hypercall and
> we add a new sub-command to retrieve the binary build-id
> called XENVER_build_id. The sub-hypercall parameter
> allows an arbitrary size (the buffer and len is provided
> to the hypervisor). A NULL parameter will probe the hypervisor
> for the length of the build-id.
> 
> One can also retrieve the value of the build-id by doing
> 'readelf -h xen-syms'.
> 
> For EFI builds we re-use the same build-id that the xen-syms
> was built with.
> 
> Note that there are no changes to the XSM files (dummy.c
> and hooks.c) as the privileged subops fall in the default case.
> 
> The version of ld that first implemented --build-id is v2.18.
> Hence we check for that or later version - if older version
> found we do not build the hypervisor with the build-id
> (and the return code is -ENODATA for that case).

I think this commit message is missing some important explanation for
poor ignorant souls like me.

Something like:

  It is possible to have ld record an arbitrary identifier in an ELF,
  which can then be read out with `readelf'.  We also want to provide
  a way for guests to retrieve the same identifier.

  [ xxx do we? Maybe hosting providers would want to hide which of
  their hosts had been updated ]

  We construct the build-id out of [ ???? ]

  There is ???? no impact on users who want reproducible builds [or]
  ???  users who want reproducible builds are expected to use the
  facilities documented in ??? comments in Config.mk [or something]

Ian.

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