svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail

[Adrian Chadd]

On 31 January 2014 17:28, James Gritton <jamie at freebsd.org> wrote:


> I second the documentation route.  Yes, it's true that this option
> makes a totally insecure jail - at least one lacking the expected jail
> security additions.  But I think that while security is one of the
> primary purposes of jails, it's not the only purpose.  It should be
> possible to have a trusted "master jail" that still takes advantage of
> the encapsulation while allowing otherwise unsupported features such
> as a desktop.

No; the xorg probe and device hackery API should somehow be modified
to support this kind of hackery.

And/or a very specific API that doesn't simply require /dev/io and
/dev/kmem to be exposed.

> The distinction of whether certain devices are required to break out
> of a jail with allow.kmem is something of a red herring - the fact is
> that anyone who wants this level of access is going to have the
> devices in place anyway.
>
> I suppose "obviate" wasn't the best word for the situation.  Maybe
> something that starts with "WARNING: ..." is in order.
>
> I'd like to re-submit the patch with only the documentation changed
> (unless someone knows of something that would accomplish the same
> goals with different code).  But I'll run it by secteam@ first, and
> abide by the consensus there.

I really would rather see Xorg gain whatever abstraction is necessary
to probe/attach/interface with a DRI API supported graphics card.

So, this then becomes a question of whether this is needed for DRI API
supported graphics cards, or whether you're trying to solve the
general case (eg for nvidia stuff.) It would be nice to enumerate
what's required for different ways of interfacing to the graphics
subsystem(s).


-a