linux-kernel - Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM)

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: <CS45V0JP0DUN.82KGEI3U5ZGN@suppilovahvero>
Date:   Sun, 23 Apr 2023 16:14:18 +0300
From:   "Jarkko Sakkinen" <jarkko@...nel.org>
To:     "Sean Christopherson" <seanjc@...gle.com>,
        "Chao Peng" <chao.p.peng@...ux.intel.com>
Cc:     "Paolo Bonzini" <pbonzini@...hat.com>,
        "Vitaly Kuznetsov" <vkuznets@...hat.com>,
        "Jim Mattson" <jmattson@...gle.com>,
        "Joerg Roedel" <joro@...tes.org>,
        "Maciej S . Szmigiero" <mail@...iej.szmigiero.name>,
        "Vlastimil Babka" <vbabka@...e.cz>,
        "Vishal Annapurve" <vannapurve@...gle.com>,
        "Yu Zhang" <yu.c.zhang@...ux.intel.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        <dhildenb@...hat.com>, "Quentin Perret" <qperret@...gle.com>,
        <tabba@...gle.com>, "Michael Roth" <michael.roth@....com>,
        <wei.w.wang@...el.com>, "Mike Rapoport" <rppt@...nel.org>,
        "Liam Merwick" <liam.merwick@...cle.com>,
        "Isaku Yamahata" <isaku.yamahata@...il.com>,
        "Ackerley Tng" <ackerleytng@...gle.com>, <kvm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: Rename restrictedmem => guardedmem? (was: Re: [PATCH v10 0/9]
 KVM: mm: fd-based approach for supporting KVM)

On Mon Apr 17, 2023 at 6:40 PM EEST, Sean Christopherson wrote:
> What do y'all think about renaming "restrictedmem" to "guardedmem"?
>
> I want to start referring to the code/patches by its syscall/implementation name
> instead of "UPM", as "UPM" is (a) very KVM centric, (b) refers to the broader effort
> and not just the non-KVM code, and (c) will likely be confusing for future reviewers
> since there's nothing in the code that mentions "UPM" in any way.
>
> But typing out restrictedmem is quite tedious, and git grep shows that "rmem" is
> already used to refer to "reserved memory".
>
> Renaming the syscall to "guardedmem"...
>
>   1. Allows for a shorthand and namespace, "gmem", that isn't already in use by
>      the kernel (see "reserved memory above").
>  
>   2. Provides a stronger hint as to its purpose.  "Restricted" conveys that the
>      allocated memory is limited in some way, but doesn't capture how the memory
>      is restricted, e.g. "restricted" could just as easily mean that the allocation
>      can be restricted to certain types of backing stores or something.  "Guarded"
>      on the other hand captures that the memory has extra defenses of some form.
>
>   3. Is shorter to type and speak.  Work smart, not hard :-)
>
>   4. Isn't totally wrong for the KVM use case if someone assumes the "g" means
>      "guest" when reading mail and whatnot.
>
>
> P.S. I trimmed the Cc/To substantially for this particular discussion to avoid
>      spamming folks that don't (yet) care about this stuff with another potentially
>      lengthy thread.  Feel free to add (back) any people/lists.

I guess 'guarded' could be a good noun in the sense that it does not
get easily mixed up to anything pre-existing, and it does give the idea
of the purpose.

BR, Jarkko