linux-kernel - Re: [RFC PATCH v1 0/8] Introduce 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: <CAEAAPHYgg49WtpE7Jdq6HDecFp5RHPhdxtPTUaNF12RONu5aDA@mail.gmail.com>
Date:   Thu, 19 Oct 2023 10:00:33 +0200
From:   Stephen Röttger <sroettger@...gle.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Theo de Raadt <deraadt@...nbsd.org>, Jeff Xu <jeffxu@...gle.com>,
        jeffxu@...omium.org, akpm@...ux-foundation.org,
        keescook@...omium.org, jorgelo@...omium.org, groeck@...omium.org,
        linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-mm@...ck.org, jannh@...gle.com, surenb@...gle.com,
        alex.sierra@....com, apopple@...dia.com,
        aneesh.kumar@...ux.ibm.com, axelrasmussen@...gle.com,
        ben@...adent.org.uk, catalin.marinas@....com, david@...hat.com,
        dwmw@...zon.co.uk, ying.huang@...el.com, hughd@...gle.com,
        joey.gouly@....com, corbet@....net, wangkefeng.wang@...wei.com,
        Liam.Howlett@...cle.com, lstoakes@...il.com, willy@...radead.org,
        mawupeng1@...wei.com, linmiaohe@...wei.com, namit@...are.com,
        peterx@...hat.com, peterz@...radead.org, ryan.roberts@....com,
        shr@...kernel.io, vbabka@...e.cz, xiujianfeng@...wei.com,
        yu.ma@...el.com, zhangpeng362@...wei.com, dave.hansen@...el.com,
        luto@...nel.org, linux-hardening@...r.kernel.org
Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall

> I do like us starting with just "mimmutable()", since it already
> exists. Particularly if chrome already knows how to use it.
>
> Maybe add a flag field (require it to be zero initially) just to allow
> any future expansion. Maybe the chrome team has *wanted* to have some
> finer granularity thing and currently doesn't use mimmutable() in some
> case?

Yes, we do have a use case in Chrome to split the sealing into unmap and
mprotect which will allow us to seal additional pages that we can't seal with
pure mimmutable().
For example, we have pkey-tagged RWX memory that we want to seal. Since
the memory is already RWX and the pkey controls write access, we don't care
about permission changes but sometimes we do need to mprotect data only
pages.
But the munmap sealing will provide protection against implicit changes of the
pkey in this case which would happen if a page gets unmapped and another
mapped in its place.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4005 bytes)