From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from terminus.zytor.com ([2001:1868:205::10] helo=mail.zytor.com) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UI9OC-0007Ta-7u for kexec@lists.infradead.org; Wed, 20 Mar 2013 03:08:32 +0000 Message-ID: <51492828.5070803@zytor.com> Date: Tue, 19 Mar 2013 20:08:24 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL References: <3pfl8u1ugprwkcs5xmtjth3l.1363742692541@email.android.com> <51492379.3090302@zytor.com> In-Reply-To: <51492379.3090302@zytor.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Matthew Garrett Cc: "linux-pci@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "linux-efi@vger.kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" On 03/19/2013 07:48 PM, H. Peter Anvin wrote: > On 03/19/2013 06:28 PM, Matthew Garrett wrote: >> Mm. The question is whether we can reliably determine the ranges a device should be able to access without having to trust userspace (and, ideally, without having to worry about whether iommu vendors have done their job). It's pretty important for PCI passthrough, so we do need to care. > > It is actually very simple: the device should be able to DMA into/out of: > > 1. pinned pages > 2. owned by the process controlling the device > > ... and nothing else. > The "pinning" process needs to involve a call to the kernel to process the page for DMA (pinning the page and opening it in the iommu) and return a transaction address, of course. I think we have the interface for that in vfio, but I haven't followed that work. -hpa _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL Date: Tue, 19 Mar 2013 20:08:24 -0700 Message-ID: <51492828.5070803@zytor.com> References: <3pfl8u1ugprwkcs5xmtjth3l.1363742692541@email.android.com> <51492379.3090302@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51492379.3090302-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "kexec" Errors-To: kexec-bounces+glkk-kexec=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Matthew Garrett Cc: "linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-efi@vger.kernel.org On 03/19/2013 07:48 PM, H. Peter Anvin wrote: > On 03/19/2013 06:28 PM, Matthew Garrett wrote: >> Mm. The question is whether we can reliably determine the ranges a device should be able to access without having to trust userspace (and, ideally, without having to worry about whether iommu vendors have done their job). It's pretty important for PCI passthrough, so we do need to care. > > It is actually very simple: the device should be able to DMA into/out of: > > 1. pinned pages > 2. owned by the process controlling the device > > ... and nothing else. > The "pinning" process needs to involve a call to the kernel to process the page for DMA (pinning the page and opening it in the iommu) and return a transaction address, of course. I think we have the interface for that in vfio, but I haven't followed that work. -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from terminus.zytor.com ([198.137.202.10]:42995 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751475Ab3CTDIf (ORCPT ); Tue, 19 Mar 2013 23:08:35 -0400 Message-ID: <51492828.5070803@zytor.com> Date: Tue, 19 Mar 2013 20:08:24 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 To: Matthew Garrett CC: "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "linux-efi@vger.kernel.org" , "kexec@lists.infradead.org" , "linux-pci@vger.kernel.org" Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL References: <3pfl8u1ugprwkcs5xmtjth3l.1363742692541@email.android.com> <51492379.3090302@zytor.com> In-Reply-To: <51492379.3090302@zytor.com> Content-Type: text/plain; charset=UTF-8 Sender: linux-pci-owner@vger.kernel.org List-ID: On 03/19/2013 07:48 PM, H. Peter Anvin wrote: > On 03/19/2013 06:28 PM, Matthew Garrett wrote: >> Mm. The question is whether we can reliably determine the ranges a device should be able to access without having to trust userspace (and, ideally, without having to worry about whether iommu vendors have done their job). It's pretty important for PCI passthrough, so we do need to care. > > It is actually very simple: the device should be able to DMA into/out of: > > 1. pinned pages > 2. owned by the process controlling the device > > ... and nothing else. > The "pinning" process needs to involve a call to the kernel to process the page for DMA (pinning the page and opening it in the iommu) and return a transaction address, of course. I think we have the interface for that in vfio, but I haven't followed that work. -hpa