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

[Alexander Leidinger]

Quoting Adrian Chadd <adrian at freebsd.org> (from Mon, 10 Feb 2014  
17:24:09 -0800):

> On 10 February 2014 17:07, James Gritton <jamie at freebsd.org> wrote:

>> So is it worthwhile to add a new jail parameter called "insecure" (or
>> somesuch)?  That way you could easily add the encapsulation without
>> any of the security.  The other vibe I'm getting is not to do
>> anything.  Either way, it sounds like the Xorg-enabling patch will
>> remain a patch - not seeing a lot of buy-in here.
>>
>> I'm not against more optional and obscure holes if they have a use; I
>> just call that "a fine-grained capabilities model."
>
> I'd rather it stay a patch. IMHO the only viable solution is to create
> a sandboxable API for this DRI/IO-MMU stuff to, well, DRI via.
>
> So hm. Can you actually run clients in different jails, but have them
> access the same DRI window(s)? Or does running a client in a jail
> force it to go all over the socket(s) and not via DRI?

I would assume that a client somehow determines if he is rendering  
local or remotely. If he is doing it local (= in the same "container"  
as the X server) it uses DRI. I do not expect that two jails with  
"allow.kmem" allow to use DRI to the same X server, but I haven't  
tested it, so take it only as a gut-feeling.

Bye,
Alexander.

-- 
http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137