17

I am using Raspberry Pi 3 and raspbian jessie and I came across /dev/vchiq by trying to call program (omxplayer) with perg-cgi which would play some music on my RiPi. And I coudn't get it to work.

When I opened it with my browser (e.g. localhost/muzikica/pusti.pl)[apache2] it said "failed to open vchiq instance". So I changed /dev/vchiq file's permissions to xx7 and it worked until I didn't restart my RiPi. So figured it out and added www-data (user which is executing my program that my pusti.pl script would call) to video group, because /dev/vchiq is part of video group to. And it worked!

What is /dev/vchiq and why does www-data needs at least read and write permissions to play sound on my Raspberry Pi?

Fred
  • 4,552
  • 18
  • 29
Skodra
  • 173
  • 1
  • 1
  • 6

2 Answers2

20

I'm amazed that the almighty Google doesn't have a ready answer to the question "what is VCHIQ?" I'm a longtime kernel geek and not a Broadcom employee, nor am I BCM283* expert, but here's what I've found for (maybe) posterity:

From the Raspberry Pi kernel branch:

Kernel to VideoCore communication interface for the BCM2708 family of products.

What's worth noting here is that the VideoCore is (surprise surprise) the video controller for the SoC that the Pi runs, and it would appear that this is a handy way to run more-or-less direct IOCTLs to various subsystems hooked into the GPU. That this includes video is no big surprise, but I guess it makes sense that the camera interface has its silicon within VideoCore given all the codec stuff video needs to do.

So why is audio control run through the VideoCore as well (otherwise it wouldn't need VCHIQ to control it)? I suspect that, given the fact that VC has hardware support for H.264 and other codecs (and because you can route audio through HDMI), it was just the easiest place to put the silicon. Well, that and the fact that the BCM chip has two MMUs (one for the VC+ARM, another for normal OS use--see diagram on pg 5), which makes zero-copy DMA possible (no need to copy things to the audio silicon--just tell it that a chunk of memory belongs to it and not the CPU. Dunno yet if they actually do this under the covers, but why wouldn't you?).

Note that the IOCTLs on VCHIQ don't really transfer data per se--they set up DMA and other operations between memory chunks and send commands to various bits. This can be super dangerous, as you could potentially screw with internal kernel data structures from userspace, crash the GPU, sling around corrupt data, etc. So don't set /dev/vchiq to mode 777!!!

In any case, the short answer to "what is VCHIQ?" Here it is:

VCHIQ is a command interface between the running Linux kernel and peripherals (among other things) in the VideoCore silicon. /dev/vchiq provides generic userspace access to those commands for use by (at minimum) the camera and audio subsystems as well. It's a decently dangerous interface to expose to random programs, hence the somewhat restrictive permissions by default.

There are people that are up to their eyeballs in the BCM hardware in the RPi community; I'm not one of them (I'm perhaps ankle-deep after a couple of hours of research :-) ). That said, I think this is a decent high-level overview and would welcome additions/corrections.

As far as why www-data requires permission, that would be because your CGI program is spawning child processes as that user. I don't know that particular player well, but better practice would usually be to run some specialty daemon to control the program that's interfacing to sound and controlling it from CGI using a UNIX socket or similar interface rather than directly spawning a child.

Indeed, a security vendor got busted a while back for allowing their web server root access to their machine. They probably did this to ease process management rather than writing this type of middle layer, but it's a security no-no. Giving apache basically unfettered access to GPU DMA is an equally bad idea (though much harder to exploit I admit).

Hopefully this answers your question.

niry
  • 103
  • 3
BJ Black
  • 576
  • 3
  • 6
  • 1
    "So why is audio control run through the VideoCore as well (otherwise it wouldn't need VCHIQ to control it)?" -> Note that you shouldn't need access to /dev/vhciq to run audio generally -- in this case it's because the OP is using omxplayer to do it, which is probably not ideal. – goldilocks Sep 07 '16 at 10:19
  • Hmm. I expect there's an ALSA driver that creates the appropriate user land interfaces. I know nothing about omxplayer other than a 5-second Google search and wonder if it's doing anything interesting with that extra access on audio (like using a hardware codec) or just stupidly opening a device it doesn't need. Fascinating, and I'd also imagine that ALSA driver uses VHCIQ under the covers (directly within kernelspace, natch). Neat stuff! – BJ Black Sep 07 '16 at 10:25
  • It's a framebuffer based video player written for the Pi, with hardware acceleration -- which makes it pretty clever, I don't think anything else including uv4l will do that sans X server. I guess it can also be used play audio but I am not sure what the point of doing so is since, as you say, the normal ALSA driver (used by normal audio apps) should be fine. Nice answer BTW. – goldilocks Sep 07 '16 at 10:55
  • 1
    I've no idea if this is what actually happens, but speculation... The GPU has hardware MPEG decode and that might include MP3 audio (can't find a ref either way), and a hardware decoder would likely consume a bit less juice than software decode. Totally not worth it for the security cost, but possibly interesting. – BJ Black Sep 07 '16 at 11:03
  • 1
    Huh. Neat. Just looking through http://pqru.qr.ai and it looks like the ALSA driver does indeed use VHCIQ under the covers (no need to talk to /dev/vhciq because it can call the kernel API directly, but still...). – BJ Black Sep 07 '16 at 11:16
  • It's more accurate to say that the audio chip is embedded within the GPU and the CPU needs some interface to send commands to it (that interface being VCHIQ). If you used a different sound-playing program (one that only used the standard ALSA interfaces), you'd not need to talk this protocol (the ALSA driver would do it for you). Your call, but it'll it were me, I'd try to change the audio player if possible. – BJ Black Sep 07 '16 at 20:27
  • Thanks for your elaborate answer, i appreciate it. So what i understood is... It is actually special chip for video-audio processing? While you are all here, can i ask what do i need to know to understand what exactly is vhqic device as i am realy just simple programmer and know some electronics and you guys are speaking language i still dont understand xD – Skodra Sep 07 '16 at 20:31
  • BJ Black Ahaa, ok i get it. Well if it has dedicated hardware for it why not use it :D. And it is official player for Raspberry Pi as i understand. But nice to know. – Skodra Sep 07 '16 at 20:34
  • 5
    Sure. Basically what's happening here is that the Broadcom chip is cut into two main parts--the CPU (which is what Linux talks to and runs general-purpose software) and the GPU (that runs an independent firmware and handles video, etc.). VCHIQ is the interface that the CPU uses to talk to the GPU. This is a simplification, but likely good enough for now. – BJ Black Sep 07 '16 at 20:38
  • That makes sence. Is this common in ARM instruction set architecture or some other ISA? – Skodra Sep 07 '16 at 20:43
  • It's fairly common in general, really. In the PC world, the CPU is usually thought of as the center of the universe that all data flows through. This isn't nearly so true in the embedded and SoC world (where there is commonly the conceptual separation of management path and data path). And honestly, it's becoming more prevalent in PCs with the advent of AMD APUs (which do this kind of thing too). – BJ Black Sep 07 '16 at 20:50
  • Thanks for the insights... wish you'd write more on this subject! – Seamus Sep 15 '20 at 00:33
  • Interesting side note, temperature control is also here. It's accessed by vcgencmd. – Philip Couling Mar 10 '21 at 15:42
0

In my case I had the same problem when I created a new user besides the default user, and I had problems not only with the sound but also the configuration of the wifi, access to serial port etc ... Then I opened the / etc / group file. And I added my user to all groups where user 'pi' was inserted, and everything worked perfectly. As follows: 

root: x: 0:
daemon: x: 1:
bin: x: 2:
sys: x: 3:
adm: x: 4: pi,carlos
tty: x: 5: pi, carlos
disk: x: 6:
lp: x: 7:
mail: x: 8:
news: x: 9:
uucp: x: 10:
man: x: 12:
proxy: x: 13:
kmem: x: 15:
dialout: x: 20: pi, carlos
fax: x: 21:
voice: x: 22:
cdrom: x: 24: pi, carlos
floppy: x: 25:
tape: x: 26:
sudo: x: 27: pi, carlos
audio: x: 29: pi, carlos, press
dip: x: 30:
www-data: x: 33:
backup: x: 34:
operator: x: 37:
list: x: 38:
irc: x: 39:
src: x: 40:
gnats: x: 41:
shadow: x: 42:
utmp: x: 43:
video: x: 44: pi, carlos
sasl: x: 45:
plugdev: x: 46: pi, carlos
staff: x: 50:
games: x: 60: pi, carlos
users: x: 100: pi, carlos
nogroup: x: 65534:
input: x: 101: pi, carlos
systemd-journal: x: 102:
systemd-timesync: x: 103:
systemd-network: x: 104:
systemd-resolve: x: 105:
systemd-bus-proxy: x: 106:
crontab: x: 107:
netdev: x: 108: pi, carlos
pi: x: 1000:
messagebus: x: 109:
ssh: x: 110:
bluetooth: x: 111:
avahi: x: 112:
spi: x: 999: pi, carlos
i2c: x: 998: pi, carlos
gpio: x: 997: pi, Carlos
lightdm: x: 113:
epmd: x: 114:
ssl-cert: x: 115:
Carlos: x: 1001:
rtkit: x: 116:
press: x: 117:
pulse-access: x: 118:
 
Marcos Cruz
  • 1