linux-kernel - Re: [PATCH 07/32] mm: Bring back vmalloc

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: <ce5125be-464e-44ad-8d9e-7c818f794db1@csgroup.eu>
Date:   Sun, 14 May 2023 18:39:00 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Lorenzo Stoakes <lstoakes@...il.com>,
        Christoph Hellwig <hch@...radead.org>,
        Kent Overstreet <kent.overstreet@...ux.dev>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-bcachefs@...r.kernel.org" <linux-bcachefs@...r.kernel.org>,
        Kent Overstreet <kent.overstreet@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Uladzislau Rezki <urezki@...il.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec



Le 13/05/2023 à 15:25, Lorenzo Stoakes a écrit :
> On Tue, May 09, 2023 at 02:12:41PM -0700, Lorenzo Stoakes wrote:
>> On Tue, May 09, 2023 at 01:46:09PM -0700, Christoph Hellwig wrote:
>>> On Tue, May 09, 2023 at 12:56:32PM -0400, Kent Overstreet wrote:
>>>> From: Kent Overstreet <kent.overstreet@...il.com>
>>>>
>>>> This is needed for bcachefs, which dynamically generates per-btree node
>>>> unpack functions.
>>>
>>> No, we will never add back a way for random code allocating executable
>>> memory in kernel space.
>>
>> Yeah I think I glossed over this aspect a bit as it looks ostensibly like simply
>> reinstating a helper function because the code is now used in more than one
>> place (at lsf/mm so a little distracted :)
>>
>> But it being exported is a problem. Perhaps there's another way of acheving the
>> same aim without having to do so?
> 
> Just to be abundantly clear, my original ack was a mistake (I overlooked
> the _exporting_ of the function being as significant as it is and assumed
> in an LSF/MM haze that it was simply a refactoring of _already available_
> functionality rather than newly providing a means to allocate directly
> executable kernel memory).
> 
> Exporting this is horrible for the numerous reasons expounded on in this
> thread, we need a different solution.
> 
> Nacked-by: Lorenzo Stoakes <lstoakes@...il.com>
> 

I addition to that, I still don't understand why you bring back 
vmalloc_exec() instead of using module_alloc().

As reminded in a previous response, some architectures like powerpc/32s 
cannot allocate exec memory in vmalloc space. On powerpc this is because 
exec protection is performed on 256Mbytes segments and vmalloc space is 
flagged non-exec. Some other architectures have a constraint on distance 
between kernel core text and other text.

Today you have for instance kprobes in the kernel that need dynamic exec 
memory. It uses module_alloc() to get it. On some architectures you also 
have ftrace that gets some exec memory with module_alloc().

So, I still don't understand why you cannot use module_alloc() and need 
vmalloc_exec() instead.

Thanks
Christophe