Re: [XEN PATCH] tools/xenstore: Log xenstored build ID on startup

[Bjoern Doebel <doebel@xxxxxxxxx>]

On 13.11.20 18:23, Edwin Torok wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
>
>
>
> On Fri, 2020-11-13 at 17:13 +0000, Andrew Cooper wrote:
> > On 13/11/2020 16:56, Bjoern Doebel wrote:
> > > On 13.11.20 16:36, Jürgen Groß wrote:
> > > > On 13.11.20 15:18, Bjoern Doebel wrote:
> > > > > Right now we do not have a mechanism to determine the version
> > > > > of the
> > > > > currently running xenstored at runtime. As xenstored runs
> > > > > throughout
> > > > > the
> > > > > lifetime of a Xen host, this may lead to problems when newer
> > > > > user space
> > > > > builds are staged. Then, the running xenstored will no longer
> > > > > match the
> > > > > version of the installed xenstored.
> > > > >
> > > > > To allow users to always identify the running version of
> > > > > xenstored, add
> > > > > a linker-generated unique build ID to every xenstored build.
> > > > > Add
> > > > > functionality to log this build ID into a file upon service
> > > > > startup.
> > > > >
> > > > > Signed-off-by: Bjoern Doebel <doebel@xxxxxxxxx>
> > > > > Reviewed-by: Martin Mazein <amazein@xxxxxxxxx>
> > > > > Reviewed-by: Paul Durrant <pdurrant@xxxxxxxxxxxx>
> > > > No support for oxenstored or xenstore-stubdom?
> > > Your suggestion further down will apparently help for stubdom. I do
> > > not speak ocaml at all - how do we address this?
> > CC'ing Edwin and Christian who have done the bulk of the oxenstored
> > recently.
> >
> > It sounds like it might not be possible right now, but would be
> > possible
> > with a future plan to switch the Ocaml build system over to dune (the
> > new/preferred Ocaml upstream toolchain).
> See here what is possible with Dune:
> https://dune.readthedocs.io/en/stable/dune-libs.html#build-info
>
> Would the output of 'git describe --always --dirty' (perhaps combined
> with a build date) serve as a useful build ID?
The point of the build ID is to verify something like 
"binary-equivalence" of two builds.
* a git hash is not sufficient because different git hashes may result 
in the same binary to be created (i.e., if there is no code change in 
the target binary in between those two builds)
* a time stamp is counter-productive, because then you'd have to 
recreate this timestamp every time you want to re-create a build
GNU ld's --build-id claims to perform a checksumming of the "normative 
parts of the output contents". Whatever that means. ;)
> > If it does end up being an XS_CONTROL sub-op, we can implement it at
> > a
> > future point when we can usefully answer the question.
> Wouldn't using readelf on /proc/<pid>/exe give you the running buildid?
>
> readelf -a /usr/sbin/oxenstored /proc/$(pidof oxenstored)/exe | grep
> 'Build ID'
>      Build ID: bdd5304c8984ed22570d51308ae8717d03fe60ae
>      Build ID: bdd5304c8984ed22570d51308ae8717d03fe60ae
>
> readelf -a /usr/sbin/oxenstored /proc/$(pidof oxenstored)/exe | grep
> 'Build ID'
>      Build ID: b44ff99b216db7526e3ee7841068d584cc9c2b95
>      Build ID: bdd5304c8984ed22570d51308ae8717d03fe60ae
>
>
> When you're inside a stubdom it is probably not so easy though.
Interesting. I had not considered that because after upgrading xenstored 
to a different version, the running xenstored's /proc/$PID/exe shows as
# ls -l /proc/$(pgrep xenstored)/exe
lrwxrwxrwx 1 root root 0 Nov  9 14:06 /proc/3528/exe -> 
/usr/sbin/xenstored (deleted)
But you are right, one can still read that procfs file. Nice!


Bjoern





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879