Cannot run packaged dmidecode on UC18 (works fine on UC16)

#1

Hello,

I have a snap that packages dmidecode and uses it to retrieve firmware-related information at launch.

I discovered that this works fine on classic and UC16, but it fails on UC18 with the following error:

$ snap run --shell qabro
$ sudo env PATH=/snap/qabro/100/usr/sbin:/snap/qabro/100/usr/bin:/snap/qabro/100/sbin:/snap/qabro/100/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/
usr/bin:/sbin:/bin:/usr/games:/usr/local/games dmidecode -s system-manufacturer
/dev/mem: Operation not permitted
/dev/mem: Bad file descriptor

Is it expected from UC18? How can I solve this issue?

Thanks!

#2

You need to plugs physical-memory-observe and either be root or in the kmem group.

If you meet all those criteria, there might be a dmidecode or kernel bug since physical-memory-observe is supposed to ‘with STRICT_DEVMEM=y, allow reading /dev/mem for read-only access to architecture-specific subset of the physical address (eg, PCI, space, BIOS code and data regions on x86, etc).’ If you feel this is the case, perhaps using base: core18 would get you a dmidecode that would work on that kernel.

#3

Thanks for the reply, @jdstrand!

I currently install my snap with --devmode and it’s already using base: core18. Does devmode requires plugs anyway, or does it bypass this mechanism completely?

#4

–devmode just turns all denials into allowances but you still get an audit log entry for each and every access to the interface until you connect it.

so to avoid flooding your journal you should still connect as many interfaces as you can, even in devmode (also makes debugging easier if you dont have to fish out the relevant error messages from a sea of pointless “ALLOWED” messages :wink: )

#5

I feel obligated to point out I know of the existence of a snap that works in strict mode with the plugs, but doesn’t work in devmode with the same plugs, so there could be dragons there…

Also I’ll say that snap was a complicated Qt snap with ROS stuff so probably much different from this

#6

Well, devmode is supposed to work like this, so if you see bugs, please report them.

#7

Thank you everyone for your feedback!

Important note before I go on: after testing the following, I realized that this issue only seems to happen with the armhf and arm64 builds of the snap, not the amd64 build…

I added a bunch of plugs to my snap recipe:

    command: qabro
    (...)
    plugs: &standard [home, network-bind, hardware-observe, mount-observe,
        network-manager, system-observe, physical-memory-observe]
    (...)

I build the snap, then install it (using --devmode) and connect the plugs:

$ snap connect qabro:hardware-observe :hardware-observe
$ snap connect qabro:physical-memory-observe :physical-memory-observe
$ ...
$ snap connections qabro
Interface                Plug                           Slot                      Notes
hardware-observe         qabro:hardware-observe         :hardware-observe         manual
home                     qabro:home                     :home                     manual
mount-observe            qabro:mount-observe            -                         -
network-bind             qabro:network-bind             :network-bind             -
network-manager          qabro:network-manager          -                         -
physical-memory-observe  qabro:physical-memory-observe  :physical-memory-observe  manual
system-observe           qabro:system-observe           :system-observe           manual

But the problem still happens:

$ snap run --shell qabro
$ sudo /snap/qabro/x1/usr/sbin/dmidecode -s system-manufacturer
/dev/mem: Operation not permitted
/dev/mem: Bad file descriptor
#8

I suspect this is related to STRICT_DEVMEM=y in the kernel config which allows reading /dev/mem for read-only access to architecture-specific subset of the physical address (eg, PCI, BIOS code and data regions on x86, etc). It’s plausible that dmidecode needs an update for the newer kernel. Perhaps if you haven’t already, you should use ‘base: core18’ for qabro and then stage-packages dmidecode, which will now come from Ubuntu 18.04 and hopefully work with the newer kernels.

#9

beyond what jamie said, you should generally be putting the sudo on the first command (before snap run... ) the way you call it abve execs sudo from inside the snap shell env which might or might not cause unexpected results…

#10

I’ve updated core: base18 in my snapcraft.yaml a while ago, and am already staging dmidecode from there, so my snap is already running dmidecode 3.1.

Just for the record, I’m trying to run this on a Raspberry Pi 3 with the latest Ubuntu Core 18 I found on ubuntu.com. uname -a returns 4.15.0-1052-raspi2 #56-Ubuntu SMP PREEMPT Tue Nov 26 15:37:05 UTC 2019 armv7l armv7l armv7l GNU/Linux

Thanks for the feedback @ogra. I tried the following:

pieq@localhost:~$ sudo snap run --shell qabro
root@localhost:/home/pieq# /snap/qabro/x1/usr/sbin/dmidecode -s system-manufacturer
/dev/mem: Operation not permitted
/dev/mem: Bad file descriptor
root@localhost:/home/pieq# /snap/qabro/x1/usr/sbin/dmidecode -V                    
3.1
root@localhost:/home/pieq# /snap/qabro/x1/usr/sbin/dmidecode   
# dmidecode 3.1
Scanning /dev/mem for entry point.
/dev/mem: Operation not permitted
/dev/mem: Bad file descriptor

Seems like I’m getting the same result :frowning:

Also, I was originally using sudo inside my snap, because my snap application is running some pretty basic stuff, and only requires sudo for the dmidecode command… If I run my snap as sudo, it creates other problems (if I remember correctly, haven’t tried that in a while).