linux-kernel - Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHVum0dS+QxWFSK+evxQtZDHkZZx9pr0m_jEDHc9ovd5jQcfaA@mail.gmail.com>
Date:   Wed, 16 Dec 2020 12:02:37 -0800
From:   Vipin Sharma <vipinsh@...gle.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     David Rientjes <rientjes@...gle.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Brijesh <brijesh.singh@....com>, Jon <jon.grimm@....com>,
        Eric <eric.vantassell@....com>, pbonzini@...hat.com,
        Sean Christopherson <seanjc@...gle.com>, lizefan@...wei.com,
        hannes@...xchg.org, Janosch Frank <frankja@...ux.ibm.com>,
        corbet@....net, joro@...tes.org, vkuznets@...hat.com,
        wanpengli@...cent.com, Jim Mattson <jmattson@...gle.com>,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
        Matt Gingell <gingell@...gle.com>,
        Dionna Glaze <dionnaglaze@...gle.com>, kvm@...r.kernel.org,
        x86@...nel.org, cgroups@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [Patch v3 0/2] cgroup: KVM: New Encryption IDs cgroup controller

On Wed, Dec 9, 2020 at 12:59 PM Tejun Heo <tj@...nel.org> wrote:
> * I don't have an overall objection. In terms of behavior, the only thing
>   which stood out was input rejection depending on the current usage. The
>   preferred way of handling that is rejecting future allocations rather than
>   failing configuration as that makes it impossible e.g. to lower limit and
>   drain existing usages from outside the container.

Thanks. In next version of the patch I will remove rejection of max value
based on current usage.

On Wed, Dec 16, 2020 at 7:27 AM Tejun Heo <tj@...nel.org> wrote:
> On Thu, Dec 10, 2020 at 03:44:35PM -0800, David Rientjes wrote:
> > Concern with a single misc controller would be that any subsystem that
> > wants to use it has to exactly fit this support: current, max, stat,
> > nothing more.  The moment a controller needs some additional support, and
> > its controller is already implemented in previous kernel versionv as a
> > part of "misc," we face a problem.
>
> Yeah, that's a valid concern, but given the history, there doesn't seem to
> be much need beyond that for these use cases and the limited need seems
> inherent to the way the resources are defined and consumed. So yeah, it can
> either way.

I think a misc controller should be able support other "Resource Distribution
Models" mentioned in the cgroup v2 documentation besides limits. There might be
use cases in future which want to use weight, protection or allocation models.
If that happens it will be more difficult to support these different resources.
This will also mean the same hierarchy might get charged differently by the
same controller.

I like the idea of having a separate controller to keep the code simple and
easier for maintenance.

If you decide to have a separate misc controller please let me know what will
be the overall expectations and I can change my patch to reflect that,
otherwise I can send out a new patch with just removal of max input rejection.

My understanding with a "misc" controller is it will be something like
- cgroup v2
  cgroup/misc.encryption_ids.{sev, tdx, seid}.{stat, max, current}

- cgroup v1
  cgroup/misc/misc.encryption_ids.{sev, tdx, seid}.{stat, max, current}

Thanks
Vipin