linux-kernel - Re: [PATCH v1 1/2] mseal: Two fixes for madvise(MADV

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: <35887.1729637650@cvs.openbsd.org>
Date: Tue, 22 Oct 2024 16:54:10 -0600
From: "Theo de Raadt" <deraadt@...nbsd.org>
To: Vlastimil Babka <vbabka@...e.cz>
cc: Jeff Xu <jeffxu@...omium.org>,
    Pedro Falcato <pedro.falcato@...il.com>, akpm@...ux-foundation.org,
    keescook@...omium.org, torvalds@...ux-foundation.org,
    usama.anjum@...labora.com, corbet@....net, Liam.Howlett@...cle.com,
    lorenzo.stoakes@...cle.com, jeffxu@...gle.com, 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,
    linux-hardening@...r.kernel.org, willy@...radead.org,
    gregkh@...uxfoundation.org, surenb@...gle.com, merimus@...gle.com,
    rdunlap@...radead.org, stable@...r.kernel.org
Subject: Re: [PATCH v1 1/2] mseal: Two fixes for madvise(MADV_DONTNEED) when sealed

Vlastimil Babka <vbabka@...e.cz> wrote:

> On 10/17/24 22:57, Jeff Xu wrote:
> > On Thu, Oct 17, 2024 at 1:49 PM Pedro Falcato <pedro.falcato@...il.com> wrote:
> >> >
> >> > > > For file-backed, private, read-only memory mappings, we previously did
> >> > > > not block the madvise(MADV_DONTNEED). This was based on
> >> > > > the assumption that the memory's content, being file-backed, could be
> >> > > > retrieved from the file if accessed again. However, this assumption
> >> > > > failed to consider scenarios where a mapping is initially created as
> >> > > > read-write, modified, and subsequently changed to read-only. The newly
> >> > > > introduced VM_WASWRITE flag addresses this oversight.
> >> > >
> >> > > We *do not* need this. It's sufficient to just block discard operations on read-only
> >> > > private mappings.
> >> > I think you meant blocking madvise(MADV_DONTNEED) on all read-only
> >> > private file-backed mappings.
> >> >
> >> > I considered that option, but there is a use case for madvise on those
> >> > mappings that never get modified.
> >> >
> >> > Apps can use that to free up RAM. e.g. Considering read-only .text
> >> > section, which never gets modified, madvise( MADV_DONTNEED) can free
> >> > up RAM when memory is in-stress, memory will be reclaimed from a
> >> > backed-file on next read access. Therefore we can't just block all
> >> > read-only private file-backed mapping, only those that really need to,
> >> > such as mapping changed from rw=>r (what you described)
> >>
> >> Does anyone actually do this? If so, why? WHYYYY?
> >>
> > This is a legit use case, I can't argue that it isn't.
> 
> Could the same effect be simply achieved with MADV_COLD/MADV_PAGEOUT? That
> should be able to reclaim the pages as well if they are indeed not used, but
> it's non-destructive and you don't want to allow destructive madvise anyway
> (i.e. no throwing away data that would be replaced by zeroes or original
> file content on the next touch) so it seems overall a better fit for sealed
> areas?

Comment from the sidelines: That seems clever enough.