linux-kernel - Re: [RFC PATCH v3 11/11] mseal:add documentation

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: Sat, 20 Jan 2024 08:23:44 -0700
From: "Theo de Raadt" <deraadt@...nbsd.org>
To: Jeff Xu <jeffxu@...omium.org>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
    Stephen Röttger <sroettger@...gle.com>,
    Jeff Xu <jeffxu@...gle.com>, akpm@...ux-foundation.org,
    keescook@...omium.org, jannh@...gle.com, willy@...radead.org,
    gregkh@...uxfoundation.org, jorgelo@...omium.org,
    groeck@...omium.org, linux-kernel@...r.kernel.org,
    linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
    pedro.falcato@...il.com, dave.hansen@...el.com,
    linux-hardening@...r.kernel.org
Subject: Re: [RFC PATCH v3 11/11] mseal:add documentation

Some notes about compatibility between mimmutable(2) and mseal().

This morning, the "RW -> R demotion" code in mimmutable(2) was removed.
As described previously, that was a development crutch to solved a problem
but we found a better way with a new ELF section which is available at
compile time with __attribute__((section(".openbsd.mutable"))).   Which
works great.

I am syncronizing the madvise / msync behaviour further, we will be compatible.
I have worried about madvise / msync for a long time, and audited vast amounts
of the software ecosystem to come to a conclusion we can be more strict, but
I never acted upon it.

BTW, on OpenBSD and probably other related BSD operating systems,
MADV_DONTNEED is non-destructive.  However we have a destructive
operation called MADV_FREE.  msync() MS_INVALIDATE is also destructive.
But all of these operations will now be prohibited, to syncronize the
error return value situation.

There is an one large difference remainig between mimmutable() and mseal(),
which is how other system calls behave.

We return EPERM for failures in all the system calls that fail upon
immutable memory (since Oct 2022).

You are returning EACESS.

Before it is too late, do you want to reconsider that return value, or
do you have a justification for the choice?

I think this remains the blocker which would prevent software from doing

#define mimmutable(addr, len)  mseal(addr, len, 0)