linux-kernel - Re: [PATCH 4/7] Protectable Memory

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]

Date:   Wed, 7 Mar 2018 16:07:42 +0200
From:   Igor Stoppa <igor.stoppa@...wei.com>
To:     J Freyensee <why2jjj.linux@...il.com>, <david@...morbit.com>,
        <willy@...radead.org>, <keescook@...omium.org>, <mhocko@...nel.org>
CC:     <labbott@...hat.com>, <linux-security-module@...r.kernel.org>,
        <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        <kernel-hardening@...ts.openwall.com>
Subject: Re: [PATCH 4/7] Protectable Memory

On 06/03/18 05:59, J Freyensee wrote:

[...]

>> +config PROTECTABLE_MEMORY
>> +    bool
>> +    depends on MMU
> 
> 
> Curious, would you also want to depend on "SECURITY" as well, as this is 
> being advertised as a compliment to __read_only_after_init, per the file 
> header comments, as I'm assuming ro_after_init would be disabled if the 
> SECURITY Kconfig selection is *NOT* selected?

__ro_after_init is configured like this:

#if defined(CONFIG_STRICT_KERNEL_RWX) || defined(CONFIG_STRICT_MODULE_RWX)
bool rodata_enabled __ro_after_init = true;

But even if __ro_after_init and pmalloc are conceptually similar, in
practice they have - potentially - different constraints.

1) the __ro_after_init segment belongs to linear kernel memory
2) the pmalloc pools belong to vmalloc memory

There is one extra layer of indirection in pmalloc.
I am not an expert of MMUs but I suppose there might be types where it
is possible to mark pages as RO but it's not possible to have virtual
memory.

If (and this is a big "if") such MMUs exist and are supported by linux,
then __ro_after_init would be possible, while pmalloc would not be.

So it seemed more correct to focus specifically on hte enablers required
by pmalloc to perform correctly.

Open Question:

Is it ok that the API disappears in case the enablers are missing?
Or should it fall back to something else?

Dealing with lack of ReadOnly support would be pretty simple, it would
be enough to make the write-Protection conditional.

But what to do if virtual mapping is not supported?

kmalloc might not have the ability to support large requests made toward
pmalloc and this would possibly cause runtime failures.

--
igor