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

[Christian Lindig <christian.lindig@xxxxxxxxxx>]

How about keeping such an ID in xenstore itself in some kind of /meta hierarchy 
where xenstore could also keep stats? As long xenstore is running this 
information is easily accessible for outside tools.

-- C

________________________________________
From: Bjoern Doebel <doebel@xxxxxxxxx>
Sent: 16 November 2020 07:53
To: Edwin Torok; xen-devel@xxxxxxxxxxxxxxxxxxxx; jgross@xxxxxxxx; Andrew Cooper
Cc: wl@xxxxxxx; Christian Lindig; jgrall@xxxxxxxxxxxx; elnikety@xxxxxxxxx; 
iwj@xxxxxxxxxxxxxx
Subject: Re: [XEN PATCH] tools/xenstore: Log xenstored build ID on startup


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