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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, 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 4E893C433E7 for ; Sat, 10 Oct 2020 22:58:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DB0EB2075E for ; Sat, 10 Oct 2020 22:58:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Tn1BNmOZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730410AbgJJW6g (ORCPT ); Sat, 10 Oct 2020 18:58:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731170AbgJJTxO (ORCPT ); Sat, 10 Oct 2020 15:53:14 -0400 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B853C08EA77 for ; Sat, 10 Oct 2020 10:23:03 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id dg9so10300205edb.12 for ; Sat, 10 Oct 2020 10:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AkcMDQ9MzR0MXrPdl4Z5WIlaKuGLuztzGgHABJ/UwRo=; b=Tn1BNmOZPmbfirFetQOYO/ocDzjrlXPQ3LhwSZNpGIDc+8auCeevOxYV9x2mwnL+LJ B1X87tTja6iFvGiJMYchruyGKGyDa2qJyDYXpQ4MO9cDFl66eVBMa7wPbnL2v+lbkE61 A3oosZUv6WC10KVVTloFe7vbgZMt3GHhIV9Zs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AkcMDQ9MzR0MXrPdl4Z5WIlaKuGLuztzGgHABJ/UwRo=; b=fngoOloc0Tl/UeHxePi5izrdMpKTcVLhD3zQP6qR7nlXANW1JKLN3wG099ieZUehTW Nx8z+UBxg81zZ2TB+b7AhpW1FHgwzJI7CGHtmIC2VrRtn0Ef5BLSaI5Si2DGuEUXV04f 4r8N0K0deiUXnIFCU/h3AflsHUG9gCCvj8Ivt7N4lUxTCfigjyz23O9wNkRpiTx4SBJY BeKKoDhSh0w73fmktd57BUJTLq2rLoAqip4I325HfLdnA3e1vC0wwbTNBlDTKVbGPES2 2nhdHi8e1JO4cxCtKV86oDx2imGyj0fbHcQii5yzBHZEYW9EPFARovTOUDNE0XSKhqJw N3FA== X-Gm-Message-State: AOAM5320oUH7dy/8dUEkvfiB26ovXG+ag1HZXWMGPZI8IskteoeY9QWJ tfhcUG0vA3Gu1eNFiKYOzZq3kI02Ikxs8Q== X-Google-Smtp-Source: ABdhPJyisdYM0eadNWJXCt+gwJ6FQ79vdBdSPNfyJ93gVS9wzRA0JTKOvPRJ8qGBYENZGLFPiRF5pA== X-Received: by 2002:aa7:d781:: with SMTP id s1mr5594197edq.102.1602350581743; Sat, 10 Oct 2020 10:23:01 -0700 (PDT) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com. [209.85.128.42]) by smtp.gmail.com with ESMTPSA id m16sm7722480edj.37.2020.10.10.10.22.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2020 10:23:00 -0700 (PDT) Received: by mail-wm1-f42.google.com with SMTP id e23so5856603wme.2 for ; Sat, 10 Oct 2020 10:22:59 -0700 (PDT) X-Received: by 2002:a1c:2d85:: with SMTP id t127mr3480262wmt.22.1602350579384; Sat, 10 Oct 2020 10:22:59 -0700 (PDT) MIME-Version: 1.0 References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-10-daniel.vetter@ffwll.ch> <20201009123421.67a80d72@coco.lan> <20201009122111.GN5177@ziepe.ca> <20201009143723.45609bfb@coco.lan> <20201009124850.GP5177@ziepe.ca> In-Reply-To: From: Tomasz Figa Date: Sat, 10 Oct 2020 19:22:48 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn To: Daniel Vetter Cc: Jason Gunthorpe , Mauro Carvalho Chehab , DRI Development , LKML , KVM list , Linux MM , Linux ARM , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , linux-s390 , Daniel Vetter , Kees Cook , Dan Williams , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, On Fri, Oct 9, 2020 at 7:52 PM Daniel Vetter wrote: > > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote: > > > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > > > 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. > > > > No, it is unconditionally unsafe. The CMA movable mappings are > > specific VMAs that will have bad issues here, but there are other > > types too. > > > > The only way to do something at a VMA level is to have a list of OK > > VMAs, eg because they were creatd via a special mmap helper from the > > media subsystem. > > > > > 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. > > > > It doesn't matter, nothing prevents the user from calling media APIs > > on mmaps it gets from other subsystems. > > I think a good first step would be to disable userptr of non struct > page backed storage going forward for any new hw support. Even on > existing drivers. dma-buf sharing has been around for long enough now > that this shouldn't be a problem. Unfortunately right now this doesn't > seem to exist, so the entire problem keeps getting perpetuated. > > > > 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. > > > > We can't tell from the VMA these kinds of details.. > > > > It has to go the other direction, evey mmap that might be used as a > > userptr here has to be found and the VMA specially created to allow > > its use. At least that is a kernel only change, but will need people > > with the HW to do this work. > > I think the only reasonable way to keep this working is: > - add a struct dma_buf *vma_tryget_dma_buf(struct vm_area_struct *vma); > - add dma-buf export support to fbdev and v4l I assume you mean V4L2 and not the obsolete V4L that is emulated in the userspace by libv4l. If so, every video device that uses videobuf2 gets DMA-buf export for free and there is nothing needed to enable it. We probably still have a few legacy drivers using videobuf (non-2), but IMHO those should be safe to put behind some disabled-by-default Kconfig symbol or even completely drop, as the legacy framework has been deprecated for many years already. > - roll this out everywhere we still need it. > > Realistically this just isn't going to happen. And anything else just > reimplements half of dma-buf, which is kinda pointless (you need > minimally refcounting and some way to get at a promise of a permanent > sg list for dma. Plus probably the vmap for kernel cpu access. > > > > Please let address the issue on this way, instead of broken an > > > userspace API that it is there since 1991. > > > > It has happened before :( It took 4 years for RDMA to undo the uAPI > > breakage caused by a security fix for something that was a 15 years > > old bug. > > Yeah we have a bunch of these on the drm side too. Some of them are > really just "you have to upgrade userspace", and there's no real fix > for the security nightmare without that. I think we need to phase out such userspace indeed. The Kconfig symbol allows enabling the unsafe functionality for anyone who still needs it, so I think it's not entirely a breakage. Best regards, Tomasz 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 34C19C433E7 for ; Sat, 10 Oct 2020 17:33:43 +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 CC8822245F for ; Sat, 10 Oct 2020 17:33:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="I4Fg46fm"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Tn1BNmOZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC8822245F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UeaJJgTxUh8phyhHhJauYEQw695IDOHUK76H1KkuqD4=; b=I4Fg46fmcVdMwVQEaDXLsRlei stFolcL0hYeKPsBp2wTzWlb8Zn3bMXD8QRq743cDhPbpSkvbZoXs0YfpEooIJcNT7X11MGMGOShgx kowt+c9dBEJskZgTkGO+iepVppky8k0ao1/3B/bj1XtJI+1CbCUxWYRIIF70CMeLBkYN4MLuYdwWa P8mj6bPhgIVmTsQsTHYE0EunF4W3IGeaimbfrE/5CicDIKhVABZqMmLp5OeNYvpKMbmZN9TJ6JJeG 6L5e8xLFsuBHokURw8bx+64GcF91LC2RvfoeWXolW0ae6gfMB2TFgeCvwT3Dd3Um7yxbpyBOZ/Hqh cOMIwrSpw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kRIhf-0004gH-T7; Sat, 10 Oct 2020 17:30:44 +0000 Received: from mail-ej1-x643.google.com ([2a00:1450:4864:20::643]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kRIhc-0004fC-DW for linux-arm-kernel@lists.infradead.org; Sat, 10 Oct 2020 17:30:41 +0000 Received: by mail-ej1-x643.google.com with SMTP id e22so17597516ejr.4 for ; Sat, 10 Oct 2020 10:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AkcMDQ9MzR0MXrPdl4Z5WIlaKuGLuztzGgHABJ/UwRo=; b=Tn1BNmOZPmbfirFetQOYO/ocDzjrlXPQ3LhwSZNpGIDc+8auCeevOxYV9x2mwnL+LJ B1X87tTja6iFvGiJMYchruyGKGyDa2qJyDYXpQ4MO9cDFl66eVBMa7wPbnL2v+lbkE61 A3oosZUv6WC10KVVTloFe7vbgZMt3GHhIV9Zs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AkcMDQ9MzR0MXrPdl4Z5WIlaKuGLuztzGgHABJ/UwRo=; b=NZFcyIuGsOp+e0rLbSMiBJrABolyMoKJuAdj3q/ELj66PpbSFBPJNnKKbQVEpjoTdb Hwml2yUMirY0OObmu1kAdj9X9G8hzhDnO7vXwoqfFeRwYXBpAeHTTpjSF0MKyUV8hNRC VuA7Awo+PJcQrAt4LovJHWAWtkDJcj7NecQXB5H5KlICSdlhbzUSam2QflpiP52EiBcK oTLwrHupxj7JwqmT15k6Iy1tdZ5wkgs8eAfca5IsTkGHDyzI1gFegH+AUd1NnqImTMwF KS792coAemVVEeJJ6EgLpEr4p7lzInugSVvmrWvlvZjOeRkPZrcSqlhjftJYvhb8syU+ hITw== X-Gm-Message-State: AOAM5330gk4JcylXJ2ZExsRbRsmQmQ5me1pf8bcZw6dROTsIGc66PFjW uGPwS06Kd2DoQy4f9Iqa5MmpAcQCqrAuQQ== X-Google-Smtp-Source: ABdhPJylHYJ92d40ziGeU/1ZDBETstqfL/4rXtDkFqvHeSp69b+Nlz379zZFfjK41vK1vtK+Dr0GKg== X-Received: by 2002:a17:906:1c8f:: with SMTP id g15mr19815563ejh.179.1602351036988; Sat, 10 Oct 2020 10:30:36 -0700 (PDT) Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com. [209.85.128.47]) by smtp.gmail.com with ESMTPSA id j11sm8263761ejk.63.2020.10.10.10.30.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2020 10:30:36 -0700 (PDT) Received: by mail-wm1-f47.google.com with SMTP id 13so12901474wmf.0 for ; Sat, 10 Oct 2020 10:30:36 -0700 (PDT) X-Received: by 2002:a1c:2d85:: with SMTP id t127mr3480262wmt.22.1602350579384; Sat, 10 Oct 2020 10:22:59 -0700 (PDT) MIME-Version: 1.0 References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-10-daniel.vetter@ffwll.ch> <20201009123421.67a80d72@coco.lan> <20201009122111.GN5177@ziepe.ca> <20201009143723.45609bfb@coco.lan> <20201009124850.GP5177@ziepe.ca> In-Reply-To: From: Tomasz Figa Date: Sat, 10 Oct 2020 19:22:48 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn To: Daniel Vetter X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201010_133040_510531_D9B17391 X-CRM114-Status: GOOD ( 40.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 , linux-samsung-soc , Jan Kara , Kees Cook , KVM list , Linux MM , Mauro Carvalho Chehab , John Hubbard , LKML , DRI Development , Jason Gunthorpe , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Daniel Vetter , Dan Williams , Linus Torvalds , Andrew Morton , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" 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 Hi Daniel, On Fri, Oct 9, 2020 at 7:52 PM Daniel Vetter wrote: > > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote: > > > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > > > 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. > > > > No, it is unconditionally unsafe. The CMA movable mappings are > > specific VMAs that will have bad issues here, but there are other > > types too. > > > > The only way to do something at a VMA level is to have a list of OK > > VMAs, eg because they were creatd via a special mmap helper from the > > media subsystem. > > > > > 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. > > > > It doesn't matter, nothing prevents the user from calling media APIs > > on mmaps it gets from other subsystems. > > I think a good first step would be to disable userptr of non struct > page backed storage going forward for any new hw support. Even on > existing drivers. dma-buf sharing has been around for long enough now > that this shouldn't be a problem. Unfortunately right now this doesn't > seem to exist, so the entire problem keeps getting perpetuated. > > > > 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. > > > > We can't tell from the VMA these kinds of details.. > > > > It has to go the other direction, evey mmap that might be used as a > > userptr here has to be found and the VMA specially created to allow > > its use. At least that is a kernel only change, but will need people > > with the HW to do this work. > > I think the only reasonable way to keep this working is: > - add a struct dma_buf *vma_tryget_dma_buf(struct vm_area_struct *vma); > - add dma-buf export support to fbdev and v4l I assume you mean V4L2 and not the obsolete V4L that is emulated in the userspace by libv4l. If so, every video device that uses videobuf2 gets DMA-buf export for free and there is nothing needed to enable it. We probably still have a few legacy drivers using videobuf (non-2), but IMHO those should be safe to put behind some disabled-by-default Kconfig symbol or even completely drop, as the legacy framework has been deprecated for many years already. > - roll this out everywhere we still need it. > > Realistically this just isn't going to happen. And anything else just > reimplements half of dma-buf, which is kinda pointless (you need > minimally refcounting and some way to get at a promise of a permanent > sg list for dma. Plus probably the vmap for kernel cpu access. > > > > Please let address the issue on this way, instead of broken an > > > userspace API that it is there since 1991. > > > > It has happened before :( It took 4 years for RDMA to undo the uAPI > > breakage caused by a security fix for something that was a 15 years > > old bug. > > Yeah we have a bunch of these on the drm side too. Some of them are > really just "you have to upgrade userspace", and there's no real fix > for the security nightmare without that. I think we need to phase out such userspace indeed. The Kconfig symbol allows enabling the unsafe functionality for anyone who still needs it, so I think it's not entirely a breakage. Best regards, Tomasz _______________________________________________ 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 01A9EC433E7 for ; Sat, 10 Oct 2020 17:23:06 +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 8F8142245C for ; Sat, 10 Oct 2020 17:23:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Tn1BNmOZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F8142245C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 1E6046F393; Sat, 10 Oct 2020 17:23:05 +0000 (UTC) Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by gabe.freedesktop.org (Postfix) with ESMTPS id E59336F393 for ; Sat, 10 Oct 2020 17:23:03 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id l16so12677511eds.3 for ; Sat, 10 Oct 2020 10:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AkcMDQ9MzR0MXrPdl4Z5WIlaKuGLuztzGgHABJ/UwRo=; b=Tn1BNmOZPmbfirFetQOYO/ocDzjrlXPQ3LhwSZNpGIDc+8auCeevOxYV9x2mwnL+LJ B1X87tTja6iFvGiJMYchruyGKGyDa2qJyDYXpQ4MO9cDFl66eVBMa7wPbnL2v+lbkE61 A3oosZUv6WC10KVVTloFe7vbgZMt3GHhIV9Zs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AkcMDQ9MzR0MXrPdl4Z5WIlaKuGLuztzGgHABJ/UwRo=; b=CiCBIij1p6gDPVsq7S1xHtE+ua0xnRPR/FvHxJmmi6E5xkj7qoq4+qNFKX5PfFtR/G P3TZN/SRLTBm8Xj89WYSFc1iESV1m1GYhmKK56M2Iy8gj6KDLYxEyjWoIsNB6oQNUM5V hE0k3Y6Dj1f2ihwR3bIkd0R/aHLawhELQUTFudJUasO4xvJqxBAR8M972eUowoVKf5SA CpLjdZrQo1vM3K32XcrE1nmvGdedZ9B55GxOFP3lbjJ4AQ7ACnBtDlT1xeehH511ZyWa AUCiHqvjr3zM6kHaSXEo9O1lGITYhkgX8rbJtnLsYjztfnTmJ3Jel++k5s0w2Sivcw+T ffug== X-Gm-Message-State: AOAM533N+vpM/sRLlQx7F0Wc5+HJskg21RGhoYKGkiJPIT9i06wcGV3j 7hti3n9jvLEWhXsaMOJW3B/3rF6SpB3Deg== X-Google-Smtp-Source: ABdhPJx9+4xnHaxtLbNmLjAadq/3nTgcio5vmW56/WUn2R4jwMYIPoiKXf5iMPheV6y9QeSceJV4Ew== X-Received: by 2002:a50:fb16:: with SMTP id d22mr5258844edq.255.1602350582082; Sat, 10 Oct 2020 10:23:02 -0700 (PDT) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com. [209.85.128.41]) by smtp.gmail.com with ESMTPSA id a22sm8147316ejs.25.2020.10.10.10.22.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Oct 2020 10:23:00 -0700 (PDT) Received: by mail-wm1-f41.google.com with SMTP id d3so12837851wma.4 for ; Sat, 10 Oct 2020 10:22:59 -0700 (PDT) X-Received: by 2002:a1c:2d85:: with SMTP id t127mr3480262wmt.22.1602350579384; Sat, 10 Oct 2020 10:22:59 -0700 (PDT) MIME-Version: 1.0 References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-10-daniel.vetter@ffwll.ch> <20201009123421.67a80d72@coco.lan> <20201009122111.GN5177@ziepe.ca> <20201009143723.45609bfb@coco.lan> <20201009124850.GP5177@ziepe.ca> In-Reply-To: From: Tomasz Figa Date: Sat, 10 Oct 2020 19:22:48 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn To: Daniel Vetter 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 , linux-samsung-soc , Jan Kara , Kees Cook , KVM list , Linux MM , Mauro Carvalho Chehab , John Hubbard , LKML , DRI Development , Jason Gunthorpe , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Daniel Vetter , Dan Williams , Linus Torvalds , Andrew Morton , Linux ARM , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Daniel, On Fri, Oct 9, 2020 at 7:52 PM Daniel Vetter wrote: > > On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote: > > > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > > > 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. > > > > No, it is unconditionally unsafe. The CMA movable mappings are > > specific VMAs that will have bad issues here, but there are other > > types too. > > > > The only way to do something at a VMA level is to have a list of OK > > VMAs, eg because they were creatd via a special mmap helper from the > > media subsystem. > > > > > 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. > > > > It doesn't matter, nothing prevents the user from calling media APIs > > on mmaps it gets from other subsystems. > > I think a good first step would be to disable userptr of non struct > page backed storage going forward for any new hw support. Even on > existing drivers. dma-buf sharing has been around for long enough now > that this shouldn't be a problem. Unfortunately right now this doesn't > seem to exist, so the entire problem keeps getting perpetuated. > > > > 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. > > > > We can't tell from the VMA these kinds of details.. > > > > It has to go the other direction, evey mmap that might be used as a > > userptr here has to be found and the VMA specially created to allow > > its use. At least that is a kernel only change, but will need people > > with the HW to do this work. > > I think the only reasonable way to keep this working is: > - add a struct dma_buf *vma_tryget_dma_buf(struct vm_area_struct *vma); > - add dma-buf export support to fbdev and v4l I assume you mean V4L2 and not the obsolete V4L that is emulated in the userspace by libv4l. If so, every video device that uses videobuf2 gets DMA-buf export for free and there is nothing needed to enable it. We probably still have a few legacy drivers using videobuf (non-2), but IMHO those should be safe to put behind some disabled-by-default Kconfig symbol or even completely drop, as the legacy framework has been deprecated for many years already. > - roll this out everywhere we still need it. > > Realistically this just isn't going to happen. And anything else just > reimplements half of dma-buf, which is kinda pointless (you need > minimally refcounting and some way to get at a promise of a permanent > sg list for dma. Plus probably the vmap for kernel cpu access. > > > > Please let address the issue on this way, instead of broken an > > > userspace API that it is there since 1991. > > > > It has happened before :( It took 4 years for RDMA to undo the uAPI > > breakage caused by a security fix for something that was a 15 years > > old bug. > > Yeah we have a bunch of these on the drm side too. Some of them are > really just "you have to upgrade userspace", and there's no real fix > for the security nightmare without that. I think we need to phase out such userspace indeed. The Kconfig symbol allows enabling the unsafe functionality for anyone who still needs it, so I think it's not entirely a breakage. Best regards, Tomasz _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel