¿Qué es / dev / vchiq en Raspberry Pi?

10

Estoy usando Raspberry Pi 3 y raspbian jessie y me encontré con / dev / vchiq al intentar llamar al programa (omxplayer) con perg-cgi que reproduciría algo de música en mi RiPi. Y no podría hacerlo funcionar.

Cuando lo abrí con mi navegador (por ejemplo, localhost / muzikica / pusti.pl) [apache2] decía " no se pudo abrir la instancia de vchiq ". Así que cambié los permisos del archivo / dev / vchiq a xx7 y funcionó hasta que no reinicié mi RiPi. Entonces lo descubrí y agregué www-data (usuario que está ejecutando mi programa al que llamaría mi script pusti.pl) al grupo de video, porque / dev / vchiq es parte del grupo de video. ¡Y funcionó!

Ahora, ¿qué demonios es / dev / vchiq xD y por qué www-data necesita al menos permisos de lectura y escritura para reproducir sonido en mi Raspberry Pi?

Gracias por adelantado.

Бојан Драшко
fuente

Respuestas:

12

Me sorprende que el todopoderoso Google no tenga una respuesta lista para la pregunta "¿qué es VCHIQ?" Soy un experto en kernel desde hace mucho tiempo y no soy un empleado de Broadcom, ni soy experto en BCM283 *, pero esto es lo que he encontrado para (tal vez) la posteridad:

Desde la rama del núcleo Raspberry Pi :

Interfaz de comunicación Kernel a VideoCore para la familia de productos BCM2708.

Lo que vale la pena señalar aquí es que VideoCore es (sorpresa sorpresa) el controlador de video para el SoC que ejecuta Pi, y parece que esta es una forma práctica de ejecutar IOCTL más o menos directos en varios subsistemas conectados a la GPU . Que esto incluya video no es una gran sorpresa, pero supongo que tiene sentido que la interfaz de la cámara tenga su silicio dentro de VideoCore dado todo el codec que necesita hacer el video.

Entonces, ¿por qué el control de audio también se ejecuta a través de VideoCore (de lo contrario no necesitaría VCHIQ para controlarlo)? Sospecho que, dado el hecho de que VC tiene soporte de hardware para H.264 y otros códecs (y porque puede enrutar audio a través de HDMI), fue el lugar más fácil para colocar el silicio. Bueno, eso y el hecho de que el chip BCM tiene dos MMUs (uno para el VC + ARM, otro para el sistema operativo normal de servicio- ver diagrama en la página 5 ), lo que hace copia cero DMA sea posible (sin necesidad de copiar cosas a la silicio de audio: solo dígale que una parte de la memoria le pertenece a él y no a la CPU. Todavía no sé si realmente lo hacen bajo las cubiertas, pero ¿por qué no lo haría?).

Tenga en cuenta que los IOCTL en VCHIQ realmente no transfieren datos per se: configuran DMA y otras operaciones entre fragmentos de memoria y envían comandos a varios bits. Esto puede ser súper peligroso, ya que potencialmente podría atornillar las estructuras internas de datos del kernel desde el espacio de usuario, bloquear la GPU, colgar datos corruptos, etc. ¡¡Así que no configure / dev / vhciq en modo 777 !!!

En cualquier caso, la respuesta corta a "¿qué es VCHIQ?" Aquí está:

VCHIQ es una interfaz de comando entre el núcleo Linux en ejecución y los periféricos (entre otras cosas) en el silicio VideoCore. / dev / vhciq proporciona acceso genérico de espacio de usuario a esos comandos para que también lo utilicen (como mínimo) la cámara y los subsistemas de audio. Es una interfaz decentemente peligrosa para exponer a programas aleatorios, de ahí los permisos algo restrictivos por defecto.

Hay personas que están a la altura de sus ojos en el hardware BCM en la comunidad RPi; No soy uno de ellos (tal vez estoy hasta los tobillos después de un par de horas de investigación :-)). Dicho esto, creo que esta es una descripción general de alto nivel decente y agradecería adiciones / correcciones.

En cuanto a por qué www-data requiere permiso, eso sería porque su programa CGI está generando procesos secundarios como ese usuario. No conozco bien a ese jugador en particular, pero una mejor práctica generalmente sería ejecutar algún demonio especial para controlar el programa que está interactuando con el sonido y controlándolo desde CGI usando un socket UNIX o una interfaz similar en lugar de engendrar directamente a un niño.

De hecho, un proveedor de seguridad fue arrestado hace un tiempo por permitir el acceso raíz de su servidor web a su máquina. Probablemente hicieron esto para facilitar la gestión de procesos en lugar de escribir este tipo de capa intermedia, pero es un no-no de seguridad. Darle a Apache acceso básicamente ilimitado a GPU DMA es una idea igualmente mala (aunque mucho más difícil de explotar, lo admito).

Esperemos que esto responda tu pregunta.

BJ Black
fuente
1
"Entonces, ¿por qué el control de audio también se ejecuta a través de VideoCore (de lo contrario no necesitaría VCHIQ para controlarlo)?" -> Tenga en cuenta que no debería necesitar acceso para /dev/vhciqejecutar audio en general, en este caso es porque el OP lo está utilizando omxplayerpara hacerlo, lo que probablemente no sea lo ideal.
Ricitos de oro
Hmm Espero que haya un controlador ALSA que cree las interfaces terrestres de usuario adecuadas. No sé nada sobre omxplayer que no sea una búsqueda de Google de 5 segundos y me pregunto si está haciendo algo interesante con ese acceso adicional en audio (como usar un códec de hardware) o simplemente abriendo estúpidamente un dispositivo que no necesita. Fascinante, y también me imagino que el controlador ALSA usa VHCIQ debajo de las cubiertas (directamente dentro del kernelspace, natch). ¡Cosas ordenadas!
BJ Black
1
No tengo idea de si esto es lo que realmente sucede, pero las especulaciones ... La GPU tiene decodificación MPEG de hardware y eso puede incluir audio MP3 (no puede encontrar una referencia de ninguna manera), y un decodificador de hardware probablemente consumiría un poco menos jugo que la decodificación de software. No vale la pena por el costo de seguridad, pero posiblemente sea interesante.
BJ Black
1
Huh Ordenado. Simplemente mirando pqru.qr.ai y parece que el controlador ALSA de hecho usa VHCIQ debajo de las cubiertas (no es necesario hablar con / dev / vhciq porque puede llamar a la API del kernel directamente, pero aún así ...).
BJ Black
2
Por supuesto. Básicamente, lo que sucede aquí es que el chip Broadcom se divide en dos partes principales: la CPU (que es con lo que Linux habla y ejecuta el software de uso general) y la GPU (que ejecuta un firmware independiente y maneja video, etc.). VCHIQ es la interfaz que usa la CPU para hablar con la GPU. Esta es una simplificación, pero probablemente lo suficientemente buena por ahora.
BJ Black
0

En mi caso tuve el mismo problema cuando creé un nuevo usuario además del usuario predeterminado, y tuve problemas no solo con el sonido sino también con la configuración del wifi, el acceso al puerto serie, etc. Luego abrí el / etc / grupo de archivos. Y agregué mi usuario a todos los grupos donde se insertó el usuario 'pi', y todo funcionó perfectamente. Como sigue:

raíz: x: 0:
demonio: x: 1:
bin: x: 2:
sys: x: 3:
adm: x: 4: pi, carlos 
tty: x: 5: pi, carlos
disco: x: 6:
lp: x: 7:
correo: x: 8:
noticias: x: 9:
uucp: x: 10:
hombre: x: 12:
proxy: x: 13:
kmem: x: 15:
marcado: x: 20: pi, carlos
fax: x: 21:
voz: x: 22:
cdrom: x: 24: pi, carlos
disquete: x: 25:
cinta: x: 26:
sudo: x: 27: pi, carlos 
audio: x: 29: pi, carlos , presiona
inmersión: x: 30:
www-data: x: 33:
copia de seguridad: x: 34:
operador: x: 37:
lista: x: 38:
irc: x: 39:
src: x: 40:
mosquitos: x: 41:
sombra: x: 42:
utmp: x: 43:
video: x: 44: pi, carlos
sasl: x: 45:
plugdev: x: 46: pi, carlos
personal: x: 50:
juegos: x: 60: pi, carlos 
usuarios: x: 100: pi, carlos
nogrupo: x: 65534:
entrada: 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:
bus de mensajes: 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:
prensa: x: 117:
acceso por pulso: x: 118:
 

Marcos Cruz
fuente