From owner-freebsd-hackers@freebsd.org Tue Mar 26 02:34:25 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E59D9155B662 for ; Tue, 26 Mar 2019 02:34:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 129976EA0D for ; Tue, 26 Mar 2019 02:34:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-it1-x144.google.com with SMTP id h9so17476094itl.1 for ; Mon, 25 Mar 2019 19:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=eCs2d0/NWeiAiEOaiKn0FntyxLRIuNlPvVPrBWn6yMg=; b=ns9fSxQwK5w8oIxlS4XWMsmprD0p3Rrd737oNmYSzQJ+//NUZYbzUf73YlpVJVgmE7 v+Rsd9cTjmG+AWuNyet+qpzHUCSaUupW/Af+PGdglUvaCDWMoL/cQEZsz+dhu16bgiL/ DH6fBx5xQVLQnsGwWMbml8buuSQH7QN3OcWsLOZ9xJboibDLhRXEKA+F1or+JCvuzuQ4 NUC7O7FBD4g1Y1QECr4J3nsnU91G6q0ougaDlwTGBpbp7sxMyRChF+j65hzp2l4x/epL RZhG4q25V/8VpapDZg/VDxyoK4PZS6gzCgQor6vOWNHn7YxF2WOiCAgrXRCucvHTGFSp 0XBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=eCs2d0/NWeiAiEOaiKn0FntyxLRIuNlPvVPrBWn6yMg=; b=spoQzQ5StB3dANybNaXevWfnXxRiNEUU5xKHIrZi55Aof9D8cX0vPTspaGQxpPCD0L 8bS3mNYyzsvt4BnRsXNBC45hhmpBV7LBP+AXOAqhKohAzCMreaP/JBwOJL7vNmPtbrOq IqkaBtHYQbHsmYpLIHH0G6x8EouTYteKV+ujnP0Ool6fL4EIrgh+zTyRRZkaR8hWSvrY zq9hQ0Egw/2tUqcWMW43W9EyU9/oZ7Ulh8Lpt6jkgUlTRuDdfMm4Yi3G6S3oZS/sabZ3 fhJsgvY0ES7/IEfguxnu3EEJck/+mSFTPWfLx7FvBoxItMb209F/2fw6uCuHivkjRDCC WhMQ== X-Gm-Message-State: APjAAAW92EI2zG00g5ZuO8k4G2tvgKtVutpLHH4mIoCcFVQyIZuepRX7 BpFvWLmy2oVqa9llNL8WZ7s= X-Google-Smtp-Source: APXvYqxw5yHLOEnb8cXnejTW+tZMjxrrW/glPVfFOStiu4eDK7w41GFVuVvmWgfMMDZhrPvHvhDkgw== X-Received: by 2002:a24:f802:: with SMTP id a2mr1772870ith.24.1553567663245; Mon, 25 Mar 2019 19:34:23 -0700 (PDT) Received: from raichu (toroon0560w-lp140-01-69-159-36-102.dsl.bell.ca. [69.159.36.102]) by smtp.gmail.com with ESMTPSA id o9sm6552986itb.23.2019.03.25.19.34.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 19:34:22 -0700 (PDT) Sender: Mark Johnston Date: Mon, 25 Mar 2019 22:34:19 -0400 From: Mark Johnston To: Poul-Henning Kamp Cc: Warner Losh , FreeBSD Hackers , Alfonso Siciliano Subject: Re: kern_sysctl.c interface Message-ID: <20190326023419.GB62914@raichu> References: <20190313013530.d96fc84c362bb489178357eb@gmail.com> <78358.1552464694@critter.freebsd.dk> <885.1552506820@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <885.1552506820@critter.freebsd.dk> User-Agent: Mutt/1.11.3 (2019-02-01) X-Rspamd-Queue-Id: 129976EA0D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ns9fSxQw; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::144 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-3.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.69)[-0.686,0]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.67)[ip: (1.76), ipnet: 2607:f8b0::/32(-2.87), asn: 15169(-2.15), country: US(-0.07)]; MID_RHS_NOT_FQDN(0.50)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 02:34:25 -0000 On Wed, Mar 13, 2019 at 07:53:40PM +0000, Poul-Henning Kamp wrote: > -------- > In message > , Warner Losh writes: > > >> > * This interface is under work and consideration, and should probably > >> > * be killed with a big axe by the first person who can find the time. > >> > * (be aware though, that the proper interface isn't as obvious as it > >> > * may seem, there are various conflicting requirements. > >> > >> I think that is a comment I added more than 20 years ago because we, > >> or at least I, wondered if the sysctl-OID tree should be moved to > >> something SNMP-OID compatible. > >> > >> I dont know of anything happening after that. > > > >I suspect after 20ish years the comment can be removed, eh? > > Well, it's still a butt-ugly and inefficient interface... I don't know that it'd help much with efficiency, but lately I've wanted an fd-based interface for sysctl so as to be able to use Capsicum to restrict the sysctl namespace. The idea is that a sysctlfd would reference a node in the sysctl hierarchy, and it would be possible to read or write a descendent node using the relative sysctlfd, like the *at() system calls. Only sysctls reachable from an open sysctlfd could be accessed while in capability mode. Today, we have a situation where sysctls are either statically flagged as CTLFLAG_CAPRD and thus are readable in capability mode, or you have to talk to another process over a unix socket and have it access the sysctl on your behalf. I'm not sure what an ideal syscall interface for this would look like. I think you could probably implement the idea using the existing __sysctl() syscall, by having a magic OID that writes an fd to the out buffer. Ideally you'd be able to use relative names to refer to sysctl, so that if you had an fd for dev.cpu, you could read CPU 0's temperature with something like: sysctlat(cpufd, "0.temperature", oldp, &oldlen, NULL, 0); That could avoid resolving "dev.cpu" each time it's read, so it'd be more efficient than what we do today. A real interface has to handle iteration and name resolution (hopefully avoiding an extra syscall just for resolution). It also needs to handle sysctl nodes that are addressed by OID, like kern.proc.pid..