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 5E5B9C46CA1 for ; Tue, 17 Oct 2023 12:56:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D79F28D010E; Tue, 17 Oct 2023 08:56:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D036A8D000C; Tue, 17 Oct 2023 08:56:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA3138D010E; Tue, 17 Oct 2023 08:56:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A77E48D000C for ; Tue, 17 Oct 2023 08:56:27 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 808F440A21 for ; Tue, 17 Oct 2023 12:56:27 +0000 (UTC) X-FDA: 81354952014.27.7A1EB79 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id 52B9FA0019 for ; Tue, 17 Oct 2023 12:56:25 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ltmteh5H; dmarc=none; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697547386; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=TjP165kdnXnZeWEs6lPqJmTemVZVmWMQm34b8bWqLdI=; b=l1WTTWvZx7sRPhg0gOl21XQKjjUr5sS3GVi145OmetGRXWzK/vyFlNcUTsjOw/qujiI2DI GQT+Ugs885Njk4ObtQrfyZ7PDnrlfaKD3SBxEptSG5VzCOKGbjBFub82nFSSTvjcLLDKd3 q9uMSfRwc0e8FxCnrCQXrKOGSdWA5MY= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ltmteh5H; dmarc=none; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697547386; a=rsa-sha256; cv=none; b=NepJCmCGpdyN7GQfOiOpdU6Jv+rngZ5pI5E8qylMIOFYbiCoV9JUqkteWNxbqgxaiAjb6u uAPKWG+drzWJAKTo4Y0kPBuSkPutKYN7MIDwalN6G5oovwPORddc/kNVevOaeEJ4f6hNpY 6LgV8PFhedva0TJAngEdDdf3Bi/ls2I= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=TjP165kdnXnZeWEs6lPqJmTemVZVmWMQm34b8bWqLdI=; b=ltmteh5Hzny7tVZzXlOFG8QS/p 3YJ7eG9UUk08wyDbfGAQhMuh2NIvNEbkORJg36P/Z7x/CSuUN8nmmbED0vYf4sl03v59vYlxP/X56 2IZmlUzb6CRzr140Z+kAr+DxyJ17yI+1JpUe3xicV5+2NDhzq5HzvC/R6iouB6ETf/v1gXWHAIFCH eVGww/Mle6QpVDNH85gRMu4l6/FE6AUSDZ+f+b0HK1tDYdEsZFCwvS6bG5VLA5xOUHXHLu+N5j9U9 5nBRieVWKifUAdaMytJ9HB7s5/cAbKTWuOuMvWb5e3CAuDCvwAIXQKJMb3syDXVkZ15gMj+ez9pPd w5et+yUA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qsjcJ-00CQmQ-7n; Tue, 17 Oct 2023 12:56:11 +0000 Date: Tue, 17 Oct 2023 13:56:11 +0100 From: Matthew Wilcox To: Jeff Xu Cc: jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, sroettger@google.com, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, jannh@google.com, surenb@google.com, alex.sierra@amd.com, apopple@nvidia.com, aneesh.kumar@linux.ibm.com, axelrasmussen@google.com, ben@decadent.org.uk, catalin.marinas@arm.com, david@redhat.com, dwmw@amazon.co.uk, ying.huang@intel.com, hughd@google.com, joey.gouly@arm.com, corbet@lwn.net, wangkefeng.wang@huawei.com, Liam.Howlett@oracle.com, torvalds@linux-foundation.org, lstoakes@gmail.com, mawupeng1@huawei.com, linmiaohe@huawei.com, namit@vmware.com, peterx@redhat.com, peterz@infradead.org, ryan.roberts@arm.com, shr@devkernel.io, vbabka@suse.cz, xiujianfeng@huawei.com, yu.ma@intel.com, zhangpeng362@huawei.com, dave.hansen@intel.com, luto@kernel.org, linux-hardening@vger.kernel.org Subject: Re: [RFC PATCH v1 0/8] Introduce mseal() syscall Message-ID: References: <20231016143828.647848-1-jeffxu@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 47uzizqwbn8gfxwx7hzyawuqpaqqdsox X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 52B9FA0019 X-HE-Tag: 1697547385-899087 X-HE-Meta: U2FsdGVkX18uLdZprXA/HTD7cUQjF0XSJzu2stz1WkYRFZAHYCeli6ROyt51spA4B2ZaL7aVtpL/9eL+DFYKUdW1peUjLUNRBzuGADC4ML56x1StnmdaHCguIAmNGow7jRSQnNk8PR9Aj3uGReBC1at0tJ5z9yWMDOTJbFCmkTLV/JosWpqDwTp58/m+5SGejO186dKWlFkKUVUsaOjNTSVkixAql8F/1Zs3p5MFnFXt69vTZNtOxYQPnT4EnWSF4y2hvngnfdJQpJIZMtmcAMi3kwlRftyFo71lYf8e6q1X/p1ajWv56aDNxxRTAektQhMNPPTE6mkXtprkonbb6ftROkBS8UTc+Z397x1tutSUAYh7zGgGr28NJkoIlzbowpaMB87Z4slxgtVLMTk7NrKBzwb3bFej5c1gqh9ubqW9SlgKqgt1i+UbhPoI7HGPUlmQpdflQXewNUwzpltDJqIruZcoRqSenuTFginWmr2J9GItq9O43oIm3kH2NjzoKQznt2c5F8Q62DSLzdCUe/r5cEh4IaIStVFioeWGHt18rdAVMjPi4bF0AkGGYacjESVo2+U64MqWrUOzH+c641IHiTb0L9EVAFUh+rG246i2SLLKGHaqdEIaSs7VSt8LiRajEhaNtu8uDvF69tYX1snqOnC+pWoEaVl/btI7vWWR1BLGpftHBmYs1ZGz7jFhG96j0LDOkgBGc2lcfn3n6C1Ee3CyM1pI8Mer9QouDi9vEsG/8lkM3Jzsohc0KujG58MT4pXBtE5gou2RLmSmUw7HsPhpgghgLaEYJ7+W4twUf/mtr/092RNDKo7dMiQRoqYGbrlGoO7DUA+MAUQi3c3wWneRidvl6pb6YhdUO6OpqWhwj91jc7tNM0dT3h3lkblj74gpJMC3pk0UQQclPmsRLjq0aUJ9X+/5j5pa3KZqdHnCzWwsgME2/C1hbCO6kR0SLJp5Gs3TBvtPpn7 z6zJ5bNZ KU93cAEWuKOIOR6XsQOt1qEWMyB21CBDCpPvDPXUjvKApPiwlSDyy0HkgOb9BXFRHiiPzLlMqmQDY1k5jaOJoz23BuZaFhw9pp1dOXQwrOAYTS5Z/fgiozrvb118s2fdcGJWRRHi4BLKpDNY= 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: On Tue, Oct 17, 2023 at 01:34:35AM -0700, Jeff Xu wrote: > > > types: bit mask to specify which syscall to seal, currently they are: > > > MM_SEAL_MSEAL 0x1 > > > MM_SEAL_MPROTECT 0x2 > > > MM_SEAL_MUNMAP 0x4 > > > MM_SEAL_MMAP 0x8 > > > MM_SEAL_MREMAP 0x10 > > > > I don't understand why we want this level of granularity. The OpenBSD > > and XNU examples just say "This must be immutable*". For values of > > immutable that allow downgrading access (eg RW to RO or RX to RO), > > but not upgrading access (RW->RX, RO->*, RX->RW). > > > > > Each bit represents sealing for one specific syscall type, e.g. > > > MM_SEAL_MPROTECT will deny mprotect syscall. The consideration of bitmask > > > is that the API is extendable, i.e. when needed, the sealing can be > > > extended to madvise, mlock, etc. Backward compatibility is also easy. > > > > Honestly, it feels too flexible. Why not just two flags to mprotect() > > -- PROT_IMMUTABLE and PROT_DOWNGRADABLE. I can see a use for that -- > > maybe for some things we want to be able to downgrade and for other > > things, we don't. > > > Having a seal type per syscall type helps to add the feature incrementally. > Applications also know exactly what is sealed. You're trying to portray a disadvantage as an advantage, This is the seccomp disease, only worse because you're trying to deny individual syscalls instead of building up a list of permitted syscalls. If we introduce a new syscall tomorrow which can affect VMAs, we'll then make it the application's fault for not disabling that new syscall. That's terrible design! > I'm not against types such as IMMUTABLE and DOWNGRADEABLE, if we > can define what it seals precisely. As Jann pointed out, there have > other scenarios that potentially affect IMMUTABLE. Implementing all thoses > will take time. And if we missed a case, we could introduce backward > compatibility issues to the application. Bitmask will solve this nicely, i.e. > application will need to apply the newly added sealing type explicitly. It is your job to do this. You seem to have taken the attitude that you will give the Chrome team exactly what they asked for instead of trying to understand their requirements and give them what they need. And don't send a v2 before discussion of v1 has come to an end. It uselessly fragments the discussion.