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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 AD8D2C433E8 for ; Mon, 29 Jun 2020 19:07:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9308220663 for ; Mon, 29 Jun 2020 19:07:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730559AbgF2THA (ORCPT ); Mon, 29 Jun 2020 15:07:00 -0400 Received: from verein.lst.de ([213.95.11.211]:59051 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730481AbgF2TGf (ORCPT ); Mon, 29 Jun 2020 15:06:35 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 1ED6168C65; Mon, 29 Jun 2020 17:29:13 +0200 (CEST) Date: Mon, 29 Jun 2020 17:29:12 +0200 From: Christoph Hellwig To: Linus Torvalds Cc: David Laight , Christoph Hellwig , Al Viro , Luis Chamberlain , Kees Cook , Iurii Zaikin , Linux Kernel Mailing List , linux-fsdevel Subject: Re: [PATCH 03/11] fs: add new read_uptr and write_uptr file operations Message-ID: <20200629152912.GA26172@lst.de> References: <20200624162901.1814136-1-hch@lst.de> <20200624162901.1814136-4-hch@lst.de> <20200624175548.GA25939@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 27, 2020 at 09:33:03AM -0700, Linus Torvalds wrote: > I thought there was just one very specific case of "oh, in certain > cases of setsockopt we don't know what size this address is and optlen > is ignored", so we have to just pass the pointer down to the protocol, > which is the point that knows how much of an address it wants.. The setsock issue is a little more complicated. Let me try to summarize it: - setsock takes a (user) pointer and len - unfortunately while the designed of the BSD socket API designed the len to be correct some protocol implementations have been sloppy and just use a hardcoded len for the value plus some other funnies - unfortunately there is some BPF magic that can attach to a socket and be run, and that (and only that in the latest kernel) can cause a setsockopt to take a kernel buffer. One that was copied from userspace earlier and had the BPF program run on it. - unfortunately we have about 90 ->setsockopt instances, and the BPF hook is not specific to one particular of them. In fact the BPF program can run for options that don't even exist, and based on my previous dicussion Facebook has setups that rely on that. > Was that a misunderstanding on my part? > > Because if there are tons and tons of places that want this "either > kernel or user" then we could still have a helper function for it, but > it means that the whole "limit the cases" advantage to some degree > goes away. But except for setsockopt we don't really have anything like that left. There is some alpha arch code that would need to be duplicated for user vs kernel pointers, but I suspect it will get cleaner by that, and the messy s390 crypto driver whіch will be a bit of work, but all internal to that driver. So based on that I'd rather get away without our flag and tag the kernel pointer case in setsockopt explicitly.