From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2F1DC433E7 for ; Fri, 9 Oct 2020 12:40:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 240D9222B8 for ; Fri, 9 Oct 2020 12:40:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ksmXbBWq"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="wSJCIxYl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 240D9222B8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=iEGxW90Ybntun4a4gK2WhzH2YVL6Syre5/pKmteN/M8=; b=ksmXbBWqD3opqRtuA89Lo1Sj9 1WzHwYsZo+1sErO3Dfth96xWFqT8Dfquh4wP6iD98+7lMglaZsoOzZg+60Aj+fdRd4bbIosx4FIVn epU0hcvhI9dg5jvAoQiScXRVoXDqLp3BGZSsT9PW77a5Jei7K8ppe1HpSD6L3Si+I/YQnYG0voRVL pRUXBbZ8AoEf/tnDbDJkVH3jBtYFPeC/ehqmAYo4E/11DdUIHJDnQplnYCEL584+u1Rnp1qYi9pVI +HiU4tpc5KCReGwh/ogrAs+EJAozNgJWQijK3hg338D3y273RIQjjz2q0uUPUawylVPao1sHxFdHo vYl5jwP3A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQreg-0003WX-II; Fri, 09 Oct 2020 12:37:50 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQreO-0003Lj-Es for linux-arm-kernel@lists.infradead.org; Fri, 09 Oct 2020 12:37:33 +0000 Received: from coco.lan (ip5f5ad5d0.dynamic.kabel-deutschland.de [95.90.213.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E09B7206BE; Fri, 9 Oct 2020 12:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602247050; bh=ruiGPoaea6akiTHS+AvFSiqq7lSiUQn1p22q5WNA1W0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=wSJCIxYl4F1jPbJncw+V2h9y4FuE4LpMRU+tKrXF5utyqs5uMgts7afTuLBBRKYAr 9YH6N1saYfI0AZj6UgTF6HO2LEUi/3X8iseC4ywPkN0VC2VLOj6D9SUZBOHZPx53Oi C8BqC/PANqTv9j0OylEQJGHm8asglolwe8J3aDiU= Date: Fri, 9 Oct 2020 14:37:23 +0200 From: Mauro Carvalho Chehab To: Jason Gunthorpe Subject: Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn Message-ID: <20201009143723.45609bfb@coco.lan> In-Reply-To: <20201009122111.GN5177@ziepe.ca> References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-10-daniel.vetter@ffwll.ch> <20201009123421.67a80d72@coco.lan> <20201009122111.GN5177@ziepe.ca> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201009_083732_627842_B002DC91 X-CRM114-Status: GOOD ( 33.01 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-s390@vger.kernel.org, linux-samsung-soc@vger.kernel.org, Jan Kara , Kees Cook , kvm@vger.kernel.org, Daniel Vetter , LKML , DRI Development , linux-mm@kvack.org, =?UTF-8?B?SsOpcsO0bWU=?= Glisse , John Hubbard , Daniel Vetter , Dan Williams , Linus Torvalds , Andrew Morton , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Em Fri, 9 Oct 2020 09:21:11 -0300 Jason Gunthorpe escreveu: > On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote: > > Hi, > > > > Em Fri, 9 Oct 2020 09:59:26 +0200 > > Daniel Vetter escreveu: > > > > > Way back it was a reasonable assumptions that iomem mappings never > > > change the pfn range they point at. But this has changed: > > > > > > - gpu drivers dynamically manage their memory nowadays, invalidating > > > ptes with unmap_mapping_range when buffers get moved > > > > > > - contiguous dma allocations have moved from dedicated carvetouts to > > > cma regions. This means if we miss the unmap the pfn might contain > > > pagecache or anon memory (well anything allocated with GFP_MOVEABLE) > > > > > > - even /dev/mem now invalidates mappings when the kernel requests that > > > iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87 > > > ("/dev/mem: Revoke mappings when a driver claims the region") > > > > > > Accessing pfns obtained from ptes without holding all the locks is > > > therefore no longer a good idea. > > > > > > Unfortunately there's some users where this is not fixable (like v4l > > > userptr of iomem mappings) or involves a pile of work (vfio type1 > > > iommu). For now annotate these as unsafe and splat appropriately. > > > > > > This patch adds an unsafe_follow_pfn, which later patches will then > > > roll out to all appropriate places. > > > > NACK, as this breaks an existing userspace API on media. > > It doesn't break it. You get a big warning the thing is broken and it > keeps working. > > We can't leave such a huge security hole open - it impacts other > subsystems, distros need to be able to run in a secure mode. Well, if distros disable it, then apps will break. > > While I agree that using the userptr on media is something that > > new drivers may not support, as DMABUF is a better way of > > handling it, changing this for existing ones is a big no, > > as it may break usersapace. > > media community needs to work to fix this, not pretend it is OK to > keep going as-is. > Dealing with security issues is the one case where an uABI break might > be acceptable. > > If you want to NAK it then you need to come up with the work to do > something here correctly that will support the old drivers without the > kernel taint. > > Unfortunately making things uncomfortable for the subsystem is the big > hammer the core kernel needs to use to actually get this security work > done by those responsible. I'm not pretending that this is ok. Just pointing that the approach taken is NOT OK. I'm not a mm/ expert, but, from what I understood from Daniel's patch description is that this is unsafe *only if* __GFP_MOVABLE is used. Well, no drivers inside the media subsystem uses such flag, although they may rely on some infrastructure that could be using it behind the bars. If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE flag that it would be denying the core mm code to set __GFP_MOVABLE. Please let address the issue on this way, instead of broken an userspace API that it is there since 1991. Thanks, Mauro _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel