Possibly split VCHIQ into multiple drivers?

Eric Anholt eric at anholt.net
Tue Nov 15 09:34:04 PST 2016

Michael Zoran <mzoran at crowfest.net> writes:

> I was just thinking about the security implications of VCHIQ by
> exposing that much to userland by default.  
> I'm thinking that perhaps VCHIQ should be split into at least two
> different drivers.
> 1. An internal driver that only serves kernel mode drivers.  For some
> reason, I'm less concerned about the security implications of in
> kernel(especially statical linked) driver clients.
> 2. A driver written on top of 1 that exposes the user mode API.   The
> idea is that this driver would be optional and would be disabled or
> left out of the kernel build config in a hardened/locked down
> environment.  This would make VCHIQ work in a way that's similar to the
> mbox user mode interface driver.
> Any thoughts/ideas?

You could put the /dev node setup under a config option if you wanted.
Separate drivers seems unnecessary to me (and given what the pain you'll
get to experience per DT node you want to add, I'd recommend avoiding
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20161115/705def35/attachment.sig>

More information about the linux-rpi-kernel mailing list