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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 8AB19C2BB1D for ; Tue, 17 Mar 2020 16:09:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6B7B620735 for ; Tue, 17 Mar 2020 16:09:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726756AbgCQQJw (ORCPT ); Tue, 17 Mar 2020 12:09:52 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:58740 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726016AbgCQQJw (ORCPT ); Tue, 17 Mar 2020 12:09:52 -0400 Received: from ip5f5bf7ec.dynamic.kabel-deutschland.de ([95.91.247.236] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jEEmm-0004fx-QV; Tue, 17 Mar 2020 16:09:44 +0000 Date: Tue, 17 Mar 2020 17:09:43 +0100 From: Christian Brauner To: Aleksa Sarai Cc: "Michael Kerrisk (man-pages)" , Adrian Reber , Eric Biederman , Pavel Emelyanov , Oleg Nesterov , Dmitry Safonov <0x7f454c46@gmail.com>, Andrei Vagin , lkml , Mike Rapoport , Radostin Stoyanov , Arnd Bergmann , Cyrill Gorcunov , Thomas Gleixner , Linux API Subject: Re: clone3: allow creation of time namespace with offset Message-ID: <20200317160943.2qquqsa4l3oc7ii2@wittgenstein> References: <20200317083043.226593-1-areber@redhat.com> <20200317142350.ssraami3a4vnk5po@yavin> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200317142350.ssraami3a4vnk5po@yavin> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 18, 2020 at 01:23:50AM +1100, Aleksa Sarai wrote: > On 2020-03-17, Michael Kerrisk (man-pages) wrote: > > [CC += linux-api; please CC on future versions] > > > > On Tue, 17 Mar 2020 at 09:32, Adrian Reber wrote: > > > Requiring nanoseconds as well as seconds for two clocks during clone3() > > > means that it would require 4 additional members to 'struct clone_args': > > > > > > __aligned_u64 tls; > > > __aligned_u64 set_tid; > > > __aligned_u64 set_tid_size; > > > + __aligned_u64 boottime_offset_seconds; > > > + __aligned_u64 boottime_offset_nanoseconds; > > > + __aligned_u64 monotonic_offset_seconds; > > > + __aligned_u64 monotonic_offset_nanoseconds; > > > }; > > > > > > To avoid four additional members to 'struct clone_args' this patchset > > > uses another approach: > > > > > > __aligned_u64 tls; > > > __aligned_u64 set_tid; > > > __aligned_u64 set_tid_size; > > > + __aligned_u64 timens_offset; > > > + __aligned_u64 timens_offset_size; > > > }; > > > > > > timens_offset is a pointer to an array just as previously done with > > > set_tid and timens_offset_size is the size of the array. > > > > > > The timens_offset array is expected to contain a struct like this: > > > > > > struct set_timens_offset { > > > int clockid; > > > struct timespec val; > > > }; > > > > > > This way it is possible to pass the information of multiple clocks with > > > seconds and nanonseconds to clone3(). > > > > > > To me this seems the better approach, but I am not totally convinced > > > that it is the right thing. If there are other ideas how to pass two > > > clock offsets with seconds and nanonseconds to clone3() I would be happy > > > to hear other ideas. > > While I agree this does make the API cleaner, I am a little worried that > it risks killing some of the ideas we discussed for seccomp deep > inspection. In particular, having a pointer to variable-sized data > inside the struct means that now the cBPF program can't just be given a > copy of the struct data from userspace to check. I suggested two alternative approaches in a response to this. The easiest one would be to simple assume that the struct doesn't change size. (But haven't we crossed that bridge with the set_tid array already?)