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 64B62CCF9E4 for ; Wed, 25 Sep 2024 15:25:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8444B6B00AC; Wed, 25 Sep 2024 11:25:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CC936B00B0; Wed, 25 Sep 2024 11:25:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6459C6B00B2; Wed, 25 Sep 2024 11:25:33 -0400 (EDT) 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 3D45C6B00AC for ; Wed, 25 Sep 2024 11:25:33 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 91259A0493 for ; Wed, 25 Sep 2024 15:25:32 +0000 (UTC) X-FDA: 82603634904.27.4DA7B74 Received: from smtp-fw-80007.amazon.com (smtp-fw-80007.amazon.com [99.78.197.218]) by imf20.hostedemail.com (Postfix) with ESMTP id 44F8A1C0003 for ; Wed, 25 Sep 2024 15:25:30 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=amazon.de header.s=amazon201209 header.b="K/Wk1KAC"; spf=pass (imf20.hostedemail.com: domain of "prvs=99141730e=faresx@amazon.de" designates 99.78.197.218 as permitted sender) smtp.mailfrom="prvs=99141730e=faresx@amazon.de"; dmarc=pass (policy=quarantine) header.from=amazon.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727277811; 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=As6Tj8wcJOBT4bSyBpmyxkEQ1WVmrxVnT+g27ZYlr1k=; b=66C6jU4zkWnQtXPx+At31PQXrssTX5nPaMSAwLPn+puyTjstbZlWUxB8dSnn47pKkEU44o CFUtGYYpV0IN834qTvFocmvdjdT1RpPFOJG2t6UPaOA3Kz1EiJt+kyJC3hqHcz+rQd8lYj o07ikBrn+T6qpSlV7XkssnWfM558sr0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727277811; a=rsa-sha256; cv=none; b=pKCk25vTtbc6Io8XZfazVvA3/3+zDIaAz9qRiZcRczx3cuq1dKv28qxzWoVY1NW8s8Z691 4X8coe0AJLID4surKjKBatFMwZIXFBTxdfwmNfglTw8DfB4ZqAoJ8ElsjsAtyolcWErJ8h 5lWwv1bbqp7G/xxjQlfo1hy6+u8DvLg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=amazon.de header.s=amazon201209 header.b="K/Wk1KAC"; spf=pass (imf20.hostedemail.com: domain of "prvs=99141730e=faresx@amazon.de" designates 99.78.197.218 as permitted sender) smtp.mailfrom="prvs=99141730e=faresx@amazon.de"; dmarc=pass (policy=quarantine) header.from=amazon.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1727277930; x=1758813930; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=As6Tj8wcJOBT4bSyBpmyxkEQ1WVmrxVnT+g27ZYlr1k=; b=K/Wk1KACYn3QlYX6pmSA5B30EcgPDKpx+Lb3Xvm1tRmghOB8wnockvGr OcbfwnDX3fFbjYs2LfmHaghKwM5/C4ST+cGfJq8fdT3DlZ73i88+oMwsW adEEQPLoz71DbDj3vjYr3fOCT9sNZjKAW+vOSxMVEAqmP2fwkArxVU63f U=; X-IronPort-AV: E=Sophos;i="6.10,257,1719878400"; d="scan'208";a="335003636" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO smtpout.prod.us-east-1.prod.farcaster.email.amazon.dev) ([10.25.36.210]) by smtp-border-fw-80007.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Sep 2024 15:25:24 +0000 Received: from EX19MTAEUC001.ant.amazon.com [10.0.43.254:31774] by smtpin.naws.eu-west-1.prod.farcaster.email.amazon.dev [10.0.17.12:2525] with esmtp (Farcaster) id de8fdb25-e828-423b-86df-630a32d02633; Wed, 25 Sep 2024 15:25:24 +0000 (UTC) X-Farcaster-Flow-ID: de8fdb25-e828-423b-86df-630a32d02633 Received: from EX19D007EUA002.ant.amazon.com (10.252.50.68) by EX19MTAEUC001.ant.amazon.com (10.252.51.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Wed, 25 Sep 2024 15:25:23 +0000 Received: from EX19MTAUWC002.ant.amazon.com (10.250.64.143) by EX19D007EUA002.ant.amazon.com (10.252.50.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.35; Wed, 25 Sep 2024 15:25:22 +0000 Received: from email-imr-corp-prod-pdx-1box-2b-8c2c6aed.us-west-2.amazon.com (10.25.36.210) by mail-relay.amazon.com (10.250.64.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34 via Frontend Transport; Wed, 25 Sep 2024 15:25:22 +0000 Received: from dev-dsk-faresx-1b-27755bf1.eu-west-1.amazon.com (dev-dsk-faresx-1b-27755bf1.eu-west-1.amazon.com [10.253.79.181]) by email-imr-corp-prod-pdx-1box-2b-8c2c6aed.us-west-2.amazon.com (Postfix) with ESMTPS id 662B9A06E7; Wed, 25 Sep 2024 15:25:18 +0000 (UTC) From: Fares Mehanna To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH 1/7] mseal: expose interface to seal / unseal user memory ranges Date: Wed, 25 Sep 2024 15:25:09 +0000 Message-ID: <20240925152509.87152-1-faresx@amazon.de> X-Mailer: git-send-email 2.40.1 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 44F8A1C0003 X-Stat-Signature: 35781d8cejf1qakxagnexxksawadx5e8 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727277930-379239 X-HE-Meta: U2FsdGVkX1/3Rt0YtoC14KMeBWBe5hwJB2gLnR6feUF+JqtoxBZsitzMsxj7EYeMCFE5toO0MbvCL7v1aAvdHtBMZ5aEZIc9Il0G9IVGlCNeoRh3PA5a+mqp/dWzHk5he6Gc/rvQEXAisx7VdpMlfoJh3smcZSxf6WOUm846L9IyWPAihJItmOyYjlC6wfjAgfERkH9KGMGYnwNzQNitmWzxn7iMHrJDfyuYvQdaD08DdaA7mvWVqqRk6pR+3B1PJZN4Rm3BNxc2eANRYNptGt6uplBDTvaUQKNI7SA8jMK9CYQG7ylRWaVdnYzI2ibAISyhfFcBoEx7bydpQjJaMysRHCOrfRjRKvfL8IcVrOd5DOcNlhX1+vT/SfRSiuYT79fekO9Ysmid+8+gwQo3hzVTzT+up9A4yoy5jEj/By7cxE6ANrEFOu0OHlFO/iHmf1XEq1F5yq+DcJN1kdVgCIUiTzaXYm9ETvcOGanIpPzT64WPkNMOp1fA2sbLS+Jbpkvbzb4QNjdtqPX9Pjqu5xzOJUTE+jMU0E0Or20gRG35ua1X2v+fdwGLnhL/2u0F0i5wO2XO6KYYV4KcTPaplBzyZ35SuyJZPeg8GnGZDC77zOZtIn/GI63ALpzcV1Y/C3wcGCsTTT7PKOLI8n7ZvWMMTkUSVJf8tQHwynkXMFHnY1KRoem4GJR7VKlJqtV0zmmv2VjqipaFtaDG/ZCsGvkTUgRAQxGQPQQRNibhGOJn8mwbwQPoKEj64Gys12IaSuP8qkPQKbzE154cuHIeWgcZ3CJ6zsN3/XIXCim4GUi4iHMZSsLAOidAbTh9GS7/7A9qWfghHQc58TctJC6irwFdFekArmkzQszJB8YU0HqhYsq0ZuI0/q1Fh6R5NxZr6/HY4LZ6XEPvwGFRpU6Nk8dsXeIA9an0Y9YhlBUAIyMTb3/NeO5tkJkWDp0zVnRHoHqpBcBrFujjHn9IdYl VUsc5I4d UmcNpyaTFciTPOP2gO+A56dKFqGH8q5qrk4RxGa/kenDLmKR5uV2AmNUITL3geDijqHjSXwudqUkNQDGqEdC8I4q9hIXE3LV4U2MBLxqxDeEaRTd+bH/YTCmaN/+hcr5ikxuBiWbQjjsYtHuYfwzKtCxKxXNBwxVfc1t7D0CEVmsC88mja/Xi79k1lXIJ5oyBAPQXAunbX+qqKwygAUzdl3NWlrAzKA0Lx5zZ8gT0R0l18STipLwAmun5csT5d2kit5c4HJTRruB5NCrbIgPsT+dxpfaNo/kAgRJDCo5faiqm1Of00qP4PszCRVLu8vUQ6iH1CfTuOp6lL7Y82Cx0tvji8fibFDgAgi0GObpo256HSaZDw+gVTmaErKr2dnADGxmlUDdcW8fOR8dVK41rBpPwk34l276kYpcJManka8mwvQA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000204, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, Thanks for taking a look and apologies for my delayed response. > It is not clear from the change log above or the cover letter as to why > you need to go this route instead of using the mmap lock. In the current form of the patches I use memfd_secret() to allocate the pages and remove them from kernel linear address. [1] This allocate pages, map them in user virtual addresses and track them in a VMA. Before flipping the permissions on those pages to be used by the kernel, I need to make sure that those virtual addresses and this VMA is off-limits to the owning process. memfd_secret() pages are locked by default, so they won't swap out. I need to seal the VMA to make sure the owner process can't unmap/remap/... or change the protection of this VMA. So before changing the permissions on the secret pages, I make sure the pages are faulted in, locked and sealed. So userspace can't influence this mapping. > We can't use the mseal feature for this; it is supposed to be a one way > transition. For this approach, I need the unseal operation when releasing the memory range. The kernel can be done with the secret pages in one of two scenarios: 1. During lifecycle of the process. 2. When the process terminates. For the first case, I need to unmap the VMA so it can be reused by the owning process later, so I need the unseal operation. For the second case however we don't need that since the process mm is already destructed or just about to be destructed anyway, regardless of sealed/unsealed VMAs. [1] I didn't expose the unseal operation to userspace. [1] https://lore.kernel.org/linux-arm-kernel/20240911143421.85612-3-faresx@amazon.de/ Thanks! Fares. Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597