Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp590559ybm; Thu, 28 May 2020 10:09:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyECMpBq8abEFnshSW9nMfN79CK8ElSKSbAvTL522doROHVsuuhKMHxmTIrJQccrCbHS+49 X-Received: by 2002:a05:6402:1434:: with SMTP id c20mr4030281edx.27.1590685752264; Thu, 28 May 2020 10:09:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590685752; cv=none; d=google.com; s=arc-20160816; b=lJ4i32+UUztEa1dOPIqi/rbbmgckQ7d/Tl6hBULsepVruXq2V52QRA/ErU4ZAz50TL ggGubmYq44wCz5dFo9n9svF8X8gsM8LwYer4yFW1Yt8v47r2mweQ4RY8gFbbA+Cat/SG 7EZdkwhdp+YILiZlqfL/7Y4SvzsNagxttj2cI5+6dltHaPJHCsonfF3q2IP7hJpzLONZ ouUukLRWD5GtNhawl3CQ0Dah5QJ+L7KjqfF6JI/VPZfeqRnOqdT7/eVQ6f/7gK5WNPGg R+qdss/iJzhTFB+0QURHn/BcWJVa3mp32bUjLZ+jG5t6emQS1ZsppA8UaawI0zk/76pg +w6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=sPK2AUkVbYrlBIuEiT/LezDNFauHztnHTLMpmUaLaBQ=; b=iuJ8yFqwmZfVMhJpeGkKU4tUVrkRW05BLWapIjr2AyXhSQ8/HJ7B537bLAH555hMS0 Os9FOR7PXSlY0uhENG69mh+d+mtapKzSYuwUocj7uGVoVlVauDcA+gVqDvIOaTCKkc2a UT7/heOoaXiwHmPakvU1MXuIUzkqfgBM9TuyuyWFX1P3G0gIFB/NwRsjTajtfa0A1l8w y5dSZIiq/idq3m/l03E640IjUxZlbFLs6Ua507nzftQwC8av5Q7JPBgpwY2SlJwaK8/K xMnJqHSQYB/u7sfqjPcdE6EXWJQpAiPc9wpQ2tP3Y/S5cYNdm/3J7MW8wusm+N0QQeT2 KQQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=VDbKzp31; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n6si4232388ejz.660.2020.05.28.10.08.48; Thu, 28 May 2020 10:09:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=VDbKzp31; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405343AbgE1REJ (ORCPT + 99 others); Thu, 28 May 2020 13:04:09 -0400 Received: from merlin.infradead.org ([205.233.59.134]:48912 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405249AbgE1REG (ORCPT ); Thu, 28 May 2020 13:04:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sPK2AUkVbYrlBIuEiT/LezDNFauHztnHTLMpmUaLaBQ=; b=VDbKzp31VwCdMbkSQ//1HtPXzL FOrZOd4XaGbi+3rVJzohXjInNfJEH9pLvG8MplMMPD0ZBy7cCVzwG5rdyA8mcZAHXwPmjrXRFQbj1 +wO5lranokB6cgL+Z+OkN/WLfs14z0VoRKZJOlJ4MKHWO9ElQXAGCVWQ6XmrH+mQZhL41cgumt/cc lAkQ4hlF5wt61fH8+WwVXShA060OwlfcZQesZVJU8Uvw8BAJVV8t7TalZqKpb+gbM9yDJnmYeYsts 6ckUUh0W7TD7D57ka0+kuBoDuARPGfuVn3iwr5Hf9SgIPFPo05ZJreTE7qYXMa6RsbbC9izz7X2dL SY9n9xzg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=worktop.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1jeLuM-0006fT-Po; Thu, 28 May 2020 17:01:30 +0000 Received: by worktop.programming.kicks-ass.net (Postfix, from userid 1000) id 4057E9836F8; Thu, 28 May 2020 19:01:28 +0200 (CEST) Date: Thu, 28 May 2020 19:01:28 +0200 From: Peter Zijlstra To: Phil Auld Cc: Joel Fernandes , Nishanth Aravamudan , Julien Desfossez , Tim Chen , mingo@kernel.org, tglx@linutronix.de, pjt@google.com, torvalds@linux-foundation.org, vpillai , linux-kernel@vger.kernel.org, fweisbec@gmail.com, keescook@chromium.org, Aaron Lu , Aubrey Li , aubrey.li@linux.intel.com, Valentin Schneider , Mel Gorman , Pawan Gupta , Paolo Bonzini Subject: Re: [PATCH RFC] sched: Add a per-thread core scheduling interface Message-ID: <20200528170128.GN2483@worktop.programming.kicks-ass.net> References: <20200520222642.70679-1-joel@joelfernandes.org> <20200521085122.GF325280@hirez.programming.kicks-ass.net> <20200521134705.GA140701@google.com> <20200522125905.GM325280@hirez.programming.kicks-ass.net> <20200522213524.GD213825@google.com> <20200524140046.GA5598@lorien.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200524140046.GA5598@lorien.usersys.redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 24, 2020 at 10:00:46AM -0400, Phil Auld wrote: > On Fri, May 22, 2020 at 05:35:24PM -0400 Joel Fernandes wrote: > > On Fri, May 22, 2020 at 02:59:05PM +0200, Peter Zijlstra wrote: > > [..] > > > > > It doens't allow tasks for form their own groups (by for example setting > > > > > the key to that of another task). > > > > > > > > So for this, I was thinking of making the prctl pass in an integer. And 0 > > > > would mean untagged. Does that sound good to you? > > > > > > A TID, I think. If you pass your own TID, you tag yourself as > > > not-sharing. If you tag yourself with another tasks's TID, you can do > > > ptrace tests to see if you're allowed to observe their junk. > > > > But that would require a bunch of tasks agreeing on which TID to tag with. > > For example, if 2 tasks tag with each other's TID, then they would have > > different tags and not share. Well, don't do that then ;-) > > What's wrong with passing in an integer instead? In any case, we would do the > > CAP_SYS_ADMIN check to limit who can do it. So the actual permission model can be different depending on how broken the hardware is. > > Also, one thing CGroup interface allows is an external process to set the > > cookie, so I am wondering if we should use sched_setattr(2) instead of, or in > > addition to, the prctl(2). That way, we can drop the CGroup interface > > completely. How do you feel about that? > > > > I think it should be an arbitrary 64bit value, in both interfaces to avoid > any potential reuse security issues. > > I think the cgroup interface could be extended not to be a boolean but take > the value. With 0 being untagged as now. How do you avoid reuse in such a huge space? That just creates yet another problem for the kernel to keep track of who is who. With random u64 numbers, it even becomes hard to determine if you're sharing at all or not. Now, with the current SMT+MDS trainwreck, any sharing is bad because it allows leaking kernel privates. But under a less severe thread scenario, say where only user data would be at risk, the ptrace() tests make sense, but those become really hard with random u64 numbers too. What would the purpose of random u64 values be for cgroups? That only replicates the problem of determining uniqueness there. Then you can get two cgroups unintentionally sharing because you got lucky. Also, fundamentally, we cannot have more threads than TID space, it's a natural identifier.