dbus communication error: "call to CreateConnection returned a NULL GUnixFDList"

[tobuh]

This seems somehow related to dbus communication. I have no further idea how to solve this. Maybe someone could give me a hint?

The core error is this on the TSS application side:
** (process:5017): CRITICAL **: 02:42:48.649: call to CreateConnection returned a NULL GUnixFDList WARNING:tcti:src/tss2-tcti/tctildr.c:79:tcti_from_init() TCTI init for function 0x7fbe05fc98 failed with a0008

You can find attached my snapcraft.yaml's and detailed log.

Kernel version: 4.19.127-rt55
Architecture: arm64
OS: Ubuntu Core 18

Some general questions:

• Regarding my kernel version, should I better go with /dev/tpmrm0? I consider using this instead of abrmd ...
• Then, how to make TSS "sticky" to tpmrm0, avoiding usage of /dev/tpm0?

Thanks for your help!

log_tpm2-abrmd.txt
log_tss-app.txt
snapcraft.abrmd.yaml.txt
snapcraft.yaml.tss-app.txt

[williamcroberts]

This seems somehow related to dbus communication. I have no further idea how to solve this. Maybe someone could give me a hint?

The core error is this on the TSS application side:
** (process:5017): CRITICAL **: 02:42:48.649: call to CreateConnection returned a NULL GUnixFDList WARNING:tcti:src/tss2-tcti/tctildr.c:79:tcti_from_init() TCTI init for function 0x7fbe05fc98 failed with a0008

You can find attached my snapcraft.yaml's and detailed log.

Kernel version: 4.19.127-rt55
Architecture: arm64
OS: Ubuntu Core 18

Some general questions:

• Regarding my kernel version, should I better go with /dev/tpmrm0? I consider using this instead of abrmd ...

Theirs issues there, like resource leaks that exhaust the TPM as well as not being able to support extended sessions for tpm2-tools. So its a good option, but it's not perfect either.

• Then, how to make TSS "sticky" to tpmrm0, avoiding usage of /dev/tpm0?

Generally things will probe for an available TCTI and if it tries the device tcti, the default is for /dev/tpmrm0. For each program their is an option to explicitly set the TCTI. So if you do device:/dev/tpmrm0 it will choose it. For tpm2-tools, you can use the --tcti option or the TPM2_TOOLSTCTI env variable, see: https://github.com/tpm2-software/tpm2-tools/blob/master/man/common/tcti.md

You can also symlink the default tcti to the tcti you want, but it will use default parameters. See: https://github.com/tpm2-software/tpm2-tss/blob/master/man/Tss2_TctiLdr_Initialize.3.in#L58 for details.

Thanks for your help!

log_tpm2-abrmd.txt
log_tss-app.txt
snapcraft.abrmd.yaml.txt
snapcraft.yaml.tss-app.txt

[tobuh]

• Regarding my kernel version, should I better go with /dev/tpmrm0? I consider using this instead of abrmd ...

Theirs issues there, like resource leaks that exhaust the TPM as well as not being able to support extended sessions for tpm2-tools. So its a good option, but it's not perfect either.

So it is still a better idea to go with tpm2-abrmd for productive use.

Any idea on the error on the dbus?

[williamcroberts]

Im not sure exactly whats going on, becuase it appears that tpm2-abrmd is starting and connecting to /dev/tpm0 properly, and clients are able to connect:

tpm2-abrmd[4691]: connection_set_property: set transient_handle_map
tpm2-abrmd[4691]: Created connection with client FD: 10 and id: 0x4e364ec8bda7c030
tpm2-abrmd[4691]: command_source_on_new_connection: adding new connection
tpm2-abrmd[4691]: command_source_on_input_ready
tpm2-abrmd[4691]: read_data: reading 10 bytes from istream
tpm2-abrmd[4691]: read produced EOF
tpm2-abrmd[4691]: read_tpm_buffer_alloc: err_out freeing buffer
tpm2-abrmd[4691]: command_source_on_input_ready: removing connection from connection_manager
tpm2-abrmd[4691]: connection_manager_remove: removing Connection
tpm2-abrmd[4691]: sink_enqueue
tpm2-abrmd[4691]: resource_manager_

That abrmd snippet shows a client connecting and tpm2-abrmd reading a command header. Can you run tpm2-abrmd with the env variable of G_MESSAGES_DEBUG=all and post the response?

[tobuh]

😑 😩 😖

Sorry, should have tested "devmode" before. 🤦‍♂️ 🤦‍♂️ 🤦‍♂️ It is working in devmode, generally. It must be some snap interface (aka AppArmor) related issue. I guess I do not only need dbus interface, but an interface for related the unix sockets.

Thanks anyway!!

btw: it was already output with G_MESSAGES_DEBUG=all

[williamcroberts]

Sorry, should have tested "devmode" before. It is working in devmode, generally. It must be some snap interface (aka AppArmor) related issue. I guess I do not only need dbus interface, but an interface for related the unix sockets.

Ahh yes, you need to be able to receive the sockets for communication. Dbus is just used for setting up the socket connection for sending and receiving command and response buffers.

Thanks anyway!!

btw: it was already output with G_MESSAGES_DEBUG=all

+1
I was gonna ask if you has any LSM enabled.

[tobuh]

Please @williamcroberts, could you give me some more information about the socket mechanism? I'm not very familiar with GSockets as far as I dived into the code.

As far as I understand, abrmd uses unnamed unix socket (via socketpair()), not represented by files? What does abrmd with tss application exactly share by dbus? Is it something like /proc/$pid/fd/$fd? Or does the GSocket produce some binding (as file or abstract)?

Background: I need to connect the abrmd with tss app via Ubuntu snapd interfaces. I'm not sure if it supports unnamed sockets. But it does support abstract sockets and file based sockets.

[williamcroberts]

Please @williamcroberts, could you give me some more information about the socket mechanism? I'm not very familiar with GSockets as far as I dived into the code.

As far as I understand, abrmd uses unnamed unix socket (via socketpair()), not represented by files? What does abrmd with tss application exactly share by dbus? Is it something like /proc/$pid/fd/$fd? Or does the GSocket produce some binding (as file or abstract)?

I am pretty sure they are unix dgram sockets, looking at the selinux policy:
allow tabrmd_t self:unix_dgram_socket { create_socket_perms };