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 AA349C77B75 for ; Tue, 16 May 2023 23:37:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A413900004; Tue, 16 May 2023 19:37:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 154CD900003; Tue, 16 May 2023 19:37:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04371900004; Tue, 16 May 2023 19:37:31 -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 EA8EA900003 for ; Tue, 16 May 2023 19:37:30 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B8A27ADCDB for ; Tue, 16 May 2023 23:37:30 +0000 (UTC) X-FDA: 80797732260.03.B2DF4CB Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf09.hostedemail.com (Postfix) with ESMTP id D4E62140006 for ; Tue, 16 May 2023 23:37:28 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=sfoNUTG7; spf=pass (imf09.hostedemail.com: domain of jeffxu@google.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=jeffxu@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=1684280249; 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=B3cyjPKDEETW9BoaEFZPFlkSTqObLADNtxINVLQqYFs=; b=KkMqnePm2VXM8fFjEWmyyrNYzFKUrkNasNS4JhjLF9isqpv8oSYvEIhth1wj2FUuGNoYlP X0fPttzWMlxg2bSucuRwcQeAQR8aELWWPhfoL94ddGfHs/Rh+WFdalfVI/dZAyfpgehYis vTm9j4MJe5YS1qtO3IRw3X9lbj49n7s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684280249; a=rsa-sha256; cv=none; b=BtS8fPLuqnxivWlvB8YKzdc9clcGdCnjz+4XNSjkgTxfPZTlN97PEOmvvPzWjHgyIYIpY5 OSjrMC0+ocj6IxsEMHvORfVFX4NjKB8vuS7EjQn4z9Ipcnn/rOffigPbNkCN7BsWyM6UCQ owth3QC8j90VcTVIvII8bC1Afddf8AY= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=sfoNUTG7; spf=pass (imf09.hostedemail.com: domain of jeffxu@google.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-4f37884956bso171e87.1 for ; Tue, 16 May 2023 16:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684280247; x=1686872247; 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=B3cyjPKDEETW9BoaEFZPFlkSTqObLADNtxINVLQqYFs=; b=sfoNUTG7NcUMYKrPlQ6h6W5SKsRa0vmOp8q/513w0aQHfwXABSOgbZ/0flBuGDfj1h N6X0KheevQYPN0GIY/kVb74OJEB9MhsqjFzR1HjeFUF8lKQ8fRjyhRdm4EAw/rt6KhJt 0nKP/X2QE8K9G32zFaoehnKHKpleay3BM12Cu1DJ1HYyME1n30CAeCM02jHQ4nioAqtF 7foP51GbGpZTbmLKY6Ig5epxmVaYWZ8Pc7OaO9ijoBYYTflGQYlc/GFXyyCWQD23y36I xzJplVx0SmcEawjdUrvg2dZjkIVX6jf11/dM8AlTUeuUdwTSud4ElguaP6EPbJmKHi6v QYtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684280247; x=1686872247; 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=B3cyjPKDEETW9BoaEFZPFlkSTqObLADNtxINVLQqYFs=; b=WIR/yTzcuHO277RdqlF+DqMCPtvPqJ/JifPoBaQOqQ2gkBSRLBH/s+yNTfFV1kFBfR gqN94SM1H6LB/snQaYeUDJzk8hspUXgu/qqwxvvCCE2icu47V8me/ALH06pndfG4gZzY 0v8Klfr1NLfdJjjtLF2D5+RJ8ouEOJkPTDxTUY8T9PAAmPTYIP3xf0eqgCByreVMkxU8 HIib7VblqcXbGx8i3FOKWWHdpCNXlyIyD7rgOeCLMDqRftKr2CzDGaSbT8nsMEghKwOB st6LGiI+xHaZd6gNBiCq5MLDficfELw9C+dR7cT+6XEZjpnLpGl8ti3blceHUkZIt5vl ykPg== X-Gm-Message-State: AC+VfDyNiK7CO/NSjeJZMTQaCGo9FJAvCAgChs/YxBmtstBE7DwAEMl9 c0FF5Qavl/FHrixSKkj43vcEOFKb0VsNl97ZcbVFIQ== X-Google-Smtp-Source: ACHHUZ7cpmyJObyaViqWzpJRKdk7zMSWg9lLD6ZsxBPhJhsDoJ5qssn7At+CRnjxlB6QS91sb2qEM3QcHU971ozzjBE= X-Received: by 2002:ac2:4ed8:0:b0:4e8:3f1e:de43 with SMTP id p24-20020ac24ed8000000b004e83f1ede43mr25525lfr.7.1684280246758; Tue, 16 May 2023 16:37:26 -0700 (PDT) MIME-Version: 1.0 References: <20230515130553.2311248-1-jeffxu@chromium.org> <20230515130553.2311248-4-jeffxu@chromium.org> <78bb0097-7dca-254f-45a6-5cea6baec0c4@intel.com> In-Reply-To: <78bb0097-7dca-254f-45a6-5cea6baec0c4@intel.com> From: Jeff Xu Date: Tue, 16 May 2023 16:36:49 -0700 Message-ID: Subject: Re: [PATCH 3/6] PKEY: Apply PKEY_ENFORCE_API to mprotect To: Dave Hansen Cc: jeffxu@chromium.org, luto@kernel.org, jorgelo@chromium.org, keescook@chromium.org, groeck@chromium.org, jannh@google.com, sroettger@google.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: D4E62140006 X-Stat-Signature: h4dzrjtc8aeopqpbnozusiwstqh8tw9o X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1684280248-390300 X-HE-Meta: U2FsdGVkX196iPQWjHeDZhXY7KfhiDp6EMcDbe7fTnoU7rZw7Sah9rJh/F1ZgH0YYemKj8xBtgr1FdHi0wMmTYrfcUsQ+E1vUtPLTnip6+32bteTPUtNdaoS88Ig6e+M7qnBq35qlf+feoD/zUIJHfb8A7xhsuc9/Ony3V2KVC5AOXet/g4SI5aUzXkc3w3ATfGiC5jIx5xu11z9UMVtzu0uRhL+xuHxF6lGDzmS4YSaOtCe4Egv1ME3Kg4/iH3NnZ6rK+5lp8ruq+YkGEGfPU+ANxmDxkEmy3NWxXmIWZFdIeYMJZ4MFl/hnoprmijtjc6FH9cRhR8ds/2H1w5rmH57CFvcem1Ucckin/4g0KEx9kBilDfISuz7bW4wcN92IMCx5trpUNwtPrCtZocP3BbweNnlhEJPLKsQGOyk/ZIxXL6lmoefcb+msGJQ45K6pNXyBkWl8GPiVn80IJMc002Nq02MPq4ajDlzWjHGn/YOg2SPer2uaHqCP/tBiVinIFdHOnsKiFmJ+a1O62X8X6kO1cJKnwvAjyrp54skZzRMbRXndSMPbQdNV47nmZ0tqGH9HwRe8ReKWypoZvAP3cBM38WjlcokIP5LKRpMb3NoLShg31fBWkn4uM2cqgFFwLPTxGRHYnu19E3t1mC5qLHihj+mU3x3657uiISNRZRcg78wystZgWbhBkpPty75oFQFLiq5JMXCfduNmqUhGWIIBWjLa+zQoNL6uos+dlFDHLS31yeoT6B+3oO7FBDJ0Z9sk8cphArm8nwxqXDEdGb4N/a4bl1OlhUZZ770/LKIS2KS9dDKKOztCdoqpXI25Ohva1VQ+qkfVaNX40gAxPQHmjrkJV6ac2564EASOV3fFiZDT8fU7QpoeoMYvtQ6u6Ll1KmlyY1YlecfKsZZBv1iVCu7Ix3ymTb6myT1uTq4cgGGJG+KNVbE8YeE6WKVNTTNE9cyXnPP0kAkmcX F/dG9AIQ qpS9Rh46R6W3qRnuMxRQnA/gNGPZueG1E+2l2CTaaD7nuHMfLNi0uiY9wT6BApc+4d05uS2gYgEJy2Ri7Y4S7BMlnZOtoK+yqOwtZ284DBfL6AEQ0TGcQGdGLKlRPmPrdngJDaotNoU28mc44e2sadGlRGyVbU2FDDKnQVJgiU0uFm6cqTtRsH/bSSzeCRNfrZucp9ER6gLAkiHjs6MPBVCVxa5HHNMkDD9vUJ8xepQ9j3KQA0aynrpx0kbpDeP5bcddCmBQeSu6B3C4aW/XPjXTX6EWsGMc2da0gT7rn/yU6MnZHPqjptSDEctUoNapwwEN20o31eUSul5RtVJWZ7oWu8pY3KB4WkOnY X-Bogosity: Ham, tests=bogofilter, spamicity=0.000041, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, May 16, 2023 at 4:19=E2=80=AFPM Dave Hansen = wrote: > > On 5/15/23 06:05, jeffxu@chromium.org wrote: > > /* > > * pkey=3D=3D-1 when doing a legacy mprotect() > > + * syscall=3D=3Dtrue if this is called by syscall from userspace. > > + * Note: this is always true for now, added as a reminder in case that > > + * do_mprotect_pkey is called directly by kernel in the future. > > + * Also it is consistent with __do_munmap(). > > */ > > static int do_mprotect_pkey(unsigned long start, size_t len, > > - unsigned long prot, int pkey) > > + unsigned long prot, int pkey, bool syscall) > > { > > The 'syscall' seems kinda silly (and a bit confusing). It's easy to > check if the caller is a kthread or has a current->mm=3D=3DNULL. If you > *really* want a warning, I'd check for those rather than plumb a > apparently unused argument in here. > > BTW, this warning is one of those things that will probably cause some > amount of angst. I'd move it to the end of the series or just axe it > completely. Agreed. syscall is not a good name here. The intention is to check this at the system call entry point For example, munmap can get called inside mremap(), but by that time mremap() should already check that all the memory is writeable. I will remove "syscall" from do_mprotect_pkey signature, it seems it caused more confusion than helpful. I will keep the comments/note in place to rem= ind future developer.