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: <9A9A2DFD-45FA-45EA-95FB-5FC0DC5A9E2E@fb.com>
Date:   Tue, 18 Oct 2022 15:05:24 +0000
From:   Song Liu <songliubraving@...a.com>
To:     Christoph Hellwig <hch@....de>
CC:     Song Liu <songliubraving@...a.com>, Song Liu <song@...nel.org>,
        Linux-MM <linux-mm@...ck.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        X86 ML <x86@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
        Kernel Team <Kernel-team@...com>,
        "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "urezki@...il.com" <urezki@...il.com>
Subject: Re: [RFC v2 0/4] vmalloc_exec for modules and BPF programs



> On Oct 18, 2022, at 7:50 AM, Christoph Hellwig <hch@....de> wrote:
> 
> On Mon, Oct 17, 2022 at 04:23:52PM +0000, Song Liu wrote:
>>> Well, nothing explains what the method is to avoid having memory
>>> that is mapped writable and executable at the same time, which really
>>> could use some explanation here (and in the main patch as well).
>> 
>> Thanks for the feedback. I will add this. 
>> 
>> Does the code look good to you? I personally think patch 1, 2, 4 could
>> ship with a little more work. 
> 
> I only took a quick look and I'm not sure how the W^X actually works.
> Yes, it alls into the text poke helpers, but how do these work on
> less than page sized allocations?

Aha, I guess I understand your point (and concern) now. 

It is the same as text poke into static kernel text: we create a local 
writable mapping to the memory we need to update. For less than page
sized allocation, this mapping does have access to X memory that may 
belong to a different allocation, just like text poke into static 
kernel text. 

Maybe we need something like vcopy_exec(x_mem, tmp_buf, size), where
we explicitly check the allowed memory of x_mem is bigger or equal to
size. And users of vmalloc_exec should only use vcopy_exec to update
memory from vmalloc_exec. 

Does this make sense? Did I understand your concern correctly? 

Thanks,
Song

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ