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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23BC7C77B61 for ; Fri, 28 Apr 2023 15:41:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A66CB6B0075; Fri, 28 Apr 2023 11:41:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EF656B0078; Fri, 28 Apr 2023 11:41:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 88F456B0082; Fri, 28 Apr 2023 11:41:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 794146B0075 for ; Fri, 28 Apr 2023 11:41:56 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 55BEBC0276 for ; Fri, 28 Apr 2023 15:41:56 +0000 (UTC) X-FDA: 80731215432.16.CEDDF94 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 20C24C001C for ; Fri, 28 Apr 2023 15:41:53 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PHT4vS2P; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682696514; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1H9pPvEM+Js8vhAavaMMOgoamiyAYwUIQKWzoU2WpOs=; b=i4RQNZlzAjNpOKtpQe6kY3GLD/hdeDQ9hnwN6gl2b1qThM/YUixO7eAObNwmPBqdcLU8R3 T9DQ6A6pneYh/an8iHm/SshcWUvl25Vcd2Cg7tUW28ZFfyFEwki4mhjcM6k49YNpMI7Wvt wL2JHN0N0pYjwRKim76ZKUlcMUHdLTI= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PHT4vS2P; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682696514; a=rsa-sha256; cv=none; b=fLhx9HLd5fyqA9IBV1SaL21Gl3CYO0sUdZPa1VMUPTswH0D1t+86cATcnXmULlNJ/LLfVA ei1lakInOT8UUH/DvBErBI3ypu8bM7b7QHF7mFWz2pdGq+Qb4gX6GBcn4q/dsKFWe6NVSZ IFmTWe/8RqqJ1I7GzY2jCpSt5nv2X4Y= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682696513; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1H9pPvEM+Js8vhAavaMMOgoamiyAYwUIQKWzoU2WpOs=; b=PHT4vS2P+kpstUg4mOM+q9zHUD4Gt8ZtSJ9v2TkP1JYDy7pydXXbCpMxMaLhexN/YdlMnA KAALAr4pw4+oI76ylBJSLkyRyR/v2i3YD2vWw2pAve5D9p7P/5biR2cd04H4xUcrdfM+/C tSUJ1VDY1A6HpUg/yHwS+g8cMpVbPkg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-326-Ko7HTvSHPd6bz2gfJYGcPw-1; Fri, 28 Apr 2023 11:41:46 -0400 X-MC-Unique: Ko7HTvSHPd6bz2gfJYGcPw-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-3f173bd0d1bso64519525e9.3 for ; Fri, 28 Apr 2023 08:41:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682696497; x=1685288497; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1H9pPvEM+Js8vhAavaMMOgoamiyAYwUIQKWzoU2WpOs=; b=jYTOJI50klRwQN4FiUI2ct8hmRVhcHcyA4pKoHjVXGQDRQaz6GZBqFfDqU5t/RCa1d 4jjhjulscsjhg611MRlGP25zbGp30TQVUlsm4z9c2V+V8IOgjAli9e57MCTDwMjrtxM1 j2rXV/OOpOajmM9jsH8TZMjV3QiW6bhYfL7yFLBIZxjNWe8kOVszlCVSbhrXT92ocDz2 5T/QDPOD7MjSa5diFeY4byPgo+v9A7I/QkY7MbdleeNX8SlQVNl4t6k3VcVFq5k4lG6Y YOSEgWaKE6M8HKjK3ygUJHkd+EdJrZnPtOqDLiTM28o8QoP7Ww+S17dR38AW2CaYaf7o qgxQ== X-Gm-Message-State: AC+VfDzP626EU9hurRYc8EtPhefPyyyP/22lFyKNF6ek7AH84i11vNyp 0Uyvp+vx3zmhkZ4gOlKuDyx3TQUgbg9h0DLT7O9F7gPlmnBOaBbOU5VQ7fURoJc2NEwqb5OgXd4 cjm6lxq7hhBM= X-Received: by 2002:a1c:ed0e:0:b0:3f2:5999:4f2b with SMTP id l14-20020a1ced0e000000b003f259994f2bmr4546891wmh.33.1682696497202; Fri, 28 Apr 2023 08:41:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7+nd0elYn4hmRLxdtWbwWjgrHCODyP2os9nbfNCf2KA/02ixLHWZjvg+Rr1dUNu/tXPRuH2w== X-Received: by 2002:a1c:ed0e:0:b0:3f2:5999:4f2b with SMTP id l14-20020a1ced0e000000b003f259994f2bmr4546874wmh.33.1682696496848; Fri, 28 Apr 2023 08:41:36 -0700 (PDT) Received: from ?IPV6:2003:cb:c726:9300:1711:356:6550:7502? (p200300cbc72693001711035665507502.dip0.t-ipconnect.de. [2003:cb:c726:9300:1711:356:6550:7502]) by smtp.gmail.com with ESMTPSA id r6-20020a05600c458600b003f195d540d9sm20569992wmo.14.2023.04.28.08.41.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Apr 2023 08:41:36 -0700 (PDT) Message-ID: <3f97c798-3598-1729-1981-ab8acb7b5663@redhat.com> Date: Fri, 28 Apr 2023 17:41:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: Jason Gunthorpe Cc: Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Jens Axboe , Matthew Wilcox , Dennis Dalessandro , Leon Romanovsky , Christian Benvenuti , Nelson Escobar , Bernard Metzler , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Bjorn Topel , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Brauner , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Oleg Nesterov , John Hubbard , Jan Kara , "Kirill A . Shutemov" , Pavel Begunkov , Mika Penttila , David Howells , Christoph Hellwig References: <6b73e692c2929dc4613af711bdf92e2ec1956a66.1682638385.git.lstoakes@gmail.com> <094d2074-5b69-5d61-07f7-9f962014fa68@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v5] mm/gup: disallow GUP writing to file-backed mappings by default In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 20C24C001C X-Stat-Signature: zxsor1zntxyydy5fqa3qkp7ikk686zgp X-HE-Tag: 1682696513-49281 X-HE-Meta: U2FsdGVkX188j0YO+Ayo9jv0ADhT8q9xyl+IfxIW5e3Ps3QRuzIy6FTkR9TBxzFSnfnvkIr3Uzbo6fGP8F7/wR8BcNW7sLyYwoFWu/WyxyMgXT/Ro+i6u6BgNfFQ8huDfTfLiIHmmAPrFKVDUJskMeeAJqDhQ9bttF/3MvZ74531kyU5gWDgdm05SSbyNbPw+DuH8tz/L4OpsGywoHrdwhXJVONryMAy4N9PHSWj9E9K7F7sxpSQEqENsIgeHQf4JrC0XX19GEGZuopltZS+e1DwM95Tl1r4yKcNVe0SYrSWJd7+nd7YqBQ/MPuUhR1A72H4+rgGDI6bDE1hdrIhENNp3WH2Wkfvyuvm+Lr6Eya9Yya9bDbHaAsVnW65k7/wbrM6QPzn1xmckY4vTHhX6tWNjFsXv8xVBYvyMSm9g4BDlCTGHSl1wIJPCzn8SBBHdTcMVW/qhwwjjC+Skb6/c0kFL7nZi1XneMZBHiJB8KNHFphqwsKmYI5Izc/69lPQKB49+hjqSAKOz8YskL0RxGcvLdfOOLvYsUFYGE3QAfiYtedTczFfHGgVx5u9J33Zh3WMqYyZwYWXPzWywhelO6Kqz4q6zaebswmCTccKBikk7RP1gjKQGGFEFuXttoE0sUpYdqCZsk5z4TB8kNw9h3Clu5arfWopJXeFaN2LVjGFS+kdvR2fDpag655HIfP6JFTed55SM5KbhgeE2/21aKTbEGyWP2VJcBWiURlSqCPvvpdzfbT0g+UevEYLwTI2abNaU6TIC2LvmX0GDUF8+N8qp9DoS4qN7+srL4V78meG8IVG0T/mpK5SEFLOMGwCOcOSHNj0VV3ECGpvcJDVfKXlwFm3mXSNKSaGXvSMG5L2ZD9Yu6bzn4QI7g0ijMNyFpBh2E38iUG+XlF92LAAOZCGB+7tbk1Y44+HxMWe3EITIeooPvcnjA57lDGqH/pi2KaWCmJFLKl5sc94Was lzSwqRko kz1PgL6oYs43/bO/jhVdKrY10QmnOKzSYoyunaOm7W+ebzV9NHikp/o8M6MEx4+/ns0+CCAzcweb8fQ2n9Kbwu4udUJOZMplsB2lr6VO7+zjPsU7ru+zvscuuG1XZXWFVgDJ82oNxOUmx3MGhlR6IJHaPKhzTHlSbdAxfbNJvE73f7kn0PT7vScxK3icn3jj9OeuzuyQ6yTLcNjKeM9Dbt4tuxwye3oU8mCl/INwDGhMyynfbXwv/43T3MXAUuvS/my64HeHSEeITUH1jATi292nq8wftCOc1KgtK38VIxvtvuvFF3GCmMIuaquM9H1aFTZ5iVZcuMrx4Dv0PjKYp/MUnHCyIxxrOUfnaliVf6MqKglXXDq/0LFl1Z6VxEeDdbFyNGdFH/zY/afl/1vu9sxXC6nm8XF+DGA6f1nQQjBCgUvGr9dFotqU30/B5wtJFD/Z5LjQHxQ+qWkU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 28.04.23 17:27, Jason Gunthorpe wrote: > On Fri, Apr 28, 2023 at 05:08:27PM +0200, David Hildenbrand wrote: > >>> I think this is broken today and we should block it. We know from >>> experiments with RDMA that doing exactly this triggers kernel oop's. >> >> I never saw similar reports in the wild (especially targeted at RHEL), so is >> this still a current issue that has not been mitigated? Or is it just so >> hard to actually trigger? > > People send RDMA related bug reports to us, and we tell them not to do > this stuff :) > >>> I'm skeptical that anyone can actually do this combination of things >>> successfully without getting kernel crashes or file data corruption - >>> ie there is no real user to break. >> >> I am pretty sure that there are such VM users, because on the libvirt level >> it's completely unclear which features trigger what behavior :/ > > IDK, why on earth would anyone want to do this? Using VFIO forces all > the memory to become resident so what was the point of making it file > backed in the first place? As I said, copy-and paste, incremental changes to domain XMLs. I've seen some crazy domain XMLs in bug reports. > > I'm skeptical there are real users even if it now requires special > steps to be crashy/corrupty. In any case, I think we should document the possible implications of this patch. I gave one use case that could be broken. > >>>> Sure, we could warn, or convert individual users using a flag (io_uring). >>>> But maybe we should invest more energy on a fix? >>> >>> It has been years now, I think we need to admit a fix is still years >>> away. Blocking the security problem may even motivate more people to >>> work on a fix. >> >> Maybe we should make this a topic this year at LSF/MM (again?). At least we >> learned a lot about GUP, what might work, what might not work, and got a >> depper understanding (+ motivation to fix? :) ) the issue at hand. > > We keep having the topic.. This is the old argument that the FS people > say the MM isn't following its inode and dirty lifetime rules and the > MM people say the FS isn't following its refcounting rules :/ so we have to discuss it ... again I guess. > >>> Security is the primary case where we have historically closed uAPI >>> items. >> >> As this patch >> >> 1) Does not tackle GUP-fast >> 2) Does not take care of !FOLL_LONGTERM >> >> I am not convinced by the security argument in regard to this patch. > > It is incremental and a temperature check to see what kind of real > users exist. We have no idea right now, just speculation. Right, but again, if we start talking about security it's a different thing IMHO. >> Everything else sounds like band-aids to me, is insufficient, and might >> cause more harm than actually help IMHO. Especially the gup-fast case is >> extremely easy to work-around in malicious user space. > > It is true this patch should probably block gup_fast when using > FOLL_LONGTERM as well, just like we used to do for the DAX check. Then we'd at least fix the security issue for all FOLL_LONGTERM completely. -- Thanks, David / dhildenb