linux-kernel - Re: [PATCH v10 2/5] mseal: add mseal syscall

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: <CAG48ez2ezHXVWg4y7yUx9Wi1CKk_KeU_7RJVBqkABjQhM=HbBg@mail.gmail.com>
Date: Tue, 16 Apr 2024 17:17:56 +0200
From: Jann Horn <jannh@...gle.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, akpm@...ux-foundation.org, 
	torvalds@...ux-foundation.org, jeffxu@...omium.org, keescook@...omium.org, 
	jannh@...gle.com, sroettger@...gle.com, willy@...radead.org, 
	gregkh@...uxfoundation.org, usama.anjum@...labora.com, corbet@....net, 
	surenb@...gle.com, merimus@...gle.com, rdunlap@...radead.org, 
	jeffxu@...gle.com, 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, deraadt@...nbsd.org
Subject: Re: [PATCH v10 2/5] mseal: add mseal syscall

On Tue, Apr 16, 2024 at 4:59 PM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
> * jeffxu@...omium.org <jeffxu@...omium.org> [240415 12:35]:
> > From: Jeff Xu <jeffxu@...omium.org>
> >
> > The new mseal() is an syscall on 64 bit CPU, and with
> > following signature:
> >
> > int mseal(void addr, size_t len, unsigned long flags)
> > addr/len: memory range.
> > flags: reserved.
[...]
> No per-vma change is checked prior to entering a per-vma modification
> loop today. This means that mseal() differs in behaviour in "up-front
> failure" vs "partial change failure" that exists in every other
> function.
>
> I'm not saying it's wrong or that it's right - I'm just wondering what
> the direction is here.  Either we should do as much up-front as
> possible or keep with tradition and have (partial) success where
> possible.

FWIW, in the current version, I think ENOMEM can happen both in the
up-front check (for calling the syscall on unmapped ranges) as well as
in the later loop (for VMA splitting failure).

I think no matter what we do, a process that gets an error other than
ENOSYS from mseal() will probably not get much actionable information
from the return value... no matter whether sealing worked partly or
not at all, the process will have the same choice between either
exiting (if it treats sealing failure as a fatal error for security
reasons) or continuing as if the sealing had worked.