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=-4.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 29004C433DF for ; Thu, 25 Jun 2020 08:44:15 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E97BD20707 for ; Thu, 25 Jun 2020 08:44:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Sk9LjARH"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dOpkywZO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E97BD20707 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FeYKYT467gePE2DcM1SQ2BjBfz8F8kiAwrxkHtUDVgw=; b=Sk9LjARHDeLqiwos9kQWbSJtJ Y1rPO+MwHIH7F266KpHDuNxp4mjjojsUUM7FBD69/xXXDGMnaahKQ8UzHXIzkGfXpF4se/6fTm95Z 1exB90wX4HsREVZNrcfFXuxoHgoOC0TdycKW1uOs0mZ61JZI6R864OvoeBGrLnRXZWSsh69dTCFlb 8wT4W2OgHSXMleHNHEO8iLH147Optqi6vzlwlWHmwWs+kAJfqObgJh1gdHL8s4fdGc9ZlwdtQ2woQ Qy38nQpjqLwYfiF2CH3VylMJw8xMfoJe2Ge29qDW+JdkgCTcHf4oVMXzwVN9BwHSy/0rSAVPcqu16 3SFtiHs1w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1joNSz-0005lw-NG; Thu, 25 Jun 2020 08:42:41 +0000 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1joNSx-0005jW-02 for linux-arm-kernel@lists.infradead.org; Thu, 25 Jun 2020 08:42:39 +0000 Received: by mail-pl1-x641.google.com with SMTP id j4so2516139plk.3 for ; Thu, 25 Jun 2020 01:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9Ak4YKOU6Z1LQkeYz68N9Kz3RJ7GxY3Zdvb8yaAgjb0=; b=dOpkywZOfZZs5ibaTbsnSX/lYi8K7cpq5wVnt7hnEwDySagQm7ZfegX0k9THbUrQkA hdWw1W8gloKrRtxR3USeU/5hHSeJ5vRufcv26BMCFbK8owRJzYyXCJvKhI0BM0OFdLgr +Flfg3f5AkuzVDQRLPVQIzz3nP11srH8hdcgfQ2wHHAMA2Pq385TSePQxuI0jJjFJpXK LW4dLkzLRY4sv4X06eJShAYpQgH40MaCJHVIIEWSXkMbmaEZPa8Tl+0OPCWqV8oe2FOa 5jC+kQeke5iSXz1T9Mr/FXMzY2pQrENLZC5qSrikqStIUEedBRQGblVp6C18gsP5yZvl 6ivg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9Ak4YKOU6Z1LQkeYz68N9Kz3RJ7GxY3Zdvb8yaAgjb0=; b=gtJKiUuuBtUv6kN8YfxtOsfCz9hPevaDqrCWNCpWaAkcOZgfci2FvNt43oM0DWAyKn yw8Bv2ZVsOant7YVnrqPuePmmYXOdJeumAwDI2Ec97jekXNoB00OCaw/XfqEKmSyjEku t+aaPslENr1e3RpjoT9dBMlBBMzWoWGhLCQLC4nqC/QgRqUwLcl5zzTGcYwEHELhmlrm mzHkKFhBVKY3fb0eGQ0BgKdqDv1yef9L2F+kRk7kKX12VY4epMOf8Poz99kLC3YtOHP3 WLV9b8hd8O3cBMp/lRKP1ITr3GoliMUoETX5tJpgDKx2l1YC6brerNfuPLn3MbX94I52 NokQ== X-Gm-Message-State: AOAM532mz/JeJVZDfIXdYk03NrVxU2BLg3sD/cnQYRCvzWSC2ea8v9sB fJDHZ1aUuoUwuNEW60NL/S8= X-Google-Smtp-Source: ABdhPJzPLoaOTjTeX0um/FFziQC1BFJH5ulKh16r2QyVBel5hbJ51f7pn+ruzDrHtBtkYkraGki5HQ== X-Received: by 2002:a17:90a:7c4e:: with SMTP id e14mr2111770pjl.175.1593074555248; Thu, 25 Jun 2020 01:42:35 -0700 (PDT) Received: from gmail.com ([2601:600:9b7f:872e:a655:30fb:7373:c762]) by smtp.gmail.com with ESMTPSA id p5sm23854276pfg.162.2020.06.25.01.42.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2020 01:42:34 -0700 (PDT) Date: Thu, 25 Jun 2020 01:42:32 -0700 From: Andrei Vagin To: Christian Brauner Subject: Re: [PATCH 3/3] nsproxy: support CLONE_NEWTIME with setns() Message-ID: <20200625084232.GB151695@gmail.com> References: <20200619153559.724863-1-christian.brauner@ubuntu.com> <20200619153559.724863-4-christian.brauner@ubuntu.com> <20200623115521.hk3xlhixrt2zrgkn@wittgenstein> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200623115521.hk3xlhixrt2zrgkn@wittgenstein> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Dmitry Safonov , Catalin Marinas , x86@kernel.org, linux-kernel@vger.kernel.org, adrian@lisas.de, Michael Kerrisk , Andy Lutomirski , Thomas Gleixner , Vincenzo Frascino , Will Deacon , linux-arm-kernel@lists.infradead.org, Serge Hallyn Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 23, 2020 at 01:55:21PM +0200, Christian Brauner wrote: > On Fri, Jun 19, 2020 at 05:35:59PM +0200, Christian Brauner wrote: > > So far setns() was missing time namespace support. This was partially due > > to it simply not being implemented but also because vdso_join_timens() > > could still fail which made switching to multiple namespaces atomically > > problematic. This is now fixed so support CLONE_NEWTIME with setns() > > > > Cc: Thomas Gleixner > > Cc: Michael Kerrisk > > Cc: Serge Hallyn > > Cc: Dmitry Safonov > > Cc: Andrei Vagin > > Signed-off-by: Christian Brauner > > --- > > Andrei, > Dmitry, > > A little off-topic since its not related to the patch here but I've been > going through the current time namespace semantics and i just want to > confirm something with you: > > Afaict, unshare(CLONE_NEWTIME) currently works similar to > unshare(CLONE_NEWPID) in that it only changes {pid,time}_for_children > but does _not_ change the {pid, time} namespace of the caller itself. > For pid namespaces that makes a lot of sense but I'm not completely > clear why you're doing this for time namespaces, especially since the > setns() behavior for CLONE_NEWPID and CLONE_NEWTIME is very different: > Similar to unshare(CLONE_NEWPID), setns(CLONE_NEWPID) doesn't change the > pid namespace of the caller itself, it only changes it for it's > children by setting up pid_for_children. _But_ for setns(CLONE_NEWTIME) > both the caller's and the children's time namespace is changed, i.e. > unshare(CLONE_NEWTIME) behaves different from setns(CLONE_NEWTIME). Why? This scheme allows setting clock offsets for a namespace, before any processes appear in it. It is not allowed to change offsets if any task has joined a time namespace. We need this to avoid corner cases with timers and tasks don't need to be aware of offset changes. > > This also has the consequence that the unshare(CLONE_NEWTIME) + > setns(CLONE_NEWTIME) sequence can be used to change the callers pid > namespace. Is this intended? > Here's some code where you can verify this (please excuse the aweful > code I'm using to illustrate this): > > int main(int argc, char *argv[]) > { > char buf1[4096], buf2[4096]; > > if (unshare(0x00000080)) > exit(1); > > int fd = open("/proc/self/ns/time", O_RDONLY); > if (fd < 0) > exit(2); > > readlink("/proc/self/ns/time", buf1, sizeof(buf1)); > readlink("/proc/self/ns/time_for_children", buf2, sizeof(buf2)); > printf("unshare(CLONE_NEWTIME): time(%s) ~= time_for_children(%s)\n", buf1, buf2); > > if (setns(fd, 0x00000080)) > exit(3); And in this example, you use the right sequence of steps: unshare, set offsets, setns. With clone3, we will be able to do this in one call. > > readlink("/proc/self/ns/time", buf1, sizeof(buf1)); > readlink("/proc/self/ns/time_for_children", buf2, sizeof(buf2)); > printf("setns(self, CLONE_NEWTIME): time(%s) == time_for_children(%s)\n", buf1, buf2); > > exit(EXIT_SUCCESS); > } > > which gives: > > root@f2-vm:/# ./test > unshare(CLONE_NEWTIME): time(time:[4026531834]) ~= time_for_children(time:[4026532366]) > setns(self, CLONE_NEWTIME): time(time:[4026531834]) == time_for_children(time:[4026531834]) > > why is unshare(CLONE_NEWTIME) blocked from changing the callers pid > namespace when setns(CLONE_NEWTIME) is allowed to do this? > > Christian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel