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 2060AC4345F for ; Tue, 16 Apr 2024 15:18:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A66256B0092; Tue, 16 Apr 2024 11:18:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EF066B0093; Tue, 16 Apr 2024 11:18:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 868B96B0095; Tue, 16 Apr 2024 11:18:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 647756B0092 for ; Tue, 16 Apr 2024 11:18:38 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 28CD4C0A98 for ; Tue, 16 Apr 2024 15:18:38 +0000 (UTC) X-FDA: 82015751916.24.B0F347C Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by imf10.hostedemail.com (Postfix) with ESMTP id 12CFAC0022 for ; Tue, 16 Apr 2024 15:18:35 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=R0qjMtCt; spf=pass (imf10.hostedemail.com: domain of jannh@google.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713280716; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=P7xPJ4NgaRqZ7lnpDudSOzBFLojU78EScRSM6wvzvKk=; b=7cX91UmWdjHR99i0UrZdzU0kGn3gkuU8qSh1+XSf72/bDdgE4f+OY7zcaGlfLkQk+2cn/P 9apMwRHlbjs32cSji5n+xESDIyGdGFy3/64VuAky9hsl6POEk9w4B6dnrLv4vCTcUNdHdM LwLFnEx9htS7JVjfcaCO6BrGUgz8Ed8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=R0qjMtCt; spf=pass (imf10.hostedemail.com: domain of jannh@google.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713280716; a=rsa-sha256; cv=none; b=g45dBsGVr9NH33UIOaWP/sFzcjSnTeovSB11VWcRPnxDOAjEuxZ7lzjc0DuZ3mr/WNXgDA ofmzY3U08x3HEWj+DmTQy10SvXNmG+nk3JF4EpuHqFnXjw4NSMZeLJKm7F6OVXtpXKDg5D j2qrqEgQyfc3h3OSo3g1/RZRg+X3ytQ= Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-418820e6effso70795e9.0 for ; Tue, 16 Apr 2024 08:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1713280715; x=1713885515; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=P7xPJ4NgaRqZ7lnpDudSOzBFLojU78EScRSM6wvzvKk=; b=R0qjMtCtNbz6qTjdlc+uwmG+r6YTwB2qGeVg80H9r1eID1Wb3HCkev1j98bqmlSC1U EqimsZJZndGJX1vj16AjdnwrEjwWoySgvjLSGUXGTcb1TTIjGXkN/VKcZmwNHGN7Un9p jHbh9MRhO24Lj3ar3oayE6o/S3tatUXguU3qoa+U3zPmVCx4JYb87xtuH4E/yiKYAeLD ZI/voMj6beli72zDy8Jx0cKwf+cvq/J86JIMuckk/5bGvcOKDohyqxdqGCFGVYj0GhA1 o01gfsQk7astOJw9k6v9E7zaGZphM9MfxtufKdMHDTWMVR1vgJgo30DlGraL+uO//Loa +uag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713280715; x=1713885515; h=content-transfer-encoding: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=P7xPJ4NgaRqZ7lnpDudSOzBFLojU78EScRSM6wvzvKk=; b=L5d8pUEMEpVWHDZ0CfMbm4R9ddwFyhrlVj3EkaVSJTUvhPdw7HgkLcH9KkoEMfLZxo rWoXGyimp/MXwVp2ectdel7YzN3Fzg1QW6xVwIQK3t/cm0YT1zy3EjIiU3tPDG3y1VID Zgu9n4mwEhqE5xtfEhtrDcVQ/f350HzAeuZ9MxwB0X11Tg/4s8YaCIJaj0VllwwKeL5w 19HxLMm6hPY3tz7GQ5xxxYeIvz4Uof5rc4uScGXQPZag0G4kQqgHBSG5m+ud0BkdWBWM l7rN5+00gjlZLDaQiEcUp2b6IiYsEngF0g/s8iexP9HEt7Y5fsvUZa9TYQegycaE7dBx xrJg== X-Forwarded-Encrypted: i=1; AJvYcCUkyB0V6E73NpGCaubtp9I+2xrTameXCzD94PEGpluOvpAAoS+o24XkFybIHSe5KbQbGQ/WE0tsHHr48vEtenHYcH4= X-Gm-Message-State: AOJu0Yy7qsz44icvJE4ZU2zMtYP8MCMgeZ1CA41CRvp5AjWIBhwnFwMc fyfnwgvliiQjL2wKu2Nv6jERPvvoeyJPwXeFSj1e0aTZz23WbaEe5raIIDi478JAvrgrogJf8jf jdVgweQTttFXvqb3sDOsCffUN70Jqpy4VPK1P X-Google-Smtp-Source: AGHT+IEeH9C9bC1RaxsNelMnFwqD5KOxfvmXYJRoKyxe3Q7CaWZjnpYXhJ/saHUxjHvV1zQnpGdajAJ/hjr7wymfVm8= X-Received: by 2002:a05:600c:1c8f:b0:416:bc07:a3c9 with SMTP id k15-20020a05600c1c8f00b00416bc07a3c9mr210315wms.6.1713280714469; Tue, 16 Apr 2024 08:18:34 -0700 (PDT) MIME-Version: 1.0 References: <20240415163527.626541-1-jeffxu@chromium.org> <20240415163527.626541-3-jeffxu@chromium.org> In-Reply-To: From: Jann Horn Date: Tue, 16 Apr 2024 17:17:56 +0200 Message-ID: Subject: Re: [PATCH v10 2/5] mseal: add mseal syscall 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, deraadt@openbsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: i3cys59619meh1crqassgbmssj3e8nrg X-Rspamd-Queue-Id: 12CFAC0022 X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1713280715-612383 X-HE-Meta: U2FsdGVkX1/bd4HN6+yTny7e3XFTeAMBFfrPVXVj5Qam9IO4k7YqsMFnLlKE1YxbsD9JYgtGIDve6kqXX/Jl0jCObUYTg6bRhsK+I5jHuKZPMvAnm1gusdBY9FhADt013y3CxI5nsN5vFSKV+AjL2V6VRi8QhrvR1AlxogteZB+2r2otimp9oAsBn01jnlmsALJXryU+p64DuH1saogyw9T5u07Gd1FwDjgWxzo3KM8Qr7dGW47iJrnGYoL0JPJI7hh8q5mBoJyq4tXJ9Pa1YvpHJB6quFmnNlW19ZSW2/CE2vu8ksql5AX7z+ZWBJ4wfjIJ2CBZu4lQN9LXBBbX66osqjMjUi0uIgSjIySE+x2o3jP8pKUtFk6sd6cVqg3lyBRZFcRf/a69MXbsnI5uzOaHtVTr8zEHRht2kXjNhm8loBrGrGCxEETvtdc2wSyz4sjplDF3yjW57lDtmnOEBsj9whDoXTr/0j1CS0pLfbFQLV6JGSFUUXw5Zj3XSo1BokMfKvaUGR5g7w9wSRvrRGikUFN9dfJZ5jyQXN6hh2HAUKNsY80DfIzdjLXr5iqBfRvyTcf0yYlCJhLyY4cJz0rDZYPx/Sh3zIgLfD1LdNQF+vg1xXyMHy6ldWfKRnGy/yj96PrQPcbQ6R9STUo/pod2Bo1bnVhUNtjALFCZxdxXZnU/ClbKeJOrHe7WAGcBgDup1IbhMkdJelTsmCF45uhWH74DGi4xN0pnetm92aIP1l8Su8VD8h37BbsuLzvw+ThHFetLg8q79PBq+krllBRX0pCKETU3/t/6HlqCD5L2NeWBF0kkPata8tBF2tcnY9lh/LRBJV/U3sw1UyUGoCsRSDW09UdmXdLnYMsTDQnw0Mt5cYE4Uxn8t+vVbv0nO0Tk2ld0t3OEpT+LbIIpTonwXOk8elQfrEmc2a427U9J58w4Wc8O1RmQ0LsW5lEiElyGG8cESE+TU4Dktt1 pwa412Av LjejmuQIuAT2XNmchUo+3Ttbo7ugnl8gLK2CoqHlZ9lewOVEPig6nZ7nWvE1WapZsVdUesSi4xvcZ1PP8IdrH0x76yj7e2y85Oby08FmurHzY4I1HyB7Dh6CnYFyQ+2w4PUeG8JFTqlSKblQHlmiRj5p7YpN2m+VX5GSNs7pP/qg6rZSRzvChpcTDITS4rDlZi06so4Sh1/0ibCUjSBXf9GarZPlIDfuf7Hkt2C9Ffot9OUfarYuRY/va1tt8Euga+pYwJGrVHOb2qd26HHr61UmJoI87l7xehs0BNdgUC2wAvLCHZdT7fwMUK9/9STXMwEuHMcnQk9KjBunx9EbU5PZxEOzgL11O4uxB/vq2mckKfxWw6i08LfLDzmqpaUaOnwmG X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 Tue, Apr 16, 2024 at 4:59=E2=80=AFPM Liam R. Howlett wrote: > * jeffxu@chromium.org [240415 12:35]: > > From: Jeff Xu > > > > 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.