From owner-svn-src-all@FreeBSD.ORG Tue Feb 4 07:53:34 2014 Return-Path: Delivered-To: svn-src-all@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 81D2BFFC; Tue, 4 Feb 2014 07:53:34 +0000 (UTC) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3E6E1D6D; Tue, 4 Feb 2014 07:53:33 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id w7so13059520qcr.28 for ; Mon, 03 Feb 2014 23:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FaB5DQyEJZnlmS3b7W/nULkYA7yIHYG5zi7Xm1GPvdE=; b=Acug1un3P8H5kZSOAZiJjuCKpWRotCf4U0iSGHM0QxyfoYNwWum5xOG06OY8g5uCCl CgnC9O6szWavJRQLLminyLXmoK3BkYBfHGj31o9T/ffQxGKOLzu850NGj9rhq256Tqdq zgB46cDbUAuWt3QJorRVOnFUJw+y6tILJkV06nXcJNrbCzXzW016/lUmmuIg/X2Fowx7 Qh2I4hTwwwp5im/Fpnv9jrgcQF+oM6HS2/C5KYvuoUkSusUYI3WSFaRQ4MQf1gre7cff Mh+u2yAk+W14qJLsCT4FOQ1/P+wDdO6ZMyXM/6JX3tLV9DEICX1wXcPyB1422QpJYkVL vINQ== MIME-Version: 1.0 X-Received: by 10.224.160.195 with SMTP id o3mr13411398qax.98.1391500413062; Mon, 03 Feb 2014 23:53:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Mon, 3 Feb 2014 23:53:32 -0800 (PST) In-Reply-To: <52EC4DBB.50804@freebsd.org> References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <20140129134344.GW66160@FreeBSD.org> <52E906CD.9050202@freebsd.org> <20140129222210.0000711f@unknown> <20140131223011.0000163b@unknown> <52EC4DBB.50804@freebsd.org> Date: Mon, 3 Feb 2014 23:53:32 -0800 X-Google-Sender-Auth: xIDx5GfiUr5GanLrpv8FR5XJpQY Message-ID: Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail From: Adrian Chadd To: James Gritton Content-Type: text/plain; charset=ISO-8859-1 Cc: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , Gleb Smirnoff , Robert Watson , "svn-src-head@freebsd.org" , Alexander Leidinger X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 07:53:34 -0000 On 31 January 2014 17:28, James Gritton 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