Possibly split VCHIQ into multiple drivers?

[Eric Anholt]

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
it).
-------------- 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>