Parrot-Sphinx in a container - firmwared

[brandon]

We’re attempting to build the Parrot-Sphinx software inside of a Singularity container. I think we’ve gotten close, however we’ve ran into an issue with firmwared. Our host OS is CentOS 7.7-1908. When attempting to start firmwared inside of the container we get an error with the kernel being too old. Our Kernel is 3.10.0-1062 and firmwared wants at least 3.18. Is there anyway to start firmwared on this older kernel? Our systems are based on CentOS 7 and unfortunately at this moment, kernel 3.10 is the newest we’ll have for some time. Any feedback is appreciated. Thank you.

[ndessart]

Hi @brandon,

Parrot-Firmwared is a container engine of its own (like docker) and relies on some advanced linux namespace and other kernel features. The minimal recommended linux version for running Sphinx is 4.4.

That being said, running Sphinx/Firmwared in a container is quiet difficult.

@ndessart

Running sphinx-server in a docker container is relatively hard. You’ll probably hit other issues :

• you need to create an X server DISPLAY (or share the host one)
• sphinx needs access to the nvidia driver libraries if you want to use your GPU to its full potential
• you need to give the container a lot of privileges for firmwared to run properly
• (optionally) share your host wifi interface
• …

Off the top of my head, the docker run command line should look like :

   # /tmp directory that will be bind mounted inside the docker container
   # This should be a regular filesystem (ext4 ?) and not some
   # exotic union fs (overlayfs, aufs,...)
   tmp_dir="/tmp"
   [[ -d "${tmp_dir}" ]] || mkdir -p "${tmp_dir}"
   # Path to the host nvidia drivers
   NVIDIA_PATH=/usr/lib/nvidia-375
   docker run -it --rm \
   --privileged \
   `# Graphics setup` \
   -v /tmp/.X11-unix:/tmp/.X11-unix:ro      `# share the host X server socket` \
   -e DISPLAY="${DISPLAY}"                  `# share the host display` \
   -v ${NVIDIA_PATH}:${NVIDIA_PATH}:ro      `# mount bind host nvidia drivers` \
   -e NVIDIA_PATH=${NVIDIA_PATH} \
   -v "${tmp_dir}":/tmp                     `# Note that /tmp in the container is` \
                                            `# not in an overlay filesystem.` \
                                            `# This is important because firmwared` \
                                            `# will (ab)use overlayfs there.` \
   --net=host                               `# (optionally) share the host net` \
                                            `# namespace to use your wifi interface` \
 
  <your_docker_image_name> <args...>

Please note that, firmwared is a container engine of its own (like docker) and it doesn’t really like to be sitting on top of a union filesystem like overlayfs (the default filesystems used by docker and firmwared). At Parrot, we’ve already encountered some kernel related issues with firmwared in docker and this is why it’s important that inside the container /tmp is part of a regular filesystem: ext4, eventually tmpfs but not overlayfs or aufs.

Regards

Nicolas

[brandon]

Hi @ndessart. The post you linked was the post I was following to start to get this to work when I ran into the issue that I posted about. Unfortunately it doesn’t seem to entirely answer the problem I’m running into.

The minimal recommended linux version for running Sphinx is 4.4.

Is this just recommended or required? Is there any chance of getting it to run on an older kernel than this recommended one? CentOS 8 should work as it’s 4.18, but unfortunately everything we currently have is on CentOS 7 for the foreseeable future.

The post you linked has some good concerns. Most of which we have figured out, besides this one.

Any feedback is appreciated. Thanks!

[ndessart]

Sphinx was initially developed during the Ubuntu 14.04 (Xenial) era under a 3.13, 3.16 and 3.19 (14.04.4) kernel and I think that at one point we needed a 3.18 kernel to be able to use a new AppArmor profile feature that was included in that kernel release.

Running Firmwared on a 3.10 kernel would imply that you disable some protections offered by AppArmor. Your host kernel would then give additional privileges to the simulated firmware. We can’t lower this requirement without performing an in-depth analysis of the implications.

[brandon]

Gotcha. That makes sense. I’ll have to do some exploring to see what I can do to make it work then in my environment. Thanks!