From owner-svn-src-head@FreeBSD.ORG Tue Feb 11 12:25:33 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CBF211C; Tue, 11 Feb 2014 12:25:33 +0000 (UTC) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id E1E4E1B0B; Tue, 11 Feb 2014 12:25:32 +0000 (UTC) Received: from outgoing.leidinger.net (p57A39136.dip0.t-ipconnect.de [87.163.145.54]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 58880844009; Tue, 11 Feb 2014 13:16:26 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id A2AE33852; Tue, 11 Feb 2014 13:16:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1392120983; bh=sIrZyMeZ+WpvEKRj+9tiVI9lcDvQTgVE08Mv0wGpja4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=SYkl9CmQi1FLq5GIo/ciSbJ+/TSRLDx9YJ6C/TyT+gVKiV49mfNhBrgBY+k2EzCmo +B2NZL83eUZp2XUalGtUC4Dwmg7nOPDo1phJavPznynZ8SRaUMwjEFYsTpVLRrdeew OZ8HS+xTJK0t0UHtVekE2Sn0lCxuJrkpZmd7LXesCQ7yt0MD0UdI4N2qepfCn4qJem kNDaiWlFYgIch+S8v5N01fyijJ3x15zl2o5kQFKznn8Zp+wz1SUL7NEGIjn5ohaAaJ 4I8DcbUnC3xaSpHPPs3eLsR4RbWOgAv1j48sc7m1/zHb6S/RS+wz7/ql/78Lqp8DIA nXEe/jk6+OBBA== Received: (from www@localhost) by webmail.leidinger.net (8.14.7/8.14.4/Submit) id s1BCGLnr018576; Tue, 11 Feb 2014 13:16:21 +0100 (CET) (envelope-from Alexander@leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@leidinger.net using -f Received: from 217.197.101.97 ([217.197.101.97]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 11 Feb 2014 13:16:21 +0100 Date: Tue, 11 Feb 2014 13:16:20 +0100 Message-ID: <20140211131620.Horde.tGeutf6n8Vfaosr3bjHnhQ1@webmail.leidinger.net> From: Alexander Leidinger To: Adrian Chadd Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <52EC4DBB.50804@freebsd.org> <20140203235336.GA46006@ambrisko.com> <2362081.WrjYmKeYu9@ralph.baldwin.cx> <52F977D9.5010200@freebsd.org> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 58880844009.A1ABF X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.107, required 6, autolearn=disabled, AWL -0.08, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RP_MATCHES_RCVD -0.00, TW_SV 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1392725787.6996@ZSGHz7keCA+5b0g7JQR3hw X-EBL-Spam-Status: No Cc: src-committers@freebsd.org, Doug Ambrisko , John Baldwin , svn-src-all@freebsd.org, Gleb Smirnoff , Robert Watson , James Gritton , svn-src-head@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 12:25:33 -0000 Quoting Adrian Chadd (from Mon, 10 Feb 2014 17:24:09 -0800): > On 10 February 2014 17:07, James Gritton 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