linux-kernel - Re: [PATCH v7 13/14] module: Do not set nx for module memory before freeing

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: <55a4fb61164d7ecf5950e29d1fa2aea52a1b958f.camel@intel.com>
Date:   Thu, 6 Dec 2018 20:21:57 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "luto@...nel.org" <luto@...nel.org>,
        "jeyu@...nel.org" <jeyu@...nel.org>,
        "namit@...are.com" <namit@...are.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "nadav.amit@...il.com" <nadav.amit@...il.com>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "linux_dti@...oud.com" <linux_dti@...oud.com>,
        "will.deacon@....com" <will.deacon@....com>,
        "bp@...en8.de" <bp@...en8.de>
Subject: Re: [PATCH v7 13/14] module: Do not set nx for module memory before
 freeing

On Thu, 2018-12-06 at 10:52 -0800, Andy Lutomirski wrote:
> On Wed, Dec 5, 2018 at 12:52 AM Nadav Amit <namit@...are.com> wrote:
> > 
> > When module memory is about to be freed, there is no apparent reason to
> > make it (and its data) executable, but that's exactly what is done
> > today. This is not efficient and not secure.
> > 
> > There are various theories why it was done, but none of them seem as
> > something that really require it today. nios2 uses kmalloc for module
> > memory, but anyhow it does not change the PTEs of the module memory.  In
> > x86, changing vmalloc'd memory mappings also modifies the direct mapping
> > alias, but the NX-bit is not modified in such way.
> > 
> > So let's remove it. Andy suggested that the changes of the PTEs can be
> > avoided (excluding the direct-mapping alias), which is true. However,
> > in x86 it requires some cleanup of the contiguous page allocator, which
> > is outside of the scope of this patch-set.
> > 
> 
> 
> I'm okay with this, but I'd like to see Rick's stuff get rebased on
> top of it and clean it up for real.

Nadav,

Hmm, since you are trying to move things forward and not close all cases in one
swoop, would it make sense to split the modules W^X mission from this patchset?

Thanks,

Rick