From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37A47C46CD2 for ; Wed, 24 Jan 2024 18:55:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B55586B007D; Wed, 24 Jan 2024 13:55:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B04456B0080; Wed, 24 Jan 2024 13:55:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A4BE6B0081; Wed, 24 Jan 2024 13:55:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 849D86B007D for ; Wed, 24 Jan 2024 13:55:55 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4C89CA16C5 for ; Wed, 24 Jan 2024 18:55:55 +0000 (UTC) X-FDA: 81715109070.23.B2B78B5 Received: from mail-oa1-f46.google.com (mail-oa1-f46.google.com [209.85.160.46]) by imf13.hostedemail.com (Postfix) with ESMTP id 7C72A20009 for ; Wed, 24 Jan 2024 18:55:52 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=cAt4yNy7; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.46 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706122552; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=HzxBYWU0XLGvtFhW2j53HrOFywmcvwVn8sjJljXglm0=; b=Duqi0EZ/YbWw3H3VAwc5+6Ln9a69T6Vs2JB5O+xDW+Wxf5Wz9Qw4oC1lSUnEZ+3k06wUIW 6jaKT0ZC58G4v/7xB8gjtezo8WnPDR5Lu8BoBPsn3fOG58jXdI/EGdaZHh0IUIuWzy5saM MH8eaC1rH2dd0KC0HdDrJwM9kMORiFc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=cAt4yNy7; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.46 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706122552; a=rsa-sha256; cv=none; b=lyUKpMx0b5HnkJvypfG4yclcM3q6aytiQ9RuQJaHN20krv/N3Cdy1QsxbeH1QU4SEKRNyw tUvUqjj9zgRAo6t1/OiwwnF4riHmYllaB4Do8Y9sHs+pPJuysELD0Bw4qN17S0FFqu2aXT f2N1HuyC/r4fxED4T/toixLy0fhgo30= Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-20536d5c5c7so3419683fac.2 for ; Wed, 24 Jan 2024 10:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706122551; x=1706727351; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HzxBYWU0XLGvtFhW2j53HrOFywmcvwVn8sjJljXglm0=; b=cAt4yNy77hguB0Wjn9F3eTNr60s6DsTAw4kU0yVkim0s1je7xn5rm6/Loh8sD0fRXR yi94jVVE6jJtvFWEBDYLUNfrUKPelgggI51xJC1iNda5U4jhnuqwJE/dK9z5mPhyIc1Z LyWdVUqbGLHAF3v3BwQwE/u8euTovAqdBrerI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706122551; x=1706727351; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HzxBYWU0XLGvtFhW2j53HrOFywmcvwVn8sjJljXglm0=; b=tNLZ553Rm8dWT9bbKhg4QdwIQo/3aCvfKT2m35+7pKWaz+ClfII7JCFoRB6EOOtNwR 7KCMTXtPT7WDdiDn5wX5ShOl2gbaX037Qn7+jEmjNboL+Cyo696MfnSQY5MkklejFuPe migqyB7yLcEo5JAPJzdU+UHWKfWDsqRjy4BykKBrK10lqwzaXT8krLqETFZKhaQHddXX aoxR09FEXSlW01oEcu6FGCRQ0FMiJC2JA4PQxJOBsPnnijEAZfY23OQzGcpASWUn8u0S JpBXlT3T0gVjtnkvq/KOCa9MlvxLZuRlvsozHjrR1wgNfiu8QRUPeMseMVQA+QOhjdkg /4qQ== X-Gm-Message-State: AOJu0YyMB0BvYkGBUh5krmBeaXjy6tZHMrFsEieLxUuS4lK9WFd0eYvS 0Pc0wMksfl9glSri2IAP0Q83c0YK4yjtkGcEDJXRqghUi1xyB/I9IPQaNCqUMPDwNwpSn09gVEZ lHcGN/VAnXSmPzLATfhddHBcPXvK123MAcqDw X-Google-Smtp-Source: AGHT+IHWbZarCrd4sIhzNv9IZJE3B+OX3xjBmL88b3OOmmDhwGA+wxixbMYXHijO0HSTHdoNR/Ds7SybUvl+5K4zcno= X-Received: by 2002:a05:6870:5490:b0:214:448f:e3e with SMTP id f16-20020a056870549000b00214448f0e3emr3479864oan.66.1706122551393; Wed, 24 Jan 2024 10:55:51 -0800 (PST) MIME-Version: 1.0 References: <20240122152905.2220849-1-jeffxu@chromium.org> <726.1705938579@cvs.openbsd.org> <86181.1705962897@cvs.openbsd.org> In-Reply-To: <86181.1705962897@cvs.openbsd.org> From: Jeff Xu Date: Wed, 24 Jan 2024 10:55:39 -0800 Message-ID: Subject: Re: [PATCH v7 0/4] Introduce mseal() To: Theo de Raadt Cc: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, usama.anjum@collabora.com, rdunlap@infradead.org, jeffxu@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7C72A20009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 5ok4gounznfro7bhyxs88556jz8enc6s X-HE-Tag: 1706122552-91973 X-HE-Meta: U2FsdGVkX1+Qthdu7IDgsbAz71VrSeGEjYBm9Rsm/mHGjcOtvvw5RXiDW7PO0nnWxpnQno7yQkkytW4xTeOss1Thhoel5GrHStYxllcrERTXccoMzTRv4yO7+av4ptdnSejIL5Z5JOSaX5PQ5DT40fr2jHibaLLrer39AXnuqH5Ino+PA5PPfXIhbuhLXi0hruE0fVxU492wbNHo7+pAEIWE4KxIoU1ylXF1fNhnvaCy96l/PGEsbbAbgem6Un8BovY32mTtJU/mNdehXnNihdT3hiU3NPjPqL5xiDC81vJtnOFKVxLDEy/1xEdCHfojb8km3KrvBEj9m1V1NODv6bxROtc7l8VjKLVoCJaSbfZprp3NpoXw82ALljOzKls2kyaYcMmlDfKmsChD4FiD2aR/QnLd1sDfX9T5oVHxMWh6ABKMqoMVSQsAmFzDTzD11hInDw4LGsD212LrssK7GW4QLtw49FJTL2w+/uxWFUZnYb3HsrSFuMamPOEmkRe88bKuhzMVb0kso0iqL+g6ZqVvYMJbXteMJjvdmAIzDZsYLXOU+UDVnGJvFBfZpCjBpEsOcHgh5DFp3XFWixoile0w1gXP3obCNXo3pmZ2IyW2yxtAe4zepMxPthu97LFQoJs8Esd+Moni/HK1vLrdvsPASqtcTkSZCGu+SPMkZFuDU3nbTLouD2aEHLPCoUj+haeeq7R18XxTNK2Zc8qkDftK/R3WiF1+jmWD18RF2/+pb2YKyGnO26K0j4wXczser6HX6CumG8Ccb52F44fGKF/2aYLdjAeQepMmSUaQoSFQO+J9SnhEmXao/ny5zuuBXiEqMPVYNUB2M8NWeondWtcsY0J4zaaIjYQi3bVoD6zJfYaiauMgk3hWpbyLaIupiysyAwTmFIn8UyXKRRyO9h8EX/tiBb2CLcG4CpGQg5cRHl9HnGwMFFoa/KvfHXnODfP/QWCsYMF73O0AUwI 1yrc1NOD IRp2LHQUv9nC6nUmnBJwUqxVjUF8DW373PMeeN3g1ieEVmCz/j/Lnrfeufh8zARjrKLLYgOvgu+SfL3nUZCzPhO0qHigX1e5LCg5L+9UCZghH7g9jewD1gznAjVwR0uXAxQhbWi0pDWUNefNcWDPEtsXTFB1vL8lsGkRoKgdkg5Rd+UsGbT+FwQgc18KaJ4dt1flSrnDT+LwCMi42nG8was164cZYi81PFNC+xs24IAMygmW3554kl/two0DUDHg3UP/V2D5iCEm+0lzJmlIAQxXoXHqJJE8feei6w4CWLKjzh3IZiPJmps1MVkvqwqew1UdnuGJR456k/tDJ8uQm9t4YdBPu4y3fIftWtKJY+11DS9qomWhJ6z+zYcF/trw0NsTpzVTefpz+/nx0lGVTs57bQAYG5LtSMbotYzY8Lb6Co8lUy8AMaOzyGQ7u1XITy/LWM1GOtP0xlYBxlWo8qir/UxUeEzcF7RUT9zVw+d7ItMAwWKwI4e20i21iS9pKwKzj8IUsuJEbbR9kdOLpSPgnVYdNCS4GRRWfdoCwfqqerFRhCMkxQRHCrg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Jan 22, 2024 at 2:34=E2=80=AFPM Theo de Raadt = wrote: > > Jeff Xu wrote: > > > On Mon, Jan 22, 2024 at 7:49=E2=80=AFAM Theo de Raadt wrote: > > > > > > Regarding these pieces > > > > > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > > > > the map sealed since creation. > > > > > > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my > > > research I found basically zero circumstances when you userland does > > > that. The most common circumstance is you create a RW mapping, fill = it, > > > and then change to a more restrictve mapping, and lock it. > > > > > > There are a few regions in the addressspace that can be locked while = RW. > > > For instance, the stack. But the kernel does that, not userland. I > > > found regions where the kernel wants to do this to the address space, > > > but there is no need to export useless functionality to userland. > > > > > I have a feeling that most apps that need to use mmap() in their code > > are likely using RW mappings. Adding sealing to mmap() could stop > > those mappings from being executable. Of course, those apps would > > need to change their code. We can't do it for them. > > I don't have a feeling about it. > > I spent a year engineering a complete system which exercises the maximum > amount of memory you can lock. > > I saw nothing like what you are describing. I had PROT_IMMUTABLE in my > drafts, and saw it turning into a dangerous anti-pattern. > I'm sorry, I have never looked at one line of openBSD code, prototype or not, nor did I install openBSD before. Because of this situation on my side, I failed to understand why you have such a strong opinion on PROC_SEAL in mmap() in linux kernel, based on your own OpenBSD's experience ? For PROT_SEAL in mmap(), I see it as a good and reasonable suggestion raised during the RFC process, and incorporate it into the patch set, there is nothing more and nothing less. If openBSD doesn't want it, that is fine to me, it is not that I'm trying to force this into openBSD's kernel, I understand it is a different code base. > > Also, I believe adding this to mmap() has no downsides, only > > performance gain, as Pedro Falcato pointed out in [1]. > > > > [1] https://lore.kernel.org/lkml/CAKbZUD2A+=3Dbp_sd+Q0Yif7NJqMu8p__eb4y= guq0agEcmLH8SDQ@mail.gmail.com/ > > Are you joking? You don't have any code doing that today. More feelings= ? > > OpenBSD userland has zero places it can use mmap() MAP_IMMUTABLE. > > It has two places where it has mprotect() + mimmutable() adjacent to each > other, two codepaths for late mprotect() of RELRO, and then make the RELR= O > immutable. > > I think this idea is a premature optimization, and intentionally incompat= ible. > > Like I say, I had a similar MAP_ flag for mprotect() and mmap() in my > development trees, and I recognized it was pointless, distracting develop= ers > into the wrong patterns, and I threw it out. > > > > OpenBSD now uses this for a high percent of the address space. It mi= ght > > > be worth re-reading a description of the split of responsibility rega= rding > > > who locks different types of memory in a process; > > > - kernel (the majority, based upon what ELF layout tell us), > > > - shared library linker (the next majority, dealing with shared > > > library mappings and left-overs not determinable at kernel time), > > > - libc (a small minority, mostly regarding forced mutable objects) > > > - and the applications themselves (only 1 application today) > > > > > > https://lwn.net/Articles/915662/ > > > > > > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it= marks > > > > the map as sealable. A map created without MAP_SEALABLE will not su= pport > > > > sealing, i.e. mseal() will fail. > > > > > > We definately won't be doing this. We allow a process to lock any an= d all > > > it's memory that isn't locked already, even if it means it is shootin= g > > > itself in the foot. > > > > > > I think you are going to severely hurt the power of this mechanism, > > > because you won't be able to lock memory that has been allocated by a > > > different callsite not under your source-code control which lacks the > > > MAP_SEALABLE flag. (Which is extremely common with the system-parts = of > > > a process, meaning not just libc but kernel allocated objects). > > > > > MAP_SEALABLE was an open discussion item called out on V3 [2] and V4 [3= ]. > > > > I acknowledge that additional coordination would be required if > > mapping were to be allocated by one software component and sealed in > > another. However, this is feasible. > > > > Considering the side effect of not having this flag (as discussed in > > V3/V4) and the significant implications of altering the lifetime of > > the mapping (since unmapping would not be possible), I believe it is > > reasonable to expect developers to exercise additional care and > > caution when utilizing memory sealing. > > > > [2] https://lore.kernel.org/linux-mm/20231212231706.2680890-2-jeffxu@ch= romium.org/ > > [3] https://lore.kernel.org/all/20240104185138.169307-1-jeffxu@chromium= .org/ > > I disagree *strongly*. Developers need to exercise additional care on > memory, period. Memory sealing issues is the least of their worries. > > (Except for handling RELRO, but only the ld.so developers will lose > their hair). > > > OK, so mseal and mimmutable are very different. > > mimmutable can be used by any developer on the address space easily. > > mseal requires control of the whole stack between allocation and consumpt= ion. > > I'm sorry, but I don't think you understand how dangerous this MAP_SEALAB= LE > proposal is because of the difficulties it will create for use. > > The immutable memory management we have today in OpenBSD would completely > impossible with such a flag. Seperation between allocator (that doesn't = know > what is going to happen), and consumer (that does know), is completely co= mmon > in the systems environment (meaning the interaction between DSO, libc, ot= her > libraries, and the underside of applications). > > This is not not like an application where you can simply sprinkle the fla= g > into the mmap() calls that cause you problems. That mmap() call is now i= n > someone else's code, and you CANNOT gain security advantage unless you > convince them to gain an understanding of what that flag means -- and it = is > a flag that other Linux variants don't have, not even in their #include > files. > I respect your reasoning with OpenBSD, but do you have a real example that this will be problematic for linux ? In my opinion, the extra communication part with mmap()'s owner has its pros and cons. The cons is what you mentioned: extra time for convincing and approval. The pro is that there won't be unexpected behavior from the code owner point of view, once this communication process is completed. It can reduce the possibility of introducing bugs. So far, I do not have enough information to say this is a bad idea. if you can provide a real example in the context of linux, e.g. DSO and libc you mentioned with details, that will be helpful.