netdev - Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

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: <50D768D7-15BF-43B8-A5FD-220B25595336@gmail.com>
Date: Thu, 1 Jun 2023 16:54:36 -0700
From: Nadav Amit <nadav.amit@...il.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "kent.overstreet@...ux.dev" <kent.overstreet@...ux.dev>,
 Thomas Gleixner <tglx@...utronix.de>,
 "mcgrof@...nel.org" <mcgrof@...nel.org>,
 "deller@....de" <deller@....de>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 "davem@...emloft.net" <davem@...emloft.net>,
 "linux@...linux.org.uk" <linux@...linux.org.uk>,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
 "hca@...ux.ibm.com" <hca@...ux.ibm.com>,
 "catalin.marinas@....com" <catalin.marinas@....com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
 "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
 "palmer@...belt.com" <palmer@...belt.com>,
 "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
 "mpe@...erman.id.au" <mpe@...erman.id.au>,
 "x86@...nel.org" <x86@...nel.org>,
 "tsbogend@...ha.franken.de" <tsbogend@...ha.franken.de>,
 "rppt@...nel.org" <rppt@...nel.org>,
 "linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
 "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
 "christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
 "rostedt@...dmis.org" <rostedt@...dmis.org>,
 Will Deacon <will@...nel.org>,
 "dinguyen@...nel.org" <dinguyen@...nel.org>,
 "naveen.n.rao@...ux.ibm.com" <naveen.n.rao@...ux.ibm.com>,
 "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
 "linux-modules@...r.kernel.org" <linux-modules@...r.kernel.org>,
 "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
 "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
 "song@...nel.org" <song@...nel.org>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>,
 "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
 Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble
 memory as ROX



> On Jun 1, 2023, at 1:50 PM, Edgecombe, Rick P <rick.p.edgecombe@...el.com> wrote:
> 
> On Thu, 2023-06-01 at 14:38 -0400, Kent Overstreet wrote:
>> On Thu, Jun 01, 2023 at 06:13:44PM +0000, Edgecombe, Rick P wrote:
>>>> text_poke() _does_ create a separate RW mapping.
>>> 
>>> Sorry, I meant a separate RW allocation.
>> 
>> Ah yes, that makes sense
>> 
>> 
>>> 
>>>> 
>>>> The thing that sucks about text_poke() is that it always does a
>>>> full
>>>> TLB
>>>> flush, and AFAICT that's not remotely needed. What it really
>>>> wants to
>>>> be
>>>> doing is conceptually just
>>>> 
>>>> kmap_local()
>>>> mempcy()
>>>> kunmap_loca()
>>>> flush_icache();
>>>> 
>>>> ...except that kmap_local() won't actually create a new mapping
>>>> on
>>>> non-highmem architectures, so text_poke() open codes it.
>>> 
>>> Text poke creates only a local CPU RW mapping. It's more secure
>>> because
>>> other threads can't write to it.
>> 
>> *nod*, same as kmap_local
> 
> It's only used and flushed locally, but it is accessible to all CPU's,
> right?
> 
>> 
>>> It also only needs to flush the local core when it's done since
>>> it's
>>> not using a shared MM.
>>  
>> Ahh! Thanks for that; perhaps the comment in text_poke() about IPIs
>> could be a bit clearer.
>> 
>> What is it (if anything) you don't like about text_poke() then? It
>> looks
>> like it's doing broadly similar things to kmap_local(), so should be
>> in the same ballpark from a performance POV?
> 
> The way text_poke() is used here, it is creating a new writable alias
> and flushing it for *each* write to the module (like for each write of
> an individual relocation, etc). I was just thinking it might warrant
> some batching or something.

I am not advocating to do so, but if you want to have many efficient
writes, perhaps you can just disable CR0.WP. Just saying that if you
are about to write all over the memory, text_poke() does not provide
too much security for the poking thread.