From owner-freebsd-arch@freebsd.org Fri Nov 27 05:04:29 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0E63747CEF4; Fri, 27 Nov 2020 05:04:29 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cj2bw6q0rz4b3C; Fri, 27 Nov 2020 05:04:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id D852A293DD; Fri, 27 Nov 2020 05:04:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f174.google.com with SMTP id x25so3434308qkj.3; Thu, 26 Nov 2020 21:04:28 -0800 (PST) X-Gm-Message-State: AOAM533kPKvIdL+qldjOIlRRJUqvF8cM+XjK+sIwOxWKe++YdxF7z92j 8J4NiQqp8Dh4Ibr/q9dz32XNc6JRK982fWeEVP8= X-Google-Smtp-Source: ABdhPJxlkh6mA3c4sZnghdfJ8mFhjgAtHtO7tAvTV5dRAPiCpuTVFNbC41qd2SROTd80g2h3UllI/b6tsAsqVkDw+h4= X-Received: by 2002:a37:9ecc:: with SMTP id h195mr6748565qke.103.1606453468362; Thu, 26 Nov 2020 21:04:28 -0800 (PST) MIME-Version: 1.0 From: Kyle Evans Date: Thu, 26 Nov 2020 23:04:17 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: RFC: Jail privsets To: freebsd-jail , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 05:04:29 -0000 (Cross-posting to -arch and -jail for maximum reach) Hi, A couple of times recently, I've had a need or desire to increase or decrease privileges available to jails I create to some extent. You can write a MAC policy for this, but at some point the downsides of MAC policies for this became clear: it's either non-trivial to allow the kind of flexibility you may need in configuring some of these jails, and you have to rebuild the module otherwise. I've got a generally functional patch at [1] that is an approach I'd like to request comments on for refining jail privileges. It creates a privset that can be assigned on a per-jail basis, and a creator with PRIV_JAIL_SETPRIVS can specify any privset mask that's a subset of the parent prison. If no privset was specified at creation time, then we use the default logic that was previously in prison_priv_check(). prison_priv_check() has been replaced with a much simpler check of the prison's privset for the given privilege. As I was writing this, I identified the first problem with it: it doesn't currently respond to ALLOW_* updates and grant the appropriate privileges after initialization time -- this is a pretty easy fix, and I will do so if anyone else finds this useful. The other caveat is that I have no idea if there's a useful way to expose this to jail(8) users, but they're not really the primary target for this -- the primary target is system application developers that want more fine control over what a jail they're creating can do. This is an excellent foot-gun, but with great power comes great responsibility. Thanks, Kyle Evans [1] https://people.freebsd.org/~kevans/privset.diff From owner-freebsd-arch@freebsd.org Fri Nov 27 12:15:33 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C40504A6E2B; Fri, 27 Nov 2020 12:15:33 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjD9K51VHz3Gf7; Fri, 27 Nov 2020 12:15:33 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6FE772C816; Fri, 27 Nov 2020 12:15:33 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 83A418D4A166; Fri, 27 Nov 2020 12:15:31 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id F0212E708C0; Fri, 27 Nov 2020 12:15:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id gr15yS49_aqm; Fri, 27 Nov 2020 12:15:29 +0000 (UTC) Received: from [127.0.0.1] (unknown [IPv6:fde9:577b:c1a9:4902:a426:5154:d8c0:5efb]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 321FEE707C0; Fri, 27 Nov 2020 12:15:29 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Kyle Evans" Cc: freebsd-jail , freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: RFC: Jail privsets Date: Fri, 27 Nov 2020 12:15:27 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 12:15:33 -0000 On 27 Nov 2020, at 5:04, Kyle Evans wrote: > (Cross-posting to -arch and -jail for maximum reach) and trustedbsd now as that is where priv(9) came from [ http://www.trustedbsd.org/privileges.html ] > A couple of times recently, I've had a need or desire to increase or > decrease privileges available to jails I create to some extent. You > can write a MAC policy for this, but at some point the downsides of > MAC policies for this became clear: it's either non-trivial to allow > the kind of flexibility you may need in configuring some of these > jails, and you have to rebuild the module otherwise. > > I've got a generally functional patch at [1] that is an approach I'd > like to request comments on for refining jail privileges. It creates a > privset that can be assigned on a per-jail basis, and a creator with > PRIV_JAIL_SETPRIVS can specify any privset mask that's a subset of the > parent prison. > > If no privset was specified at creation time, then we use the default > logic that was previously in prison_priv_check(). prison_priv_check() > has been replaced with a much simpler check of the prison's privset > for the given privilege. > > As I was writing this, I identified the first problem with it: it > doesn't currently respond to ALLOW_* updates and grant the appropriate > privileges after initialization time -- this is a pretty easy fix, and > I will do so if anyone else finds this useful. > > The other caveat is that I have no idea if there's a useful way to > expose this to jail(8) users, but they're not really the primary > target for this -- the primary target is system application developers > that want more fine control over what a jail they're creating can do. > > This is an excellent foot-gun, but with great power comes great > responsibility. While I like the idea I am not sure I like the way it is done. I think it was a long-time goal of Robert (which just never happened to day) to make priv(9) configurable from user space. I am just not sure if hanging it off jails is the right answer. The jail-set is certainly the most extensive in the system, but the priv checks are everywhere and hanging them off, say a thread or credential, would allow people to do a lot more (also non-foot-shooting) than just modifying jails. That said, jails pretty much tie into the entire td/cred concept already so we could happily use them as a jumping platform for experimenting before extending it to the entire system if we are clear that this might not be the final stable way of doing things? Lots of health, /bz From owner-freebsd-arch@freebsd.org Fri Nov 27 14:41:51 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 603894A9138; Fri, 27 Nov 2020 14:41:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjHQ72JMHz3NNB; Fri, 27 Nov 2020 14:41:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 422F52D50A; Fri, 27 Nov 2020 14:41:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f175.google.com with SMTP id t5so3363851qtp.2; Fri, 27 Nov 2020 06:41:51 -0800 (PST) X-Gm-Message-State: AOAM532y6KUvdTnZlYJ/PnxCpsVWuleUXmVQ64fcSUr7s0iL+mjEiAgL mhG/DuoYJbDDYrV/3PueGPrU94HRsNzTER9ceTs= X-Google-Smtp-Source: ABdhPJx8fH10l06qJCrMy5S2BJgnmoiLQONDyYU2hGGgLq4cvXSSON0uGDwSQxykXlFV5UePS4DYZqacfqGazWfzn7o= X-Received: by 2002:ac8:5345:: with SMTP id d5mr8761413qto.60.1606488110643; Fri, 27 Nov 2020 06:41:50 -0800 (PST) MIME-Version: 1.0 References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> In-Reply-To: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> From: Kyle Evans Date: Fri, 27 Nov 2020 08:41:39 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Jail privsets To: "Bjoern A. Zeeb" Cc: freebsd-jail , "freebsd-arch@freebsd.org" , trustedbsd-discuss@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 14:41:51 -0000 On Fri, Nov 27, 2020 at 6:15 AM Bjoern A. Zeeb wrote: > > On 27 Nov 2020, at 5:04, Kyle Evans wrote: > > > (Cross-posting to -arch and -jail for maximum reach) > > and trustedbsd now as that is where priv(9) came from [ > http://www.trustedbsd.org/privileges.html ] > > > A couple of times recently, I've had a need or desire to increase or > > decrease privileges available to jails I create to some extent. You > > can write a MAC policy for this, but at some point the downsides of > > MAC policies for this became clear: it's either non-trivial to allow > > the kind of flexibility you may need in configuring some of these > > jails, and you have to rebuild the module otherwise. > > > > I've got a generally functional patch at [1] that is an approach I'd > > like to request comments on for refining jail privileges. It creates a > > privset that can be assigned on a per-jail basis, and a creator with > > PRIV_JAIL_SETPRIVS can specify any privset mask that's a subset of the > > parent prison. > > > > If no privset was specified at creation time, then we use the default > > logic that was previously in prison_priv_check(). prison_priv_check() > > has been replaced with a much simpler check of the prison's privset > > for the given privilege. > > > > As I was writing this, I identified the first problem with it: it > > doesn't currently respond to ALLOW_* updates and grant the appropriate > > privileges after initialization time -- this is a pretty easy fix, and > > I will do so if anyone else finds this useful. > > > > The other caveat is that I have no idea if there's a useful way to > > expose this to jail(8) users, but they're not really the primary > > target for this -- the primary target is system application developers > > that want more fine control over what a jail they're creating can do. > > > > This is an excellent foot-gun, but with great power comes great > > responsibility. > > While I like the idea I am not sure I like the way it is done. > > I think it was a long-time goal of Robert (which just never happened to > day) to make priv(9) configurable from user space. > > I am just not sure if hanging it off jails is the right answer. > The jail-set is certainly the most extensive in the system, but the priv > checks are everywhere and hanging them off, say a thread or credential, > would allow people to do a lot more (also non-foot-shooting) than just > modifying jails. > > That said, jails pretty much tie into the entire td/cred concept already > so we could happily use them as a jumping platform for experimenting > before extending it to the entire system if we are clear that this might > not be the final stable way of doing things? > Hi, So, FWIW, I had mapped this out a little further in my head but hadn't quite decided on the best approach so I had stuck to jails for the time being because that's the scenario that crops up the most for me thus far. Here's the line of reasoning I went through up to this point, for full disclosure: cred-based seems like a good approach, but the caveat is that they're a little more difficult to target in a meaningful way to the admin, AFAICT. I really like cpuset(1) and the accompanying interfaces, as there's a lot of flexibility to be had there. It uses relatable concepts that have obvious semantics: - You can restrict a jail, it cascades down - You can restrict a process, it cascades down - You can restrict a thread So I started there at the first level, because it doesn't actually preclude the later levels. As you step down the tree, I think you simply step away from the need to have prison_priv_check() at all and just naturally push it all down into priv_check() because the fact that they're in a jail has either already been accounted for or is now completely irrelevant. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Sat Nov 28 13:19:08 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9EDDD4A1372; Sat, 28 Nov 2020 13:19:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjsXD3mk0z3qHk; Sat, 28 Nov 2020 13:19:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 440E8824A; Sat, 28 Nov 2020 13:19:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 265988D4A222; Sat, 28 Nov 2020 13:19:06 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 80E3BE707EC; Sat, 28 Nov 2020 13:19:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id VUKhagN7Sp-T; Sat, 28 Nov 2020 13:19:03 +0000 (UTC) Received: from [127.0.0.1] (unknown [IPv6:fde9:577b:c1a9:4902:501c:cc48:65a0:381e]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D2DBCE707D6; Sat, 28 Nov 2020 13:19:02 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Kyle Evans" Cc: freebsd-jail , freebsd-arch@freebsd.org, trustedbsd-discuss@freebsd.org Subject: Re: RFC: Jail privsets Date: Sat, 28 Nov 2020 13:19:01 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> In-Reply-To: References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 13:19:08 -0000 On 27 Nov 2020, at 14:41, Kyle Evans wrote: > On Fri, Nov 27, 2020 at 6:15 AM Bjoern A. Zeeb wrote: >> >> On 27 Nov 2020, at 5:04, Kyle Evans wrote: >> >>> (Cross-posting to -arch and -jail for maximum reach) >> >> and trustedbsd now as that is where priv(9) came from [ >> http://www.trustedbsd.org/privileges.html ] >> >>> A couple of times recently, I've had a need or desire to increase or >>> decrease privileges available to jails I create to some extent. You >>> can write a MAC policy for this, but at some point the downsides of >>> MAC policies for this became clear: it's either non-trivial to allow >>> the kind of flexibility you may need in configuring some of these >>> jails, and you have to rebuild the module otherwise. >>> >>> I've got a generally functional patch at [1] that is an approach I'd >>> like to request comments on for refining jail privileges. It creates >>> a >>> privset that can be assigned on a per-jail basis, and a creator with >>> PRIV_JAIL_SETPRIVS can specify any privset mask that's a subset of >>> the >>> parent prison. >>> >>> If no privset was specified at creation time, then we use the >>> default >>> logic that was previously in prison_priv_check(). >>> prison_priv_check() >>> has been replaced with a much simpler check of the prison's privset >>> for the given privilege. >>> >>> As I was writing this, I identified the first problem with it: it >>> doesn't currently respond to ALLOW_* updates and grant the >>> appropriate >>> privileges after initialization time -- this is a pretty easy fix, >>> and >>> I will do so if anyone else finds this useful. >>> >>> The other caveat is that I have no idea if there's a useful way to >>> expose this to jail(8) users, but they're not really the primary >>> target for this -- the primary target is system application >>> developers >>> that want more fine control over what a jail they're creating can >>> do. >>> >>> This is an excellent foot-gun, but with great power comes great >>> responsibility. >> >> While I like the idea I am not sure I like the way it is done. >> >> I think it was a long-time goal of Robert (which just never happened >> to >> day) to make priv(9) configurable from user space. >> >> I am just not sure if hanging it off jails is the right answer. >> The jail-set is certainly the most extensive in the system, but the >> priv >> checks are everywhere and hanging them off, say a thread or >> credential, >> would allow people to do a lot more (also non-foot-shooting) than >> just >> modifying jails. >> >> That said, jails pretty much tie into the entire td/cred concept >> already >> so we could happily use them as a jumping platform for experimenting >> before extending it to the entire system if we are clear that this >> might >> not be the final stable way of doing things? >> > > Hi, > > So, FWIW, I had mapped this out a little further in my head but hadn't > quite decided on the best approach so I had stuck to jails for the > time being because that's the scenario that crops up the most for me > thus far. > > Here's the line of reasoning I went through up to this point, for full > disclosure: > > cred-based seems like a good approach, but the caveat is that they're > a little more difficult to target in a meaningful way to the admin, > AFAICT. > > I really like cpuset(1) and the accompanying interfaces, as there's a > lot of flexibility to be had there. It uses relatable concepts that > have obvious semantics: > > - You can restrict a jail, it cascades down > - You can restrict a process, it cascades down > - You can restrict a thread > > So I started there at the first level, because it doesn't actually > preclude the later levels. As you step down the tree, I think you > simply step away from the need to have prison_priv_check() at all and > just naturally push it all down into priv_check() because the fact > that they're in a jail has either already been accounted for or is now > completely irrelevant. To finish this for jails, like devfs rules or cpuset or FIB (though different interfaces), we’d have a one or two “default” priv_sets defined in user space for jails then (if I understand you correctly), and jail(8)/jail_conf/jail syscalls would simply apply that (and it could be changed while running). And yes, that would indeed simplify our jail and network stack (and some other) code quite a bit. I’d love this (step-by-step or in whole right away) :-) Bjoern From owner-freebsd-arch@freebsd.org Sat Nov 28 14:39:26 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CFAEB4A2552; Sat, 28 Nov 2020 14:39:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjvJt5Q0zz3t43; Sat, 28 Nov 2020 14:39:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id A79E08DC2; Sat, 28 Nov 2020 14:39:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f180.google.com with SMTP id i199so6872975qke.5; Sat, 28 Nov 2020 06:39:26 -0800 (PST) X-Gm-Message-State: AOAM533hOCQuzFjxxUQM9PpKSLXjxHrOQLviobxI0jJf2ei8h73xZh6p dlcXsy7VQ1rFNjKJ2y54B+nqqpibEBpcmSbhGaM= X-Google-Smtp-Source: ABdhPJzTBuG5KrgkFhRcsL7UoVItLgBHwf8OiaTkcsENJuIpNDInWtEojOKeRWvoERbhh7eJK3WkRXB5r4xhosOOSsI= X-Received: by 2002:ae9:e00e:: with SMTP id m14mr13764876qkk.34.1606574365869; Sat, 28 Nov 2020 06:39:25 -0800 (PST) MIME-Version: 1.0 References: <06F654BB-B087-4AE5-8599-E5837A85A850@FreeBSD.org> <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> In-Reply-To: <6BA03DAD-BDCD-4A53-A80A-4B7B476B803C@FreeBSD.org> From: Kyle Evans Date: Sat, 28 Nov 2020 08:39:08 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: Jail privsets To: "Bjoern A. Zeeb" Cc: freebsd-jail , "freebsd-arch@freebsd.org" , trustedbsd-discuss@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 14:39:26 -0000 On Sat, Nov 28, 2020 at 7:19 AM Bjoern A. Zeeb wrote: > > On 27 Nov 2020, at 14:41, Kyle Evans wrote: > > > On Fri, Nov 27, 2020 at 6:15 AM Bjoern A. Zeeb wrote: > >> > >> On 27 Nov 2020, at 5:04, Kyle Evans wrote: > >> > >>> (Cross-posting to -arch and -jail for maximum reach) > >> > >> and trustedbsd now as that is where priv(9) came from [ > >> http://www.trustedbsd.org/privileges.html ] > >> > >>> A couple of times recently, I've had a need or desire to increase or > >>> decrease privileges available to jails I create to some extent. You > >>> can write a MAC policy for this, but at some point the downsides of > >>> MAC policies for this became clear: it's either non-trivial to allow > >>> the kind of flexibility you may need in configuring some of these > >>> jails, and you have to rebuild the module otherwise. > >>> > >>> I've got a generally functional patch at [1] that is an approach I'd > >>> like to request comments on for refining jail privileges. It creates > >>> a > >>> privset that can be assigned on a per-jail basis, and a creator with > >>> PRIV_JAIL_SETPRIVS can specify any privset mask that's a subset of > >>> the > >>> parent prison. > >>> > >>> If no privset was specified at creation time, then we use the > >>> default > >>> logic that was previously in prison_priv_check(). > >>> prison_priv_check() > >>> has been replaced with a much simpler check of the prison's privset > >>> for the given privilege. > >>> > >>> As I was writing this, I identified the first problem with it: it > >>> doesn't currently respond to ALLOW_* updates and grant the > >>> appropriate > >>> privileges after initialization time -- this is a pretty easy fix, > >>> and > >>> I will do so if anyone else finds this useful. > >>> > >>> The other caveat is that I have no idea if there's a useful way to > >>> expose this to jail(8) users, but they're not really the primary > >>> target for this -- the primary target is system application > >>> developers > >>> that want more fine control over what a jail they're creating can > >>> do. > >>> > >>> This is an excellent foot-gun, but with great power comes great > >>> responsibility. > >> > >> While I like the idea I am not sure I like the way it is done. > >> > >> I think it was a long-time goal of Robert (which just never happened > >> to > >> day) to make priv(9) configurable from user space. > >> > >> I am just not sure if hanging it off jails is the right answer. > >> The jail-set is certainly the most extensive in the system, but the > >> priv > >> checks are everywhere and hanging them off, say a thread or > >> credential, > >> would allow people to do a lot more (also non-foot-shooting) than > >> just > >> modifying jails. > >> > >> That said, jails pretty much tie into the entire td/cred concept > >> already > >> so we could happily use them as a jumping platform for experimenting > >> before extending it to the entire system if we are clear that this > >> might > >> not be the final stable way of doing things? > >> > > > > Hi, > > > > So, FWIW, I had mapped this out a little further in my head but hadn't > > quite decided on the best approach so I had stuck to jails for the > > time being because that's the scenario that crops up the most for me > > thus far. > > > > Here's the line of reasoning I went through up to this point, for full > > disclosure: > > > > cred-based seems like a good approach, but the caveat is that they're > > a little more difficult to target in a meaningful way to the admin, > > AFAICT. > > > > I really like cpuset(1) and the accompanying interfaces, as there's a > > lot of flexibility to be had there. It uses relatable concepts that > > have obvious semantics: > > > > - You can restrict a jail, it cascades down > > - You can restrict a process, it cascades down > > - You can restrict a thread > > > > So I started there at the first level, because it doesn't actually > > preclude the later levels. As you step down the tree, I think you > > simply step away from the need to have prison_priv_check() at all and > > just naturally push it all down into priv_check() because the fact > > that they're in a jail has either already been accounted for or is now > > completely irrelevant. > > > To finish this for jails, like devfs rules or cpuset or FIB (though > different interfaces), > we=E2=80=99d have a one or two =E2=80=9Cdefault=E2=80=9D priv_sets define= d in user space > for jails then > (if I understand you correctly), and jail(8)/jail_conf/jail syscalls > would simply > apply that (and it could be changed while running). > Yeah, so jail sets are a little tricky, and to be honest I haven't really thought about how to cope with common jail sets. The complication arises because you have various allow flags that typically default to off and turn privileges on, but your common sets would have to include them. So, you'd probably end up with: privset 0: All privs available to the superuser (not considering superuser policy just yet) privset 1: All privs available to jails (assuming most permissive, all allow flags on and assuming a new vnet on VIMAGE systems) So jails would typically inherit privset 1, but they'd have to mask out based on vnet/allow flags out of necessity. Now, that's not terrible, but I think we'd have to do a couple more things to reduce maintenance burden on folks introducing privs: 1.) Clearly define a central table that maps pr_flags <-> privs where there's a 1:1 mapping (most common, though PRIV_VFS_*MOUNT* are a little more complicated) 2.) Walk said table when we're defining privs in privset 1 3.) Walk said table when we're determining what to mask out I suspect the vnet set is large enough that we'd just have a separate kernel-internal mask for "vnet privs". In any event, for most people, there will be one of three places that you might touch when adding a new priv flag or pr_flag mapping to a priv, but it should still be obvious what you want: either you want a conditionally added flag, you want to influence the default jail policy, or you want to change the vnet policy. The latter two scenarios might even be a little easier, because you don't need to wade through these gigantic switch statements with a lot of cases to determine where you really want it to go. > And yes, that would indeed simplify our jail and network stack (and some > other) > code quite a bit. > > I=E2=80=99d love this (step-by-step or in whole right away) :-) > :-) I'm looking to see if I can define a useful abstraction from cpuset/domainset that would limit the amount of duplication needed for this, then I'll post a v2 to Phabricator. Thanks, Kyle Evans From owner-freebsd-arch@freebsd.org Sat Nov 28 15:53:02 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B1D6D4A472D for ; Sat, 28 Nov 2020 15:53:02 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cjwxp0w61z4TXC for ; Sat, 28 Nov 2020 15:53:01 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1606578780; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=LNZ6GKzxv1fZhBQVQvFrRy5XnYH66sOHxoNOAGyh/yCOQkcjZo8jj2RsJOeLXb3kr83spGqkzuMIr p1mzqjkD6JXYPcNP0VnOzrZ3o2O9NJDK8ttSlFpncGBpdmJ0M4dzYigLBO0Ga7x39J5Me3Z5YFPnIv 7OEZeqXhCIWLgzfr72MDy5W4FPnXbshI0bQGx1s6uObzPUIy8gGJk3m7x/h9j2Nxy+GAzWuSK5k4ay Ymqe8gwWcLxzkR5ysU7MdLwlZ1rihblHGulij3fc4podqa41L47PCXkOaD2NzTug70amnwijGqeRBr AQXmvuDpclfexIs12o1hZpEsn//4qoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:date:to:from:subject: message-id:dkim-signature:from; bh=qak2HyWeLlpbdkp7Ef6Ag/hr4FZrzJa7zcKH5na03M4=; b=iIKRbh+hkXnVtBbxS+ZAhaX1fTRgU0GZSb3plf0gkGcsMFFvo0bnJxMtYsCecfm1BzjgLbnajALWW qcbRTFZ15GABLYaSYMYlg0lf/YQP65RXo8nZKLIcMfnDEXY8VPpRZd070iRDjXr1qfjNjN85rURjQz v5vculsoYngOyVyJ+K2GYhjasRv5SYcGesm+aVtaPf/HCkCyWzmgPwnr9JKo4RRX2JUSLuwoAQJOPV 5209DDtVldK6LvqMVcHIAZ9gaBY6oSau+apg45ET6V2upBDf0916IzNj8bENODybH6Hd6s5CIljvxH CDhVNLCAjqT3irAQyyCqSftQyxfz2Tg== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:date:to:from:subject: message-id:from; bh=qak2HyWeLlpbdkp7Ef6Ag/hr4FZrzJa7zcKH5na03M4=; b=a0OGeqjwvFYOCC9LbvtE0LBWaU3aJUUv6CSeI503X38pAK//MynkwmYwbA5mJ46MqBZU7nLl7jJil N2s0TWg2+wjA13qQJxMLQcgW0dltRidTsjYUIUJ7NK8ONLZMFjnbZiO/gX6LNFVlBHxwerwS43EEmB 5pGjJxd67cTMTDuCTzPg72UbYK4L+b19x/hWbkdWmM5qsI45MZANgsBDV9jTZ37UtyFQxwpfvdnF+f 3UyloJ9Sxo57rfX+/E5+CR2F7BkswfJRTZjehq8c9cTLK3/WX2qL8SOMKp9c5Q5PjpPywHqJNVSX2n sk++lKnKs30W1ce1WMoQKdOo8Kvy1wQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: c9612f0a-3191-11eb-8b39-614106969e8d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id c9612f0a-3191-11eb-8b39-614106969e8d; Sat, 28 Nov 2020 15:52:59 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0ASFqwDN083803 for ; Sat, 28 Nov 2020 08:52:58 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <567389bbf8882800c86a9cd8a502051af48cc4ec.camel@freebsd.org> Subject: sbintime_t in userland From: Ian Lepore To: "freebsd-arch@FreeBSD.org" Date: Sat, 28 Nov 2020 08:52:58 -0700 Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Cjwxp0w61z4TXC X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 15:53:02 -0000 I notice everything related to sbintime_t in sys/time.h is in the public part of the header file (not protected by #ifdef _KERNEL). As near as I can tell, no existing userland software uses this type, and no userland<->kernel APIs involve sbintime_t. I have a situation where I need to timestamp events relative to each other in the kernel and report those timestamps to userland. sbintime_t would be an ideal compact format for the data, and sbinuptime() would be a fine way to obtain the timestamps in the kernel. Before breaking new ground like this I thought I'd solicit opinions: is it a bad idea to export sbintime_t values from the kernel like this? If it's considered okay, a second question would be: is it okay to document that they are on the 'uptime timescale' (meaning userland could translate them to UTC timestamps by determining the offset between CLOCK_REALTIME and CLOCK_MONOTONIC)? -- Ian From owner-freebsd-arch@freebsd.org Sat Nov 28 15:57:14 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F32CB4A4748 for ; Sat, 28 Nov 2020 15:57:14 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cjx2d6fhzz4TvW; Sat, 28 Nov 2020 15:57:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 903148A574; Sat, 28 Nov 2020 15:57:03 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0ASFv3G8052818; Sat, 28 Nov 2020 15:57:03 GMT (envelope-from phk) To: Ian Lepore cc: "freebsd-arch@FreeBSD.org" Subject: Re: sbintime_t in userland In-reply-to: <567389bbf8882800c86a9cd8a502051af48cc4ec.camel@freebsd.org> From: "Poul-Henning Kamp" References: <567389bbf8882800c86a9cd8a502051af48cc4ec.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <52816.1606579023.1@critter.freebsd.dk> Date: Sat, 28 Nov 2020 15:57:03 +0000 Message-ID: <52817.1606579023@critter.freebsd.dk> X-Rspamd-Queue-Id: 4Cjx2d6fhzz4TvW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 15:57:15 -0000 -------- Ian Lepore writes: > I notice everything related to sbintime_t in sys/time.h is in the > public part of the header file (not protected by #ifdef _KERNEL). As > near as I can tell, no existing userland software uses this type, and > no userland<->kernel APIs involve sbintime_t. s/existing userland/existing checked in userland/ :-) yes, this is a supported, but very lightly documented api. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Sat Nov 28 16:32:11 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C355F4A53BD for ; Sat, 28 Nov 2020 16:32:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cjxpy6QBQz4WJT for ; Sat, 28 Nov 2020 16:32:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf31.google.com with SMTP id g19so3684724qvy.2 for ; Sat, 28 Nov 2020 08:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S6tDOmFZp5Mi4+09aXGsI+EZ2wG2KZ+dxE/XjQri+aI=; b=UJaJ/1mzgO1HJp63rIEhHZggVCdkk/lualQbP29Hz3DceIKcHrl2VHyZa/dBmUD1rP pQBNMnT0kfnmLcLuRHPAS5xL8CK3C0u09VGotyfMIG93fW/8IJm9NPg4L/aVafk32Tvs QrG8BVdaDwBAiT4NqEnJLl4Ld3NDtwhwqYZrx/KJNyPQBw9B7fVcYiwK9T8Vm3sRfHQP NWMVG58devEbqBv3oGdWcoMPna3xsE/y6QgzMCzarINGUSMoXY5ErQhpuB1pKsQuinRz /I0Py7NlNEy3n1NTjf4ye3nsmTtwIw98u9H10DazxneUUBAl45sn3eOso4QClEXtWHd2 mB6w== 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=S6tDOmFZp5Mi4+09aXGsI+EZ2wG2KZ+dxE/XjQri+aI=; b=VuUec15HEYS7e2gQSUsVBjHDzf8eA7AFDqm94R+hJf12jg9x/btQOVDo1kfrnoArZ2 Qy1bIxgfC1776JV2rTbnMLbTdzvUv/qHZm2e5DtnowRFSO6NlRSlhk7B2ElbInVyo+ly 9HARJIYOuF1XbSO1Jkm1Qo2JdnlIEFpmlIH/AVG+aJZn8Fw5F394NZLPSqFSXSycULIX yHt1xgm+MIgigiVCUW3IftUak1fBWCpWzm2MCgpjndT0jcjF6Lz4P9QiOJRy0U29PvGy LseFlkITQVuZfxfctF8xFCrW0k7U3RI5gpmyA+a7+bcc6l1IkhbBsQgS8MHWjaVf+ND9 EMBQ== X-Gm-Message-State: AOAM533PNCRkVSMkT9FGrjco9TSRAZ/V542LBS7wN1fW5IuzbR9jSOFc 6tD40nybZUAWjOMREw1lQ0kGzm4C3wax7TPmAQQSiQ== X-Google-Smtp-Source: ABdhPJxAWfo8oCl2bbQubhk26lHcM61pm/aACiGtpFSn0yp/dk8/jEyBqBQtBtpThlcadiGkfKAz9inZwGge8ReGBsE= X-Received: by 2002:ad4:4e13:: with SMTP id dl19mr13676325qvb.24.1606581129608; Sat, 28 Nov 2020 08:32:09 -0800 (PST) MIME-Version: 1.0 References: <567389bbf8882800c86a9cd8a502051af48cc4ec.camel@freebsd.org> In-Reply-To: <567389bbf8882800c86a9cd8a502051af48cc4ec.camel@freebsd.org> From: Warner Losh Date: Sat, 28 Nov 2020 09:31:57 -0700 Message-ID: Subject: Re: sbintime_t in userland To: Ian Lepore Cc: "freebsd-arch@FreeBSD.org" X-Rspamd-Queue-Id: 4Cjxpy6QBQz4WJT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=UJaJ/1mz; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f31) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::f31:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::f31:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-arch]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 16:32:11 -0000 On Sat, Nov 28, 2020, 8:53 AM Ian Lepore wrote: > I notice everything related to sbintime_t in sys/time.h is in the > public part of the header file (not protected by #ifdef _KERNEL). As > near as I can tell, no existing userland software uses this type, and > no userland<->kernel APIs involve sbintime_t. > > I have a situation where I need to timestamp events relative to each > other in the kernel and report those timestamps to userland. > sbintime_t would be an ideal compact format for the data, and > sbinuptime() would be a fine way to obtain the timestamps in the > kernel. > > Before breaking new ground like this I thought I'd solicit opinions: is > it a bad idea to export sbintime_t values from the kernel like this? > This is fine. If it's considered okay, a second question would be: is it okay to > document that they are on the 'uptime timescale' (meaning userland > could translate them to UTC timestamps by determining the offset > between CLOCK_REALTIME and CLOCK_MONOTONIC)? > You'd have to publish the offset for this series of timestamps. And an ntpd time step would require an update to do completely right... The frequency adjustments are already swizzled in, though. Granted, those are rare enough, but the condition should at least be documented. In many ways, time steps are like leap seconds, though at irregular times and without :60 to worry about. Backwards steps lead to ambiguous UTC time stamps... Warner -- Ian > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >