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: <CABi2SkWOz8fX1M6Jx0Xh1y-866Zsn6fweK9-ZB30PRkPPgdgEQ@mail.gmail.com>
Date: Mon, 7 Oct 2024 08:02:00 -0700
From: Jeff Xu <jeffxu@...omium.org>
To: Theo de Raadt <deraadt@...nbsd.org>
Cc: Randy Dunlap <rdunlap@...radead.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

Hi Theo

On Fri, Oct 4, 2024 at 6:04 PM Theo de Raadt <deraadt@...nbsd.org> wrote:
>
> 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.

Apology  for delay.
Yes, mseal does block such patterns.

Thanks
-Jeff

> The sentence doesn't indicate that mseal() has a response to the stated
> problem.
>