passing a config parameter to iceoryx2-pal?

[crslzz]

Hi, I am looking for the proper way to pass a configuration parameter to iceoryx2-pal.

Directly adding a new entry to the global config in iceoryx2 doesn’t work due to the circular dependency it would create if used within iceoryx2-pal.

One alternative is reading the parameter from an environment variable, but this does not appear to be common practice, with the only existing example being IOX2_LOG_LEVEL in iceoryx2-bb.

Are there better options? Thanks!

[orecham]

Hi @crslzz, what is it that you are trying to configure in iceoryx2-pal? Could you provide an example or a description of your use-case?

[crslzz]

Hello @orecham,

On Linux, I want to make the directory for the named shared memory objects configurable.

The use case is as follows: in a system with a combination of security and safety requirements, workloads with different integrity levels execute in separate, isolated containers.

We do not want containers of different integrity levels to share the entire /dev/shm directory, along with other, non-IceOryx2 workloads. We rather want to create named shared memory objects in dedicated directories, such as /dev/shm/some-level. These directories would only be shared among containers of the same or lower integrity level.

(this also applies to /tmp/iceoryx2 but this directory is already configurable via the global config file).

This is not doable using glibc’s shm_open(). However, this function is just a wrapper around open(), meaning it can be easily re-implemented in iceoryx2-pal directly. The change would touch shm_open(), shm_unlink(), and shm_list() in posix/src/linux/mman.rs.

The simplest approach would be to use an environment variable to specify an alternative shared memory directory. If this environment variable is not set, the regular posix functions would be used.

[orecham]

@crslzz Got it, I think we have you covered.

You can pass a custom configuration for iceoryx2-pal via an environment variable as described here: https://github.com/eclipse-iceoryx/iceoryx2/blob/main/config/README.md#custom-platform-abstraction-layer-configuration
This will allow you to e.g. specify a different location for the iceoryx2 shared memory objects.

If you decide that you do want to tweak abstractions for the functions like shm_open, you are also able to pass the path to a custom POSIX abstraction implementation via environment variable as described here: https://github.com/eclipse-iceoryx/iceoryx2/blob/main/config/README.md#custom-platform-abstraction-layer-posix

Note that this currently requires building iceoryx2 with some additional feature flags, but we are looking into simplifying this (see this PR #1212).

[elfenpiff]

@crslzz This is also supported on higher level API. For instance the /tmp/iceoryx2 directory is a path hint that is provided to the iceoryx2 concept abstraction layer and if the mechanism supports the path we apply it. Since shm_open does not support paths, we ignore the path hint.

But as you said, we can also use open() directly and use a file in an in-memory tmpfs. The cleanest approach would not be to add this to the platform - this is more a hacky workaround - but to provide a iceoryx2 concept implementation for this special kind of shared memory. This would again support the path hints and then all sockets, directories, files and shared memories would be located under the configurable path /tmp/iceoryx2.

[crslzz]

Thanks for these replies. I'll process them, and then get back to you.

Does it imply that you do not oppose such a change in principle, and will not reject a PR outright?

[elfenpiff]

@crslzz I got a first version working for you, check this branch out: https://github.com/ekxide/iceoryx2/tree/iox2-1223-in-mem-shm

All shared memory constructs are backed up by a file, and if the file is inside a tmpfs in Linux, you have a shared memory object. But with a fully configurable path. When you run any example on this branch like cargo run --example publish_subscribe_publisher, you will see that no more shared memory objects are stored in /dev/shm/, but they are now all in /tmp/iceoryx2, and you configure the path as usual with the iceoryx2 configuration.

I need to clean up the code, write a little documentation, and then we can merge it. So by the end of next week, it should be fully usable for you - but now the weekend starts for me.

Need to prepare for St. Nicholas' Day, where we hide some chocolate in Germany for the kids.

[crslzz]

Hi @elfenpiff,
Yes, the version in https://github.com/ekxide/iceoryx2/tree/iox2-1223-in-mem-shm works exactly as intended, moving the shared memory objects to the root-path dir, and removing the need to share /dev/shm. Thank you for implementing this change!

[elfenpiff]

@crslzz we merged the branch and added an example on how to use a custom shared memory implementation, see: https://github.com/eclipse-iceoryx/iceoryx2/tree/main/examples/rust/service_variant_customization

The gist is, by default iceoryx2 still uses the shm_open call since the open call approach depends on having a file path pointing to an in-memory file system like tmpfs. If it is pointing, by accident, somewhere else the performance degrades.

With iceoryx2 we also introduced service variants that allow you to customize the mechanisms used for your setup. The example shows how to adjust the default ipc::Service variant to the file based approach.