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.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ