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 5B0D9C71136 for ; Thu, 12 Jun 2025 09:45:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D365C6B007B; Thu, 12 Jun 2025 05:45:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D0E066B0088; Thu, 12 Jun 2025 05:45:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C24376B0089; Thu, 12 Jun 2025 05:45:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A23DA6B007B for ; Thu, 12 Jun 2025 05:45:45 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1DD5EC09B7 for ; Thu, 12 Jun 2025 09:45:45 +0000 (UTC) X-FDA: 83546266650.26.FE86B83 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf25.hostedemail.com (Postfix) with ESMTP id 736F2A0003 for ; Thu, 12 Jun 2025 09:45:43 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fKF38VES; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf25.hostedemail.com: domain of alx@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=alx@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749721543; 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=y5lX3aMSmVDmH6QiWLefVLianv3E3nUGmh/3sBMl5ZQ=; b=EyiwOd8cpCSw84rgGSHRFzA2mItijJRH9W0KK+TKS3eiLP5wI4n9X55Z2AZKjmY23H8Rh2 md6rn7mX5QkMiThlSZDfjoK3MVARHITTUMUoGn1UABfeeYIx/e6Q+vXrsNtj1nB3SDcAQ8 vGWFExaqPopAHqE4Ituh5DduV8k4IZ4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749721543; a=rsa-sha256; cv=none; b=U2zyuJ/sM84oNEbH5PkIFo/kV/hply7SB0gjs6Pe8QFbCK/QCUWVvIC988SoeLjjCiApvL XVjoLmo1ZcGBYXl37GeT5H8Oa+khgt1ETJ60poShpHxzhG3bceN5gJ+jrKjs5tFE+Gnc68 wLpMYjCeHnPy8g+ff3MAEaW4v7m6xH4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fKF38VES; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf25.hostedemail.com: domain of alx@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=alx@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id C1BBE6113A; Thu, 12 Jun 2025 09:45:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68BA1C4CEEA; Thu, 12 Jun 2025 09:45:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749721542; bh=ISSwJzQtcPMgDfooxcBBf4ZtPTrjUOw20WkC/jwELYQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fKF38VESGU0+8srBj0ZYtbybtVz02QgkU6rGWBDVTttfuUomHrfnmOnKaTPAgzNYR F4NDpGJbh/3Eb/WAcglsv8Djp6SsxK6KsZOQwcU3NRNgHLCzBC8UITwlDv7DuG2hcS F6aAbN67DuvdaZvcJNXc4kxeLDCg/AHp0F+QSvln0BYS8rNlwFVvBe66a5jFUdhVME 4DqKwlU2gVoaqH3ZNbkqfyrNdvMMQlAQllO0K4ecW2WJEx9UBnDfysifySWavQbCg2 6td9aQcZyyZeqv8Bv89ErSbUccAf/ogOZlDl+gZqggQ9vdO5cmS+i26nprxdNyR43M acYHWxinUo7og== Date: Thu, 12 Jun 2025 11:45:36 +0200 From: Alejandro Colomar To: Zhengyi Fu Cc: linux-man@vger.kernel.org, David Herrmann , Mike Rapoport , David Rheinsberg , Hugh Dickins , Hagen Paul Pfeifer , James Bottomley , Andrew Morton , Linus Torvalds , Andy Lutomirski , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] man/man2/memfd_secret.2: Correct the flags Message-ID: <7umhm4evxdbhvoezkcnpnt4vpaqoylwia25pzusby6evmvkoib@nfanksvdoq3c> References: <20250612061705.1177931-1-i@fuzy.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="y4mw2jlmwswrkrl3" Content-Disposition: inline In-Reply-To: <20250612061705.1177931-1-i@fuzy.me> X-Stat-Signature: pm3nry1qphxaybki917e4khsymc6okmu X-Rspamd-Queue-Id: 736F2A0003 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1749721543-290710 X-HE-Meta: U2FsdGVkX1+PBV0yViFIxLys0UV9uKk6jJP/eqyPa4v7/i4m2e78qeHjQbwDF+KNoG9JyNUKiQbpesUb6NCesVWKWjfWzb2rfUN/omrk9//PhaNVt0rG2oLdsMXwITGgfRgDCIOD8CRErrjvkV6AEwLIYExerOeLNZ3sYkc5sMTitPnSFlf2sDobzvO2Ij5hyIGl4b2u1YbrIaE1pI0SWPQ7MR49YfQzVHl1GagWOz00oPslIeO7HOvOswmBGVYAFzhNPL21RtxOKokAfZGf0pnK+xtgssTQBj8v+7+/rcXtipgmqr9qaJxYZtBJ7CEzesu0eqbdIGF96DwzeA0KwoF1VQ+vAr4COwqtIVXxo/tj+hcMVr2PohwMYXjbM4UpCTM+rAjOA6VKEbqIeLHeBuJAidREqStaBa8H8a/jRwQc0xXjhlc/JaNT4/yQnESxWAAscIaO4iNxpwl41XKD9jQ5d0Im3bH1Fx2NlYlWOBQxmf3QeCUMTd1m5d2t32HMPA42iN4b2I4h46NPqng8iYeig1i3Lj0VvGHUHsP5yMUpp2rt1Tux0dC+dEndqLUkXy80Lkl/+8DXrZA3cYoK92+qY5nO6UNTZEtk7U/oq4ZgVv4RKYX9Vo1pwhqYtaH6K4UH5n39VVuTq00xaoXA+UOIUQNo5YR0QqhxPHZ+7zQRfJV7wOA1X1GF/VRfSTobLWP+cRV3ie5gt+8k49aCBnRVA1Lh7/QH/nrejU+EARQN2amaOkSVxMR4W9z7WDxMasvbzvHfNQTzho8Xnk1kIIPuLSiVN1W0yjMUJH1a1PJIO3P8hR3VVqSbzLdix+q8qQ2KsgHwUUy3SZn1hHMonfLbTBHW6kgd4aHfrTEVwlTUavnpxgvhgHh2l4RIo4aqY02ZMpuR0LbRwCND9VToel41cjuKU7ms57HVMbHp3ECLV3HqrjsQLnNf1bYZ2Biecj31I//XV9/gjiJffSH h+WvZjZ9 eLFl09oMvfOWBsGmPno7y00y7xUBUxPmRzsZiutTePviSMBNsodNA8JeqDpSr/BrdrmWwzwpNTePIDQNZh+Q+AFAP/UxMzTWDwNEwOcBBsH5yFD8tOhXixvutXdTrODFjZNTU57xz46CtfeD4JzaiziCL4IjyciS7ASdpx/mllPY3IcASJgCGQ2w0i4sV6jLih/ZXOPbcgoQ4H86KgzeFYFJ6b3Lna+jKQhfLSgDaeb48UjfwUR/Wo1mHzps+3BGIqX+hNhlbwQjKB97o24On95Jd/Nf3j+/SgbBcqlB2KZvTLd9KKGlxiKE24D1w64aAU0WqvJPRbrCSY1w+7Rd42jtesAwL8gcY+JiQklMTQVL1RMiM38hdYRDhpsFwugLiL8Z3dxPAF5mNRbDa6c48Fl9B3PsBlr3Ptm17Vq6udtpl/mVf4X2vu7cIXvHPO9FHZgHKYTbaD0/GVtknQHHJDUUvYettap8gPUkOqF0AHR5uDMlWOGYrDgV7cktOGiUA167bFOSlNmcOaUYyQulzt8SZGNBjQpyPH2w7s0RKeF7ODwVn4xC248izJ1Hwjn2iVGFKW1KeKQ7CZZDel4avqEH8lHHjstpwsSEXvV7/INrrIrPYJVeg6VUQ4k18xcX/oXzslgnIjL28glYf6nMO6xnWJ6aYK0Tp17rFuvkV/qgM48yfh9klfxFJ4aQGk+ujp/IieU28zLn9lj4PlLbuBZb+O2fij+2TLC5Nyr1sQvmB2FHz01DUYL8/4LSWmR/slQ8P2sGkBRV0CB25ouGatIT991G6pppMdftENAs4DXdyFuLqL/wTgcKyf/Tw8epHaJxEN+NlKc21B0co2VYEkSlLsqiQs/4N9jkdE+PCvKzq4Jj0VOWJ9BgTbZwDhrpRiRkiNkDrXjLSEBqwenpqFUn+5XILCpiUFUPd//ixGrxR4q21py6iQ5cHe2zHBvPxhEIpKyaSyKNUw+h4lbD94zXCuqkK aTbeFlf8 LK4ajpO7AmJwQ81jcsPcD34QG7pZHe4meE6euaw1KTytCfZC66pImtzvm3HX2x5cfW08ErDvakBi02YHCGBM7qW4tJNNanc1Bas0mFK+2ej7PLAbESSgAjxWSg5Z98Hox1l8jvQxLIJ1QiBpDDb511itGGH7AMg8aGp8ONYpVcmRL4/ZuOLwY1IV3gBsEEzGdQssGw3keNdmpkShuxP4PzGJGtagx1txufm4mwVYfJgsaqz90K0ChYl2x9h1wmb3VmAHd9o+IHyKoTUymPB2akG/Y6AsbxD/s2dmbfoHmcWMvY5NsMsInNGEWHCbO1S+jneYqw4uNCZHTUKHMMqKbEwb70c6/ow7V8iqqDN6SVB5hzVQI4/z3j+pRO7+dDmyK7ceJaG/jyQjajfCDN/EZdU5GXa3tdljrSb6uzC+wslcuDa4swsEXLVBk2Q0qLbCsbYRJV80Rue1It4dtKwOfxe2zrImHeWlEsIUsghEbAyef2+Xqk7q7is5C423DQXltJzOSkBqCFUYtpDDbggWAmF5CgYS3xng0R0v1bU3eSH+MZn7mhqukg/4ZND6tnRP8zlfW5MpptPcBLAJuz6I+g== 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: --y4mw2jlmwswrkrl3 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: Alejandro Colomar To: Zhengyi Fu Cc: linux-man@vger.kernel.org, David Herrmann , Mike Rapoport , David Rheinsberg , Hugh Dickins , Hagen Paul Pfeifer , James Bottomley , Andrew Morton , Linus Torvalds , Andy Lutomirski , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] man/man2/memfd_secret.2: Correct the flags References: <20250612061705.1177931-1-i@fuzy.me> MIME-Version: 1.0 In-Reply-To: <20250612061705.1177931-1-i@fuzy.me> [CC +=3D people related to memfd_{create,secret}(2) in the kernel] Hi Zhengyi, On Thu, Jun 12, 2025 at 02:17:05PM +0800, Zhengyi Fu wrote: > memfd_secret returns EINVAL when called with FD_CLOEXEC. The > correct flag should be O_CLOEXEC. Thanks for the report! It seems like a bug in the kernel. The documentation was written (relatively) consistent with memfd_create(2), but the implementation was made different. I say the documentation was relatively consistent, because memfd_create(2) uses MFD_CLOEXEC, and memfd_secret(2) documents FD_CLOEXEC, which could be confused, and since they have the same value, it could be considered just a typo. However, O_CLOEXEC is an entirely different flag, which doesn't seem to make sense here. $ grepc -tfld memfd_create . | grep -A4 -e '^[{}.]' -e CLOEXEC; ./mm/memfd.c:SYSCALL_DEFINE2(memfd_create, const char __user *, uname, unsigned int, flags) { struct file *file; int fd, error; char *name; -- fd =3D get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); if (fd < 0) { error =3D fd; goto err_name; } -- } $ grepc -tfld memfd_secret . | grep -A3 -e '^[{}.]' -e CLOEXEC; ./mm/secretmem.c:SYSCALL_DEFINE1(memfd_secret, unsigned int, flags) { struct file *file; int fd, err; -- BUILD_BUG_ON(SECRETMEM_FLAGS_MASK & O_CLOEXEC); if (!secretmem_enable || !can_set_direct_map()) return -ENOSYS; -- if (flags & ~(SECRETMEM_FLAGS_MASK | O_CLOEXEC)) return -EINVAL; if (atomic_read(&secretmem_users) < 0) return -ENFILE; -- fd =3D get_unused_fd_flags(flags & O_CLOEXEC); if (fd < 0) return fd; -- } Let's see who added memfd_create(2): alx@devuan:~/src/linux/linux/master$ git blame -- ./mm/memfd.c | grep _CLO= EXEC 105ff5339f498 (Jeff Xu 2022-12-15 00:12:03 +0000 306) #def= ine MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB | MFD_NOEX= EC_SEAL | MFD_EXEC) f5dbcd90dacd3 (Isaac J. Manjarres 2025-01-10 08:58:59 -0800 475) fd = =3D get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); alx@devuan:~/src/linux/linux/master$ git show f5dbcd90dacd3 | grep -e _CLO= EXEC -e ^diff | grep -B1 -v ^d diff --git a/mm/memfd.c b/mm/memfd.c - fd =3D get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); + fd =3D get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); alx@devuan:~/src/linux/linux/master$ git blame f5dbcd90dacd3^ -- mm/memfd.= c | grep _CLOEXEC 105ff5339f498 (Jeff Xu 2022-12-15 00:12:03 +0000 305) #def= ine MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB | MFD_NOEX= EC_SEAL | MFD_EXEC) 5d752600a8c37 (Mike Kravetz 2018-06-07 17:06:01 -0700 423) fd = =3D get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); alx@devuan:~/src/linux/linux/master$ git show 5d752600a8c37 | grep -e _CLO= EXEC -e ^diff | grep -B1 -v ^d diff --git a/mm/memfd.c b/mm/memfd.c +#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB) + fd =3D get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); diff --git a/mm/shmem.c b/mm/shmem.c -#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB) - fd =3D get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); alx@devuan:~/src/linux/linux/master$ git blame 5d752600a8c37^ -- mm/shmem.= c | grep _CLOEXEC 749df87bd7bee (Mike Kravetz 2017-09-06 16:24:16 -0700 3684) #de= fine MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING | MFD_HUGETLB) 9183df25fe7b1 (David Rheinsberg 2014-08-08 14:25:29 -0700 3729) fd= =3D get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); alx@devuan:~/src/linux/linux/master$ git show 9183df25fe7b1 | grep -e _CLO= EXEC -e ^diff | grep -B1 -v ^d diff --git a/include/uapi/linux/memfd.h b/include/uapi/linux/memfd.h +#define MFD_CLOEXEC 0x0001U -- diff --git a/mm/shmem.c b/mm/shmem.c +#define MFD_ALL_FLAGS (MFD_CLOEXEC | MFD_ALLOW_SEALING) + fd =3D get_unused_fd_flags((flags & MFD_CLOEXEC) ? O_CLOEXEC : 0); alx@devuan:~/src/linux/linux/master$ git show 9183df25fe7b1 | head -n5 commit 9183df25fe7b194563db3fec6dc3202a5855839c Author: David Rheinsberg Date: Fri Aug 8 14:25:29 2014 -0700 shm: add memfd_create() syscall alx@devuan:~/src/linux/linux/master$ git log -1 9183df25fe7b1 | grep @ Author: David Rheinsberg Signed-off-by: David Herrmann Acked-by: Hugh Dickins Cc: Michael Kerrisk Cc: Ryan Lortie Cc: Lennart Poettering Cc: Daniel Mack Cc: Andy Lutomirski Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds And memfd_secret(2): alx@devuan:~/src/linux/linux/master$ git blame -- ./mm/secretmem.c | grep = _CLOEXEC 1507f51255c9f (Mike Rapoport 2021-07-07 18:08:03 -0700 238) BUI= LD_BUG_ON(SECRETMEM_FLAGS_MASK & O_CLOEXEC); 1507f51255c9f (Mike Rapoport 2021-07-07 18:08:03 -0700 243) if = (flags & ~(SECRETMEM_FLAGS_MASK | O_CLOEXEC)) 1507f51255c9f (Mike Rapoport 2021-07-07 18:08:03 -0700 248) fd = =3D get_unused_fd_flags(flags & O_CLOEXEC); alx@devuan:~/src/linux/linux/master$ git show 1507f51255c9f | grep -e _CLO= EXEC -e ^diff | grep -B1 -v ^d diff --git a/mm/secretmem.c b/mm/secretmem.c + BUILD_BUG_ON(SECRETMEM_FLAGS_MASK & O_CLOEXEC); + if (flags & ~(SECRETMEM_FLAGS_MASK | O_CLOEXEC)) + fd =3D get_unused_fd_flags(flags & O_CLOEXEC); alx@devuan:~/src/linux/linux/master$ git show 1507f51255c9f | head -n5 commit 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 Author: Mike Rapoport Date: Wed Jul 7 18:08:03 2021 -0700 mm: introduce memfd_secret system call to create "secret" memory areas alx@devuan:~/src/linux/linux/master$ git log -1 1507f51255c9f | grep @ Author: Mike Rapoport [1] https://lore.kernel.org/linux-mm/213b4567-46ce-f116-9cdf-bbd0c884e= b3c@linux.intel.com/ [akpm@linux-foundation.org: suppress Kconfig whine] Link: https://lkml.kernel.org/r/20210518072034.31572-5-rppt@kernel.org Signed-off-by: Mike Rapoport Acked-by: Hagen Paul Pfeifer Acked-by: James Bottomley Cc: Alexander Viro Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Catalin Marinas Cc: Christopher Lameter Cc: Dan Williams Cc: Dave Hansen Cc: Elena Reshetova Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: James Bottomley Cc: "Kirill A. Shutemov" Cc: Matthew Wilcox Cc: Mark Rutland Cc: Michael Kerrisk Cc: Palmer Dabbelt Cc: Palmer Dabbelt Cc: Paul Walmsley Cc: Peter Zijlstra Cc: Rick Edgecombe Cc: Roman Gushchin Cc: Shakeel Butt Cc: Shuah Khan Cc: Thomas Gleixner Cc: Tycho Andersen Cc: Will Deacon Cc: David Hildenbrand Cc: kernel test robot Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds I've added to CC everyone who had something different than Cc, and everyone who had Cc in both. Now about the situation: it seems there is only one user of CLOEXEC with memfd_secret(2) in Debian: systemtap. Do we want to fix the bug, or do we want to document it? This is for kernel people to respond. Also, was O_CLOEXEC used on purpose, or was it by accident? I expect that either MFD_CLOEXEC should have been used, by imitating memfd_create(2), or a new MFDS_CLOEXEC could have been invented, but O_CLOEXEC doesn't make much sense, IMO. Have a lovely day! Alex >=20 > Signed-off-by: Zhengyi Fu > --- > man/man2/memfd_secret.2 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/man/man2/memfd_secret.2 b/man/man2/memfd_secret.2 > index 5ba7813c1..c6abd2f5f 100644 > --- a/man/man2/memfd_secret.2 > +++ b/man/man2/memfd_secret.2 > @@ -51,7 +51,7 @@ The following values may be bitwise ORed in > to control the behavior of > .BR memfd_secret (): > .TP > -.B FD_CLOEXEC > +.B O_CLOEXEC > Set the close-on-exec flag on the new file descriptor, > which causes the region to be removed from the process on > .BR execve (2). >=20 --=20 --y4mw2jlmwswrkrl3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmhKoboACgkQ64mZXMKQ wqlzeQ/+K5xch9iM3q4DGbnPGkxzDEmxrRjZdLkg8gQ8eEK95ENojQie/eSI2F/Z PbEaGb2rQz3re4H0jLAKTo9Yyu40JmFuFLQxYmOaouZE+74zQ/hV/67axyic7Kf6 pV5SUq1s57WZEq0vqCbRBWURNup5bJD7Ijtv/7XPMI77hJDIEBNwceh6+kQ0OxMb Tm9dnuuaaT6Yk2rjko3SkCy8DA/RCii76suUmRdT0qL57XAW3PA0w27bJg/pBKNh eaZLynwd2QhxGdVJf0fYBH04bpdz8PySd5tBKdxXCIP5N78GqIl3HrpKSjYY44Uc bmUWTVf+BvU2wclKC+h5jDU5S9ZgSQH4s6gKstGUPeSDtICn1dA2AB0pb9NTIgsu mGNfsbSyKIGPsQNV68AOrRd0BTSx1lBxfXrimO8fE+HCA9+FoGIGgcOeT+sjcddl 1Zs0FC8XetFUDvnojUKVKLrPvsa0+fuElX9hcwtaVO4s2mbyGx9EugQiof8f4MUr zHxpJF8TPJhOQSGHS/mS4QtQjg8o5HxcMWJU5MjANDGea+auAYQ0u4RK7ZpAXiVX 4priCtY1yJYkYe8flBhIKL9j2iwXmvOMx61MdXNu3bqEvWB+9XSxiIUtKw5H3D8W 0QTM+dQR1eUBqwzP1bdo+oJbPvrrF1Z5Ydej7GzxG4TNPY9PdAI= =PZp/ -----END PGP SIGNATURE----- --y4mw2jlmwswrkrl3--