linux-kernel - Re: [PATCH RFC 01/10] vmalloc: Add basic perm alloc implementation

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: <4be82a3571fb25bb096f2c98dc32d07da51af3d4.camel@intel.com>
Date:   Tue, 24 Nov 2020 19:59:44 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "hch@...radead.org" <hch@...radead.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "ast@...nel.org" <ast@...nel.org>,
        "Weiny, Ira" <ira.weiny@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "luto@...nel.org" <luto@...nel.org>
Subject: Re: [PATCH RFC 01/10] vmalloc: Add basic perm alloc implementation

On Tue, 2020-11-24 at 10:19 +0000, hch@...radead.org wrote:
> But I thought that using those pgprot flags was still sort
> overloading
> > the meaning of pgprot. My understanding was that it is supposed to
> > hold
> > the actual bits set in the PTE. For example large pages or TLB
> > hints
> > (like PAGE_KERNEL_EXEC_CONT) could set or unset extra bits, so
> > asking
> > for PAGE_KERNEL_EXEC wouldn't necessarily mean "set these bits in
> > all
> > of the PTEs", it could mean something more like "infer what I want
> > from
> > these bits and do that".
> > 
> > x86's cpa will also avoid changing NX if it is not supported, so if
> > the
> > caller asked for PAGE_KERNEL->PAGE_KERNEL_EXEC in perm_change() it
> > should not necessarily bother setting all of the PAGE_KERNEL_EXEC
> > bits
> > in the actual PTEs. Asking for PERM_RW->PERM_RWX on the other hand,
> > would let the implementation do whatever it needs to set the memory
> > executable, like set_memory_x() does. It should work either way but
> > seems like the expectations would be a little clearer with the
> > PERM_
> > flags.
> 
> Ok, maybe that is an argument, and we should use the new flags more
> broadly.

They might make sense to live in set_memory.h then. Separate from this
patchset, a call like set_memory(addr, numpages, PERM_R) could be more
efficient than two calls to set_memory_ro() and set_memory_nx(). Not
that it happens very much outside of vmalloc usages. But just to try to
think where else it could be used.

> > Could easily wrap this one, but just to clarify, do you mean lines
> > over
> > 80 chars? There were already some over 80 in vmalloc before the
> > move to
> > 100 chars, so figured it was ok to stretch out now.
> 
> CodingStyle still says 80 characters unless you have an exception
> where
> a longer line improves the readability.  The quoted code absolutely
> does not fit the definition of an exception or improves readability.

Fair enough.

And to the other comment in your first mail, glad to do this and
finally send it out. This series has been sitting in a local branch for
most of the year while stuff kept interrupting it.