Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2150948pxk; Sat, 19 Sep 2020 14:56:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSAx/B4flEmmiTOTfI+DsFPdnfHGh5CUp0x20/U7ouBvrZhj/72zuEn9R067zBOlWxOHMQ X-Received: by 2002:a17:906:8258:: with SMTP id f24mr41375314ejx.551.1600552599492; Sat, 19 Sep 2020 14:56:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600552599; cv=none; d=google.com; s=arc-20160816; b=bjnFqujOSKWp+sDZNXK4Hcctv37d8crGTvBcuAHRUlEPqnfu8HqIY9A/k60u2jO70K ji62DrfiTv+ebBZHcejKJ8/6wbEVsUAC5G7kgG63PUflGWCxM+NCZTbQLQE+aWQlAlW7 Zt0+XloMWwisoIPCzJ8oRsmu0cajx+Gkh3tJ8IpQCC33dBtKX7a3959EIGsc8AHMlWVV mm2yK7ybXAcoIFU3N3fpRnGvFSq/76JMGfzzUbyLJmHHnGScb6ynovbYVqkr7mJlziUO 0USbvOav8+jm8YHBmeg9+q4UpsNeP5dHDuSSmYXwy8xW9T3fdQI8S/JXDf5eqgWl5gxI zLlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date; bh=iC+AlkwvzQLpOjXi0HFqJxbdCanP6N7lM7zbzmELp5Y=; b=f6qC37SoAIolxTtOCGaprePHVSs4e3JZOPVhRKxWzdofFSH0Kv3sfOBFzCpWVK3+vm HCf5zUxb52MHVJF/TOBud7eOGGmxMydV9VgHO3BCqGoR4n8rxoh+EV0EtOJj+FQa4cKc LZHEKeos3JZW2z//UePULucTG5Udu1wEh4ldICzJAwzaQU00hL31ywLFpONFLGNAf7s6 B9JLdBAIF3zOzCdIsOZHE27cf+2zG7/F0biGHZUjB4vHgdjAGjf/rvw6Nu8Rg1o6m7sD HInRacVt7GTOxYYlHyh9JmPbSvej1eG/d+fY6AjOxSiBKgGSw8VM86L5pcGtHDWIwbZg YfrA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i11si5410811ejv.148.2020.09.19.14.56.14; Sat, 19 Sep 2020 14:56:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726673AbgISVxL (ORCPT + 99 others); Sat, 19 Sep 2020 17:53:11 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:43814 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726582AbgISVxK (ORCPT ); Sat, 19 Sep 2020 17:53:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id C29A129C36; Sat, 19 Sep 2020 17:52:40 -0400 (EDT) Date: Sun, 20 Sep 2020 07:52:38 +1000 (AEST) From: Finn Thain To: Arnd Bergmann cc: Peter Maydell , Andy Lutomirski , Christoph Hellwig , Al Viro , Andrew Morton , Jens Axboe , David Howells , linux-arm-kernel , X86 ML , LKML , "open list:MIPS" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , linux-block , Linux SCSI List , Linux FS Devel , linux-aio , io-uring@vger.kernel.org, linux-arch , Linux-MM , Network Development , keyrings@vger.kernel.org, LSM List Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag In-Reply-To: Message-ID: References: <20200918124533.3487701-1-hch@lst.de> <20200918124533.3487701-2-hch@lst.de> <20200918134012.GY3421308@ZenIV.linux.org.uk> <20200918134406.GA17064@lst.de> <20200918135822.GZ3421308@ZenIV.linux.org.uk> <20200918151615.GA23432@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 19 Sep 2020, Arnd Bergmann wrote: > On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote: > > On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote: > > > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: > > > > Said that, why not provide a variant that would take an explicit > > > > "is it compat" argument and use it there? And have the normal one > > > > pass in_compat_syscall() to that... > > > > > > That would help to not introduce a regression with this series yes. > > > But it wouldn't fix existing bugs when io_uring is used to access > > > read or write methods that use in_compat_syscall(). One example > > > that I recently ran into is drivers/scsi/sg.c. > > Ah, so reading /dev/input/event* would suffer from the same issue, and > that one would in fact be broken by your patch in the hypothetical case > that someone tried to use io_uring to read /dev/input/event on x32... > > For reference, I checked the socket timestamp handling that has a number > of corner cases with time32/time64 formats in compat mode, but none of > those appear to be affected by the problem. > > > Aside from the potentially nasty use of per-task variables, one thing > > I don't like about PF_FORCE_COMPAT is that it's one-way. If we're > > going to have a generic mechanism for this, shouldn't we allow a full > > override of the syscall arch instead of just allowing forcing compat > > so that a compat syscall can do a non-compat operation? > > The only reason it's needed here is that the caller is in a kernel > thread rather than a system call. Are there any possible scenarios where > one would actually need the opposite? > Quite possibly. The ext4 vs. compat getdents bug is still unresolved. Please see, https://lore.kernel.org/lkml/CAFEAcA9W+JK7_TrtTnL1P2ES1knNPJX9wcUvhfLwxLq9augq1w@mail.gmail.com/ > Arnd >