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 2A539C4345F for ; Tue, 16 Apr 2024 16:42:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CE766B008C; Tue, 16 Apr 2024 12:42:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87E896B0093; Tue, 16 Apr 2024 12:42:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 745C76B0096; Tue, 16 Apr 2024 12:42:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4F04E6B008C for ; Tue, 16 Apr 2024 12:42:34 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F31E8140794 for ; Tue, 16 Apr 2024 16:42:33 +0000 (UTC) X-FDA: 82015963386.20.77BFFDA Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf02.hostedemail.com (Postfix) with ESMTP id 1101780009 for ; Tue, 16 Apr 2024 16:42:31 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=OZgRk9jl; spf=pass (imf02.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713285752; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PsbOK7NqlD2eJxMmhAgdQY9VBEXxyqleO+55ToWP6iE=; b=j3gV0/hnfXtaG5VtyeNbHEU4Qc1ImQOOS3QpeJ7R7kl+sl+Bu14GWG72PNVJ3Eh0IDydD1 uL15Pk+GVHQkaFUQtIPlb+Y7ZNgbSdCo24mCA+vMohl/hpQ1JRrHmpJ41XmJRXiuqBPP6g GAd7rVoxhpzIMROpzmUGIXtl2e/SVmI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=OZgRk9jl; spf=pass (imf02.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713285752; a=rsa-sha256; cv=none; b=GAzgAcsX7RpDkkueK5DXdh2RyqtHLYGQfgr0Cs66kDO1O5CY2AmUtx1xwFw8twRKrbfTsx 0jpx/kZJ7dcerk7m64n9x0cqUbMsZDf/r2u62pqCvjAqJ/axp9TSGDwRcnu/XT4Iorn/N1 f9kq3rIMHnB4Ot+voxpU7L3HxsOY300= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=pU0D7p6Mrs m9UDb/aQ2TM6OzvMKuAB+Zxp5mgw2XPKU=; h=date:references:in-reply-to: subject:to:from; d=openbsd.org; b=OZgRk9jlk6HVVL1liuGCuPFJ2Wd/cE3AWIUi 1dKj9S2eim+/p7/MEBIVLGnjDzmNcJk3SrhXvjCzQOoINFz8z7XieiAjr7JwyKSuds0gRv NLx/0obXLezhwQ2dW1pjWUTMqgg6JizhtP8r3Bs2z0l9RBpLPrDGSyIZOazHXibDrD+N9l 9fK2g1F/yNU0kgZlVOaVwSQQ34BqYf47mc8L5V/+WvP3gcDClX9TOPTHv1YJYT2Rz5jwKq 2gmFwm9bqhkpm5QOvXdLUqnW2kw5jlFLScyDbCrEEIg8iPV/YNBuYKastWGrKwTp1eC3Vn +qPMY7t2TzUNv+PW0NBHj/bTAw== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id a4496a3c; Tue, 16 Apr 2024 10:42:30 -0600 (MDT) From: "Theo de Raadt" To: "Liam R. Howlett" , akpm@linux-foundation.org, torvalds@linux-foundation.org, jeffxu@chromium.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, usama.anjum@collabora.com, corbet@lwn.net, surenb@google.com, merimus@google.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 Mail-Followup-To: "Liam R. Howlett" , akpm@linux-foundation.org, torvalds@linux-foundation.org, jeffxu@chromium.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, usama.anjum@collabora.com, corbet@lwn.net, surenb@google.com, merimus@google.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 Subject: Re: [PATCH v10 2/5] mseal: add mseal syscall In-reply-to: References: <20240415163527.626541-1-jeffxu@chromium.org> <20240415163527.626541-3-jeffxu@chromium.org> Comments: In-reply-to "Liam R. Howlett" message dated "Tue, 16 Apr 2024 10:59:34 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <43378.1713285750.1@cvs.openbsd.org> Date: Tue, 16 Apr 2024 10:42:30 -0600 Message-ID: <58783.1713285750@cvs.openbsd.org> X-Rspamd-Queue-Id: 1101780009 X-Stat-Signature: b4hcrzi5bostd611fp1wpgaj87edq9xz X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1713285751-188556 X-HE-Meta: U2FsdGVkX1+aw/6/O7zvNiwWvDyjPwK6u8vUoEYjmIBcVQU6uomKUtHx8tQAOGH5cuTEbpdR64BljCk7VsWWSKFjacvpPuU90MAmoyjDcvMx8wSZtUVL752t7kHCIVp+4sMfMCRgb04oO6EH0bB3NhNpfcw+z9xxPTD18Sp4BxDS3iZENsd2CdspTB+5jRj7zlgdGbvblOKJxxQKOfZlQwN9vV9BEgUY9rK5c5447b8HCLvJrzP8m+pN/61b3RQAka8cSKVGj04GGyNrCYKydv9E8+MqJ0no6pTiNqStNihJt0sYRZLZOjqe6CqdYo3KciKAmD3Vo30B6isI18jvgtZAXWbgpgipJg5LZPLhXGoFfp9W0jnnqsJJYrBvSejlb/9L6sDTxcXBv8TyJY1BfSge9oQ2qbKGrBJUV8tmSuUDxl35ebEbOZczaEJJDJYEh/nWaFa776TSRXlCBw5bBAml6DKkLPJ2aJOOsSPNlGx5bhbkxjMQpjhYhC7UbXJt5TTcHLyEW6PJZULkeF7VD3t/SYPT3DBx3RFuYK9ah+KHIme/xn5ZvRJ7rmiuYYM2lK1DsgL9UtgqGPvPKQRdNZ9ijrP9QvtQ2vZ0TAJLE+PG6WdCMZmNbdiKLmjU2kp+BfSbYw3/7k/aJ2O8uphoyvWfFs05zQGRHvuOTpP6OO9y5AYEq5QkUM3glXzWxpi54S54Hiu4+fFNW/gl9szc6fwdi33JFUuv0NZ9fY6YJnVwZshydCaTUQafQCyWRKHwpRtW+tB4oTe8eU6oiSDzfTVm5nSDbQhlUAtbNh0buRBsOkICmtmm8eO0MHocpHA6+oqS4gVi9CN22Apu/czuff5V/lGzytIsUKHXFcdfYseWLae7ruvggOmPSMwE3Iws6a/7oLTdCAgpYiSjFkX3+9GE0+A03AV1dS8eSyF8XwCEK/ymgsJSj0ZkhWQshayETssMgSNPvIELbbv/Wrk Mi95oiSz k09kvJ2NVOSYoXr3tcUsSfUwNYHMl4YKzfFYUqhNJxSeJiF73JgjBXhFHRpPy/naTp0YtXs0JBnoZKQRP5VCEGo4vg8glN8omFEbbKXkkS0JQ9efMGMQv6tH5ZbdzE/+RmKtLgW2DGTfFiq/NWJw5clBMcykPxFv85Y4Rksq4AHNb0XsV5ANUtUNXvlNJH+r5C+DuyjbBOmX5FWrdaWOmsOi/+J7l2YrGB4p9byGuY2mMdgk= 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: Liam R. Howlett wrote: > 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 discussed this with Liam and Jeff a while ago (seperate conversations). A bunch of linux m*() syscalls have weaker atomicity gaurantees than the other systems I looked into. Linux is an outlier here. Other systems do two passes over the "entries in the range", before commiting to success or failure. When success is returned, it means the whole range has been changed. When an error is identified in the first pass, then no changes are applied, and error is returned. I found no partial results in my limited reading of various VM systems. Actually the gaurantee of having done nothing upon error, is very common system call behaviour. POSIX and defacto standards don't seem to specify by specific wording as far as I can see, but majority of systems seem to do so because it matches expectations. Considering all the system calls, I can't think of any examples. There are a few specific ioctl which were designed wrong. I suspect, for performance reasons, there will be little appetite to repair the m*() syscalls in Linux. (I would appreciate if they were brought up to standard, so I guess that starts the 20 year counter :) > I think we can all agree that having some up-front and some later > without any reason will lead to a higher probability of things getting > missed. Also as attack surface. I spent some time thinking about circumstances where this might help an attack. The risk is that mprotect() return value is very rarely checked, yet parts of objects will change. mprotect() is probably the least checked system call, since people assume it will always succeed entirely; not the case on Linux. Even more so not the case once immutable memory ranges come into play, it's an even more likely error condition now. I didn't find a particular piece of software (or an old attack) which would help an attack with the sloppy permission handling aspects, but I only thought about it for a couple days... there are people with more time on their hands.