linux-kernel - Re: [PATCH v2 1/1] mseal: update mseal.rst

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] [day] [month] [year] [list]

Message-ID: <15868.1728090271@cvs.openbsd.org>
Date: Fri, 04 Oct 2024 19:04:31 -0600
From: "Theo de Raadt" <deraadt@...nbsd.org>
To: Randy Dunlap <rdunlap@...radead.org>
cc: Jeff Xu <jeffxu@...omium.org>, akpm@...ux-foundation.org,
    keescook@...omium.org, corbet@....net, jorgelo@...omium.org,
    groeck@...omium.org, linux-kernel@...r.kernel.org,
    linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
    jannh@...gle.com, sroettger@...gle.com, pedro.falcato@...il.com,
    linux-hardening@...r.kernel.org, willy@...radead.org,
    gregkh@...uxfoundation.org, torvalds@...ux-foundation.org,
    usama.anjum@...labora.com, surenb@...gle.com, merimus@...gle.com,
    lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, enh@...gle.com
Subject: Re: [PATCH v2 1/1] mseal: update mseal.rst

Randy Dunlap <rdunlap@...radead.org> wrote:

> On 10/4/24 9:52 AM, Jeff Xu wrote:
> >> above is not a sentence but I don't know how to fix it.
> >>
> > Would below work ?
> > 
> > Certain destructive madvise behaviors, specifically MADV_DONTNEED,
> > MADV_FREE, MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK,
> > MADV_WIPEONFORK, can pose risks when applied to anonymous memory by
> > threads without write permissions. These behaviors have the potential
> > to modify region contents by discarding pages, effectively performing
> > a memset(0) operation on the anonymous memory.
> 
> Yes, that works.
> Or at least it explains the problem, like Theo said.

In OpenBSD, mimmutable() solves this problem (in later code iterations).

In Linux, does mseal() solve the problem or not?  The statement doesn't
answer this question.  It only explains the problem.

If it doesn't solve the problem, that's pretty surprising (weaker than
mimmutable).

During development I wrote a fake little program which placed an 'int =
1' resided into a zone of readonly memory (.data), and then imagined "an
attacker gets enough control to perform an madvise(), but only had
enough control, and has to return to normal control flow immediately".
The madvise() operations was able to trash the int, altering the
program's later behaviour.  So I researched the matter more, and adapted
mimmutable() to block ALL system-call variations similar to 'write to a
not-permitted region'.

So the question remains:  Does mseal() block such a (rare) pattern or not.
The sentence doesn't indicate that mseal() has a response to the stated
problem.