varlink: add introspection support + varlinkctl + varlinkify one first command line tool (systemd-pcrextend)

[poettering]

This beefs up our Varlink game: it adds support for Varlink introspection to our codebase, i.e. this stuff: https://varlink.org/Service

Introspection matters as we make our Varlink services more accessible ourside of systemd.

A new tool "varlinkctl" is added for interfacing with Varlink services. It's really nice any easy to use, for example:

$ varlinkctl info /run/systemd/resolve/io.systemd.Resolve

will introspect what the Varlink service behind the /run/systemd/resolve/io.systemd.Resolve socket provides. Equally nice:

# varlinkctl info /usr/lib/systemd/systemd-pcrextend

to see what Varlink interfaces the specified binary offers.

This also adds some glue to make it very easy to add Varlink APIs to command line tools, and then does that to systemd-pcrextend, making an IPC API available that allows measuring arbitrary strings to a TPM2 PCR, with an event log record associated with it.

[DaanDeMeyer]

So I eventually want to hook up mkosi to a socket like this as well. Preferably I wouldn't have to pull in a python wrapper of libvarlink to be able to do so. Is there any way we can put the varlink bits of this in the socket unit itself and have --varlink instruct the binary to read a JSON object directly from stdin which comes from varlink? That makes this accessible to many more tools without requiring all those tools to pull in a varlink library.

[poettering]

I don't follow?

[poettering]

(there's a native python varlink module btw. given how trivial varlink actually is it's generally a better idea to use a native library for each language rather than wrapping systemd's C version)

[DaanDeMeyer]

I still find varlink annoying to pull in as a dep, it means I have to make sure it is packaged in all distributions, keep track of updates, it feels messy to require each tool to implement this independently. It would be much nicer if I just had to handle JSON and could leave the varlink bits to systemd. What would be much nicer is if systemd shipped a helper tool that does the varlink specific bits which then just calls the actual tool, passing the input as a JSON object on stdin. Then all I need is to parse JSON, which is much more trivial than having to do varlink stuff, which most people have never heard of.

[DaanDeMeyer]

Actually, thinking more about it, such a tool can be implemented independently anyway. Our tools can do varlink directly, and tools that can't do it directly could use such a wrapper tool to expose themselves over varlink. But such a wrapper tool can be added later

[poettering]

I still find varlink annoying to pull in as a dep, it means I have to make sure it is packaged in all distributions, keep track of updates, it feels messy to require each tool to implement this independently. It would be much nicer if I just had to handle JSON and could leave the varlink bits to systemd. What would be much nicer is if systemd shipped a helper tool that does the varlink specific bits which then just calls the actual tool, passing the input as a JSON object on stdin. Then all I need is to parse JSON, which is much more trivial than having to do varlink stuff, which most people have never heard of.

varlink is just json, check the spec. it's trivial to reimplement: the method call ist just a json object followed by a single NUL byte, and the response is too. That is the whole protocol.

So if you just want to do json in mkosi, that's entirely fine, but you really don't need varlinkctl for that.

What varlinkctl gives you is introspection, syntax highlighting and stuff. But you don't need any of this for basic varlink.

[bluca]

The varlink python library is already in fedora, I'll make it available in debian/ubuntu too

[evverx]

@mrc0mmand looks like it should close #23874 too. I haven't taken a close look yet but it seems with this PR included it should be possible to introspect the systemd services. I'm not sure how to get the list of all the services automatically (apart from looking for the *.io files or hard-coding them)

varlinkctl info /run/systemd/resolve/io.systemd.Resolve
    Vendor: The systemd Project
   Product: systemd (systemd-resolved)
   Version: 254 (254-1250-g1cf432d)
   Version: https://systemd.io/
Interfaces: io.systemd
            io.systemd.Resolve
            org.varlink.service
=================================================================
==10239==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c0000000ab at pc 0x7f13c5926dac bp 0x7fffdf3c2c90 sp 0x7fffdf3c2c88
READ of size 1 at 0x60c0000000ab thread T0
    #0 0x7f13c5926dab in json_variant_unref ../src/shared/json.c:864
    #1 0x4032f9 in json_variant_unrefp ../src/shared/json.h:96
    #2 0x405aff in verb_info ../src/varlinkctl/varlinkctl.c:201
    #3 0x7f13c5b358a0 in dispatch_verb ../src/shared/verbs.c:170
    #4 0x4089ab in varlinkctl_main ../src/varlinkctl/varlinkctl.c:502
    #5 0x4089f1 in run ../src/varlinkctl/varlinkctl.c:514
    #6 0x408aad in main ../src/varlinkctl/varlinkctl.c:518
    #7 0x7f13c4a49b89 in __libc_start_call_main (/lib64/libc.so.6+0x27b89) (BuildId: c9f62793b9e886eb1b95077d4f26fe2b4aa1ac25)
    #8 0x7f13c4a49c4a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c4a) (BuildId: c9f62793b9e886eb1b95077d4f26fe2b4aa1ac25)
    #9 0x4025c4 in _start (/home/vagrant/systemd/build/varlinkctl+0x4025c4) (BuildId: 7db282c724ffc0f72d298f583db879607c84339b)

0x60c0000000ab is located 107 bytes inside of 120-byte region [0x60c000000040,0x60c0000000b8)
freed by thread T0 here:
    #0 0x7f13c70d7fb8 in __interceptor_free.part.0 (/lib64/libasan.so.8+0xd7fb8) (BuildId: e5f0a0d511a659fbc47bf41072869139cb2db47f)
    #1 0x7f13c5926f8b in json_variant_unref ../src/shared/json.c:872
    #2 0x7f13c5af1159 in varlink_clear_current ../src/shared/varlink.c:595
    #3 0x7f13c5af166f in varlink_clear ../src/shared/varlink.c:610
    #4 0x7f13c5af2b21 in varlink_destroy ../src/shared/varlink.c:645
    #5 0x7f13c5af2f75 in varlink_unref ../src/shared/varlink.c:651
    #6 0x40399e in varlink_unrefp ../src/shared/varlink.h:196
    #7 0x405af0 in verb_info ../src/varlinkctl/varlinkctl.c:202
    #8 0x7f13c5b358a0 in dispatch_verb ../src/shared/verbs.c:170
    #9 0x4089ab in varlinkctl_main ../src/varlinkctl/varlinkctl.c:502
    #10 0x4089f1 in run ../src/varlinkctl/varlinkctl.c:514
    #11 0x408aad in main ../src/varlinkctl/varlinkctl.c:518
    #12 0x7f13c4a49b89 in __libc_start_call_main (/lib64/libc.so.6+0x27b89) (BuildId: c9f62793b9e886eb1b95077d4f26fe2b4aa1ac25)

[DaanDeMeyer]

I guess we won't have a way to get the name of the unit spawned by varlinkctl call so we can tail logs or so?

[poettering]

I guess we won't have a way to get the name of the unit spawned by varlinkctl call so we can tail logs or so?

Actually that should be easily implementable. If the client enables SO_PASSCRED on its side, then it will get SCM_CREDENTIALS metadata for everything the server sends, revealing its identity.

[poettering]

I'm not sure how to get the list of all the services automatically (apart from looking for the *.io files or hard-coding them)

test-varlink-idl spits them all out (but does some other things too).

We probably should install them as .varlink files or so. i.e. generate them on developer machines automatically from the C definitions, then commit them to git (so that we have no cross-building issues) and install them to some dir in /usr/share/varlink/interfaces/ or so. Now if my Meson-fu would be good enough to implement this nicely (i.e. generate from C tool on devel computer, but use git version otherwise)...

[evverx]

test-varlink-idl spits them all out (but does some other things too).

The idea was to implement vfuzzer (by analogy with dfuzzer) that could discover services and then fuzz them. Ideally it should be separate from systemd (and its test suite) to make it easier to point it to any varlink service so test-varlink-idl isn't an option probably. Based on my experiments find /run/systemd/ -name 'io.*' is enough to discover all the systemd services. The varlink files would probably be nicer though.