Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3393020imu; Mon, 19 Nov 2018 15:29:47 -0800 (PST) X-Google-Smtp-Source: AJdET5eTOH4UGeEfOO4nuV621bYsB3JU/6MMN4FK66GBclSIiHUT+gD3iCsrgbJnpailGBKFPJs3 X-Received: by 2002:a62:dbc2:: with SMTP id f185mr13408122pfg.235.1542670187809; Mon, 19 Nov 2018 15:29:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542670187; cv=none; d=google.com; s=arc-20160816; b=LQu0ZujOc0pjtRz6qChvK/K9aUonWInRWzjYFeSadtfoWnc6YrlIOtFdRwrMoiSoZH 1nRXOEYeB8qzARop7PhaKjrwDeKusgkY8jXgI2R1R+pVdhH+iY0n4kUXf52dM4Jbch6H oQjZIZyhL0VZ1FDXGK1AMf9h5BQ+xsn27GZR9inhN887rSVh3r3DHfZ60UTq2iI4Th4E LCB2LHwim2eagx6YS1YOfX7az/SDY8rsdvNFcq8wdqJuIU/vhITeTwzSdjNk3B0tKuyr 0Gxpk+pzN9LfbX8IQ/G+UNshNqXwG1mkfE8STIW+t+CjuhVcU/4pBSquxttXuFlZRIBQ 65MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=FTrqOBzCYW0EqmnRSq/KX6M623z4yUnSrlisGH7jWSk=; b=Qkcakn7xLdqEJunSZ872cbLEMQXDnckumfCsjWMd9CJzuexM3NSt+B5802v8mn6R3l mljyg+mc6dbbK7Mqi+mtjoIdfFwNgFj6jeZJ7J2i28tv+cHDXkcudPLukxS4YuYqvCKv 7AdzE9nnGHy3BefqYHZk+rlV+3sFRGlfbGPFo764Yk4vy2qFx4dYVHuyRWwQvNSwndg/ rKwbk6iYsULyGhDoMV9eBi5LntSzC0a9DRVRdsdCe4qoOYdLcwuTP3f8yScRCC7/FnT2 gJ5298l3CSoA+2Cq63YlLg8Cr3vD28aHSUQS/5eGeiXyO+qU30UOys98FhD+Uc4jmnU8 dkEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Hs7UApHA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p18si38329727pgb.469.2018.11.19.15.29.19; Mon, 19 Nov 2018 15:29:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Hs7UApHA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731905AbeKTJP3 (ORCPT + 99 others); Tue, 20 Nov 2018 04:15:29 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:42993 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730419AbeKTJP3 (ORCPT ); Tue, 20 Nov 2018 04:15:29 -0500 Received: by mail-ot1-f66.google.com with SMTP id n46so29235543otb.9 for ; Mon, 19 Nov 2018 14:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FTrqOBzCYW0EqmnRSq/KX6M623z4yUnSrlisGH7jWSk=; b=Hs7UApHA4lHIKAMiNHV8QeAwHFUCpL0TKvKBsmn4kSNY6p01JTJ1QdoqdtNfjP5oz4 DR6pq+ATuYOh75ch+iGdBPdjTJJEET+syVJvghk7Kov3Aml0cSQpHAkmIMVYGv879a+U RekhOiTPNsPJM3Iy/xxpdl625Ks3vEifQY1AMqnm4j+USCBNrXrdgDFIyPylhCcw7gl8 /KBY4xDP7/AvveyIt8zMHc5/QEMHkv/OskeNa2XbTzH/ARbnQGO1fNQPfdjUdULDp4LN w4VVrVDrimlZtC9S6s4WaPBV601+vGjHxMc26WABzRyEp6zYM+0f3pGkFE0fqIEIG/09 DhyA== 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=FTrqOBzCYW0EqmnRSq/KX6M623z4yUnSrlisGH7jWSk=; b=M+sxHqtTFuX+xzRug5b4h7ivXRTCR6qE5D85zceKCuUr2Yp/zBnMRvNjL+PIMxKPoE fvKu+XU7UhiZMylmXpDX6E8nyOVZDoqd0USDPLH0aX//gsDxDTImiiz8+iF3qwt9XQuS OAeybpo+K0XazO0EPuPxgqECK0WhAysy/Ju6D+03YMC40YbfT+6RgtCDSKV56zaDcxu/ fNqLgwIo0ztqah7PPvN817yTcULasFC1cjqSdHqYlBjQMPKUp5y/yjrg02fWrOSGnJkT O5CpIj8Z0FJWAvEKm9hDIt/HxQl5amUHZhlI1I7TZBY2TukLhm1daMunMTfYS2wTfHV/ 9X3Q== X-Gm-Message-State: AGRZ1gLNexaYHiGDeA8TmrB4amSE7AkA7eBDSMNkE/F3vQQdHZNFU/b4 863nB29JdFV0QUzo+psGgLRvk7ug8/kF/uF302qfaQ== X-Received: by 2002:a9d:12d:: with SMTP id 42mr13623236otu.352.1542667774520; Mon, 19 Nov 2018 14:49:34 -0800 (PST) MIME-Version: 1.0 References: <20181119103241.5229-1-christian@brauner.io> <20181119103241.5229-3-christian@brauner.io> <20181119223954.GA4992@cisco> In-Reply-To: <20181119223954.GA4992@cisco> From: Daniel Colascione Date: Mon, 19 Nov 2018 14:49:22 -0800 Message-ID: Subject: Re: [PATCH v1 2/2] signal: add procfd_signal() syscall To: Tycho Andersen Cc: Christian Brauner , "Eric W. Biederman" , linux-kernel , "Serge E. Hallyn" , Jann Horn , Andy Lutomirski , Andrew Morton , Oleg Nesterov , Aleksa Sarai , Al Viro , Linux FS Devel , Linux API , Tim Murray , linux-man , Kees Cook Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 19, 2018 at 2:40 PM Tycho Andersen wrote: > Can I just register an objection here that I think using a syscall > just for this is silly? Yes, you can argue that the bikeshed should be ioctl-colored and not syscall-colored. > My understanding is that the concern is that some code might do: > > unknown_fd = recv_fd(); > ioctl(unknown_fd, SOME_IOCTL, NULL); // where SOME_IOCTL == PROC_FD_KILL > // whoops, unknown_fd was a procfd and we killed a task! > > In my experience when writing fd sending/receiving code, the sender and > receiver are fairly tightly coupled. Has anyone ever actually fixed a > bug where they had an fd that they lost track of what "type" it was > and screwed up like this? It seems completely theoretical to me. Yes, I have fixed bugs of this form. > The ioctl() approach has the benefit of being extensible. The system call table is also extensible. ioctl is for when a given piece of functionality *can't* realistically get its own system call because it's separated from the main kernel somehow. procfs is a core part of the kernel, so we can and should expose interfaces to it using system calls. > Adding a > syscall means that everyone has to do all the boilerplate for each new > pid op in the kernel, arches, libc, strace, etc. These tools also care about ioctls. Adding a system call is a pain, but the solution is to make adding system calls less of a pain, not to permanently make the Linux ABI worse.