I run HASS on an amd64 virtual machine, so it’s possible there are difference between our devices. However, because both seem to be based on maintaining a set of Docker containers, I don’t think there’s much difference (other than the ARM specific virtual devicetree directory not existing on my machine).

If you run an up-to-date version of Docker, you should not have access to /sys/firmware by default. That’s a decision the Docker folks made because that directory contains things like bootloader configuration/information and Windows license keys.

On the Linux OS itself, there shouldn’t be any such restriction. If you can’t access these files outside of Docker, there’s something wrong, probably with your kernel. You said ssh’ing into the machine works as a workaround, so I don’t think this is the case.

What seems more likely to me, is that your current host OS comes with a recent version of Docker that shields the /sys/firmware directory from Docker containers by default. If the Docker version didn’t change, then I think what you’re seeing is what you should’ve been seeing all along.

The only way I can think of that Home Assistant could have changed this behaviour, is that it could’ve changed the configuration of the default containers. As you can read in the github issue I linked, there’s a way to tell Docker to basically disable security features (run in privileged more and allow access to all of sysfs). It’s possible that Home Assistant used to configure Docker in this manner, but no longer does.

Running a full application in privileged mode is normally a hack to work around other problems (i.e. not exposing the proper device paths with proper access controls and just allowing the container to do whatever and probably break out of isolation), so it could be that they enabled these workarounds to work around some unrelated issue. If the unrelated issue was fixed, and the containers no longer needed to run privileged, they could’ve disabled the workaround and broken your access to sysfs in the process.

The small Home Assistant supervisor daemon that acts as a sort of “”“hypervisor”“” (which handles updates of the other containers) does need to run in privileged mode; it needs to control Docker, so of course Docker can’t be configured to stop it from doing that. It’s a rather small service, though. However, I have noticed that on some installs, the supervisor daemon seems to lose its privileged mode due to a bug. It’s possible that this is bug also affected your seemingly privileged main container. If that’s the case, running the installation script again should fix the issue.

I googled all the terms I could think of that could affect your problem with “home assistant” but when it comes to devicetree access, only your Lemmy post seems to come up. I think your data collection setup may be rather unique among HASS users, so perhaps you really are the only one affected by this, or at least the only one who’s written a post about it.

In my tests, none of the normal (unprivileged) Docker containers I’m running on my servers could access /sys/firmware. I tested this under Ubuntu, Debian, Manjaro, and Arch hosts. Accessing various firmware related virtual files worked fine outside Docker, of course, but inside Docker, /sys/firmware is empty. I don’t have an Alpine install but I’d be surprised if that’d handle this directory any different.

Normally, you could work around the limitations here by just marking your home assistant container as privileged and ignoring the potential security implications, as you may have unknowingly been doing. I think that’s not exactly an unacceptable risk for a dedicated Raspberry Pi (though it would be bad to default to this configuration). Unfortunately, Home Assistant’s supervisor recreates containers for you during updates, so marking the containers as privileged can be more of a pain than you’d expect. You can try looking into ways to customise the Home Assistant Docker configuration to grant these permissions, perhaps there’s a config file I’m not aware of that you can use to make sure the supervisor recreates the containers with the appropriate configuration. As stupid as it may be, I would personally look towards alternative solutions, like your SSH workaround; perhaps your script can check for an empty /sys/firmware directory and apply the workaround from there?

tl;dr: it’s a kernel bug if you’re not running your data collecting script inside Docker, otherwise it could be a home assistant bug/update that caused the change, but as of a year or two ago you’re not supposed to be able to read these files from within a Docker container anyway.

For what it’s worth, I disagree with Docker’s blanket block of /sys/firmware and I hope the issue that’s open about this change will be resolved. You don’t want to leak Windows keys, but there should be an obvious way to expose the board info without disabling basic container security…