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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 73885C43467 for ; Fri, 9 Oct 2020 12:21:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1D7FB2184D for ; Fri, 9 Oct 2020 12:21:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="dRexUDY3" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733020AbgJIMVQ (ORCPT ); Fri, 9 Oct 2020 08:21:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731081AbgJIMVP (ORCPT ); Fri, 9 Oct 2020 08:21:15 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 874DBC0613D7 for ; Fri, 9 Oct 2020 05:21:13 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id d1so7717852qtr.6 for ; Fri, 09 Oct 2020 05:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GEBFnNzCc2Aa+VvpaaWfqgqAphuQOGzaQHxTmQfOeXI=; b=dRexUDY3H8MczQ4QLPjINl81RcewsEJoOwrcRnS/wdN6+1ahY+3vJqHFQSRB3AKEat Z5ZaXXZPosq4Wbd2jnV/U3qSyNEiSVNzFD8cJAswQl5FTJES+qJJJxPuS2/N1xstVsKE DmLKmIoNq1PULtGkiX9+m6e1iqZaCGoeY5Z+TbjwSmpmk3vladKQnD3eC3IjfehfAuWk OAoO3ZuMd+rz9DNMaLq4YRdS5/enCBHoI5KrUmpa+3FN6vqOFl+XYKf3xsXAEqCHUZGe a3qzy4AHPVKLKT9jFp2Z0TSDspqDK1w0Z9U5mPCKkR2TBx/oNoqCaY/YIuclFEo3wtty CzGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GEBFnNzCc2Aa+VvpaaWfqgqAphuQOGzaQHxTmQfOeXI=; b=IyOM2vsHRj5SN7Htrd0OcMqIYRZ0u1QP7cN1M5VUXLiyuwkkGflEK+nfFWa6LZF7+Z unzfgRK+k6+vP4J4XNQSzAifmZav4E9qCdxXoBqJtcXR8rsytmWifkjXJZ+tcDUEYNyt JLCWeFq9z/9OD8goqFy9kcCwa8IXkVN7tqvFagBQGliknimCBryHAmCyLTebFmq13jCo RBF6rVgn5mKgrWYrJ7xRcenOuhDwUsbUAWacynD5UDtLYNHofwM8c7y5RDJL7p/5T23g DYbNzC1w/j9vWi9Kz+VM7jRPH05nd9cKipiFId6KK00iAKJ50DluCAvvAQLeSFbL+ASg MqIQ== X-Gm-Message-State: AOAM530ICz/EenoXcZwc+CkqdBusjrSZWmXXE7PhOSVONUV9xbqsGRw5 KZ39HyXQj9XOPME+EMAASXuOGg== X-Google-Smtp-Source: ABdhPJxabis31V1ruCjg81xS+awnWmlIxScXs/iSYcl2LZthnsEHjAadouQof92mVKkzbF3fOMDQng== X-Received: by 2002:ac8:1910:: with SMTP id t16mr12554428qtj.351.1602246072505; Fri, 09 Oct 2020 05:21:12 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id x7sm3318061qkc.24.2020.10.09.05.21.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Oct 2020 05:21:11 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kQrOZ-001xjJ-2z; Fri, 09 Oct 2020 09:21:11 -0300 Date: Fri, 9 Oct 2020 09:21:11 -0300 From: Jason Gunthorpe To: Mauro Carvalho Chehab Cc: Daniel Vetter , DRI Development , LKML , kvm@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org, linux-s390@vger.kernel.org, Daniel Vetter , Kees Cook , Dan Williams , Andrew Morton , John Hubbard , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Jan Kara , Linus Torvalds Subject: Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn Message-ID: <20201009122111.GN5177@ziepe.ca> References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-10-daniel.vetter@ffwll.ch> <20201009123421.67a80d72@coco.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201009123421.67a80d72@coco.lan> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. Jason 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 4DD5CC433DF for ; Fri, 9 Oct 2020 12:22:53 +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 D238C22284 for ; Fri, 9 Oct 2020 12:22:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="dBxZUwQQ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="dRexUDY3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D238C22284 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca 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:In-Reply-To:MIME-Version:References: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=rK46FJZQ+ut/1y0wBSmUrUrvw4s68/nGXZAYN4wJePE=; b=dBxZUwQQ15JvANS/nhpGMx8zo vO7Lc3akIB6Rz4GJzL2tROegeovgDFegJyvXQiKmslh1IuupYOOWCo+DCSKKVXAdKLKU1l3Vfkrxj 4pZjV0G1QO3s4oqMIuCizfTabSyPdrXm7KAHWGUV/r46KXZ6YwmhEZvK9R4vFvNEyozE1tj6oy/Tj +MSt0STaKIwyafkpiZ3nn/oWWLdUYofgtdJHhsoZXGKRFdY8DnEMsOqEw8oeoPY5noIH+vA6pGpbh rO6TGWOhi2CYyzLK1zhdaZKQllx+84QU+aiJqw7bLRI83h4cpngwV4xyW5iKLuzV8VjbAlN4H5EFk oJn5wdh4w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQrOg-0007ZH-UD; Fri, 09 Oct 2020 12:21:18 +0000 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQrOe-0007X2-Gy for linux-arm-kernel@lists.infradead.org; Fri, 09 Oct 2020 12:21:17 +0000 Received: by mail-qt1-x841.google.com with SMTP id a9so7702654qto.11 for ; Fri, 09 Oct 2020 05:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GEBFnNzCc2Aa+VvpaaWfqgqAphuQOGzaQHxTmQfOeXI=; b=dRexUDY3H8MczQ4QLPjINl81RcewsEJoOwrcRnS/wdN6+1ahY+3vJqHFQSRB3AKEat Z5ZaXXZPosq4Wbd2jnV/U3qSyNEiSVNzFD8cJAswQl5FTJES+qJJJxPuS2/N1xstVsKE DmLKmIoNq1PULtGkiX9+m6e1iqZaCGoeY5Z+TbjwSmpmk3vladKQnD3eC3IjfehfAuWk OAoO3ZuMd+rz9DNMaLq4YRdS5/enCBHoI5KrUmpa+3FN6vqOFl+XYKf3xsXAEqCHUZGe a3qzy4AHPVKLKT9jFp2Z0TSDspqDK1w0Z9U5mPCKkR2TBx/oNoqCaY/YIuclFEo3wtty CzGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GEBFnNzCc2Aa+VvpaaWfqgqAphuQOGzaQHxTmQfOeXI=; b=GaKCzPqWiU+tOYTqxc1bZdNMH7rlG391036A+9D1m8z7LzEgERpeYVtDr4FgL1bdk2 RAE0plfvW9xGVnFEx9dTPPF4PHOvaa+vPN3OtRiUZeYevrrYvs5TCuMOQs0uUV/H+edw LY06hLHWXF5ejbisL020Cup/SsfUdKda2W/ArLNs1SMWCzQAIYBm170mlztu4R/F+2vX y9VxtoDTSFUebvdr0TZwFFRI1pKkOCjl1RcsByO1V3qvuatCWimU22LpT1Xp7F8/afkb MSwi3ASAYfRXeLbJB+OefGPFTP08DhiJx4A+wSP7mEwqKNt5ybyYRDTLktuawAqtkBJ2 G/oQ== X-Gm-Message-State: AOAM531QO14uTvjgbby/WVjLne8le0RbOHIgdm+kViICS4c+8CHQRK2B 01qY2Z/MF/gBEw22md0jfIDETw== X-Google-Smtp-Source: ABdhPJxabis31V1ruCjg81xS+awnWmlIxScXs/iSYcl2LZthnsEHjAadouQof92mVKkzbF3fOMDQng== X-Received: by 2002:ac8:1910:: with SMTP id t16mr12554428qtj.351.1602246072505; Fri, 09 Oct 2020 05:21:12 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id x7sm3318061qkc.24.2020.10.09.05.21.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Oct 2020 05:21:11 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kQrOZ-001xjJ-2z; Fri, 09 Oct 2020 09:21:11 -0300 Date: Fri, 9 Oct 2020 09:21:11 -0300 From: Jason Gunthorpe To: Mauro Carvalho Chehab Subject: Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn Message-ID: <20201009122111.GN5177@ziepe.ca> References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-10-daniel.vetter@ffwll.ch> <20201009123421.67a80d72@coco.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201009123421.67a80d72@coco.lan> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201009_082116_606968_2C51E76C X-CRM114-Status: GOOD ( 25.10 ) 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 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. > 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. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 DD972C433E7 for ; Sat, 10 Oct 2020 10:03:16 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 970F921655 for ; Sat, 10 Oct 2020 10:03:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="dRexUDY3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 970F921655 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9043D6EE92; Sat, 10 Oct 2020 10:02:58 +0000 (UTC) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by gabe.freedesktop.org (Postfix) with ESMTPS id 628186ECCC for ; Fri, 9 Oct 2020 12:21:13 +0000 (UTC) Received: by mail-qt1-x844.google.com with SMTP id c5so7729168qtw.3 for ; Fri, 09 Oct 2020 05:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GEBFnNzCc2Aa+VvpaaWfqgqAphuQOGzaQHxTmQfOeXI=; b=dRexUDY3H8MczQ4QLPjINl81RcewsEJoOwrcRnS/wdN6+1ahY+3vJqHFQSRB3AKEat Z5ZaXXZPosq4Wbd2jnV/U3qSyNEiSVNzFD8cJAswQl5FTJES+qJJJxPuS2/N1xstVsKE DmLKmIoNq1PULtGkiX9+m6e1iqZaCGoeY5Z+TbjwSmpmk3vladKQnD3eC3IjfehfAuWk OAoO3ZuMd+rz9DNMaLq4YRdS5/enCBHoI5KrUmpa+3FN6vqOFl+XYKf3xsXAEqCHUZGe a3qzy4AHPVKLKT9jFp2Z0TSDspqDK1w0Z9U5mPCKkR2TBx/oNoqCaY/YIuclFEo3wtty CzGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GEBFnNzCc2Aa+VvpaaWfqgqAphuQOGzaQHxTmQfOeXI=; b=rnwTWrJQHEntf8Vm8CCJiRMBosBIFxq/D3U1+bC+dNjRJAqhqSnXPDPM9U/Wqv9uSl dT6smXaQN8V234zmB0RxUsxDHqdeGPmc5SD1JYUD+23OGUskbHaNXKVFuE0S4sLLAwYl Ojx7xFIQqvAZFJ9O2/h3rqQ3eCIUNnVM2+OOIgx0Pqljrn2u2fOQlIx31E3aIgJpBjKz lRQOxxRL9X8ac1Tqt5/FIvVbQEpAfGkPIDeQWCV3LrWS2fgXVQhxrkB1i7Ne3lOSwGTb ODtz6dblUStaV/W+eTUVc6ExaWqW6/8l4y/sJay8EDkHBDEDZes0N0Z6LR+iWhNMmLjI Ddiw== X-Gm-Message-State: AOAM5335Z5RhIwbkKneO6YHg1Ym3MD+iNpTtA6qG2sBe9SldCnYZuxbf Z0YCtwCM9okJAODlmmlAD2HvJA== X-Google-Smtp-Source: ABdhPJxabis31V1ruCjg81xS+awnWmlIxScXs/iSYcl2LZthnsEHjAadouQof92mVKkzbF3fOMDQng== X-Received: by 2002:ac8:1910:: with SMTP id t16mr12554428qtj.351.1602246072505; Fri, 09 Oct 2020 05:21:12 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id x7sm3318061qkc.24.2020.10.09.05.21.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Oct 2020 05:21:11 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kQrOZ-001xjJ-2z; Fri, 09 Oct 2020 09:21:11 -0300 Date: Fri, 9 Oct 2020 09:21:11 -0300 From: Jason Gunthorpe To: Mauro Carvalho Chehab Subject: Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn Message-ID: <20201009122111.GN5177@ziepe.ca> References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-10-daniel.vetter@ffwll.ch> <20201009123421.67a80d72@coco.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201009123421.67a80d72@coco.lan> X-Mailman-Approved-At: Sat, 10 Oct 2020 10:02:57 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development 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 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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. > 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. Jason _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel