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 1259EC3DA7F for ; Mon, 5 Aug 2024 21:05:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B38C6B008C; Mon, 5 Aug 2024 17:05:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93BE06B0092; Mon, 5 Aug 2024 17:05:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B5EF6B0093; Mon, 5 Aug 2024 17:05:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 57FD76B008C for ; Mon, 5 Aug 2024 17:05:14 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CB23CA8EA3 for ; Mon, 5 Aug 2024 21:05:13 +0000 (UTC) X-FDA: 82419422106.17.6048DE2 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf02.hostedemail.com (Postfix) with ESMTP id AA8EF8002B for ; Mon, 5 Aug 2024 21:05:11 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Auhdec/w"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of kees@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722891866; a=rsa-sha256; cv=none; b=AABxZOmiE9OE3v4XkRI9zHngifDSOWttSW7yXsTwMGJpzugfq7NowrTcmMCXvBNZAWmmRc gPSQCGYsIONJ/BVxehuAM2syE19UNPm0DSRaaHyWBD3q7RLxniolNgCOCWKP90DPPjzVP8 mAVziYw6trRG1VPsV5DvZ1YNAdl2C6A= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Auhdec/w"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of kees@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722891866; 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=cbQYCZZGJ0/OwhjbCCDRBUJOJgmBDU3SsR96x7vZckY=; b=wR203kJcL9nAzo2BcaEl4ezltYP5cwdBgsIXxLJjyrMB3Va6U4NHN8NR1KOdwHUQkHKt1V RSkI2z2FR4bFDztNeWRoqsMErhtRy8B8hiJDvO3kqSakXL9wiFkqN/lHT4zdtwcFjtWjZv ybDuZyZhB+kqodXf4CdUn7j820+srvE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 26B5ACE0AF4; Mon, 5 Aug 2024 21:05:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A383C4AF0E; Mon, 5 Aug 2024 21:05:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722891907; bh=hNEorLFNFU6XziMXB83XWj4mCvVyNc1nseFYZY1J8Gc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Auhdec/wyq7LGcHWI7/O+VlKCfOppR2w2Z9hc+ucl5PqwwqUaUSNi7PLygqIXCQ1u 2P+VPexYHtAa1nq3Zkau7gf2aGnvk4x8HcKAaUUHeckM7UjLs0oFfcYITYaArVniLd RgoJ7jaXWTtejKbmGVdUuXlmjY8EGpA2ceV1illlFx7F1a8KWrXqMovJgmCfwFmzpd gRIKPtJWMdAR33X4pZaPfTJvg2WHSym7hMf18RSDEfGpT56JNa9f8nrBpryXVhAQ+E xKIQgtqW5iZs8zDWw/YEUDCWp0A47MNMrcDnly0kIUy9RvgIurISzrR4m7nI8cdCQY HZBx30DXnxAJA== Date: Mon, 5 Aug 2024 14:05:06 -0700 From: Kees Cook To: jeffxu@chromium.org Cc: akpm@linux-foundation.org, jannh@google.com, sroettger@google.com, adhemerval.zanella@linaro.org, ojeda@kernel.org, adobriyan@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org Subject: Re: [RFC PATCH v1 1/1] binfmt_elf: mseal address zero Message-ID: <202408051402.9C0FA18A12@keescook> References: <20240801170838.356177-1-jeffxu@google.com> <20240801170838.356177-2-jeffxu@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240801170838.356177-2-jeffxu@google.com> X-Rspamd-Queue-Id: AA8EF8002B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: i65e89arh7pfne3a9twjku1dbbm79p8x X-HE-Tag: 1722891911-143296 X-HE-Meta: U2FsdGVkX1+3P/jna4kPcShCfJS6WOHwJjBp+KpjWcweK7AgrLBxSOWciHN3tUtcB5IHhqCQeKR9xOhEQGLTOCgeC8nWd8ovE+C60x0Zu0PHz2h4QnTrbj8dqJtPHE0ql60o0NrKkCWgbrjWwGyCaGeWpr9iQGRSbG0sEnb2tOlF2xLsxVcoBbrVmNp+8aGsnYLjXdEzJ3xXja+yIRS/Isyw95t53vg98DPWTU1VT1C5cBXdXmhwRyL+QpbdaDJJyoZDT3zizsjTIj2Y+WVZgAYbHcqt5hTpUkTboZfnys0CZnq+tT7UurA8xNXuRUvaR6uvZzYN9d7jD0/6fOaxgqNf8/WmYlCCfic5VoXblD2+sQyjZkFCIVejY/9jHTTU7myjSLNe2hITxYql24QYe4Fts9lAGD26Inxxrujb5/qeGLxMx811m5j5pBLXDoRXfkoIX7ZlM7pctYGUXzOWFc1AL5j5Pz6J21eIC9XUuU6YFFkKpWhwmmMsxn512s5SL44cvlf0eZ38EoUBuKS6UdJMlmFppQpuUE+LTA0lgFCaw51PZ/fGMt26zq7aAjoY/gr0a9HhNvDggrBJeEWmoK2O8mK6Ov7jUCSi/S3QlhJ32KOv1RundgivlmzdXphEYZbVIugloOLzyVSG/D+67gpfVQTPn8XrNQpcJcUsTW/c1WcUx9bMsLsVzkSf12xWHJqyRppMIAwuHig8EnWxxvXKKlOktmAQGX43DCCSLOIbhOqtc+ATJpR8r56J4B0aNUmWzOqMkYe1aA/Y9/wzeDys490dDheHXyYdEE9Tjt1ONJTOAkKFaqpvOnh2hFh+2EJWBIyOYQO3YlKddMln1T9Yxi7WliGB+R2iw391GbDUSe13OIOYJFdNPu+Q1uvdclq5ypfSGNldkfg/D0anE7sUb5ifBygR6nVrxKIc8jrZqeJJmHIfaWrHuXyEPiXjnuGPvt+ZRDRJbqQVRzy gvIfjkyJ y12SftLrqCQuKYUtW2amWV1lacJSAvxOWBI7TLD+Q6xcjbzwRaSjV6uyHjMM/6/Kzl1CBDo+TOEAiAZ0MtXlXl8yYO9dDkujiyr+/ZuSy8ySLDNK1RFms9EwY8Ur6vUQtqraTMWnrQ5d27k8t0AzX1yM66Z7xRHVYUkGufbqrEmpzL3C078OoxjuoPFF2IFw065QeeXx2N7Zy1Xb/VscH0toxssbJl0tvJ0/lnQYjvsoKggYxYeEz//8Ung8qapJc5uuEfab2DdqqmUG3Z8QaTqixFky3QvhAs175xX7BEFmk3vjogJpJ7NEIwpuOjFZwpHwj 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: On Thu, Aug 01, 2024 at 05:08:33PM +0000, jeffxu@chromium.org wrote: > From: Jeff Xu > > Some legacy SVr4 apps might depend on page on address zero > to be readable, however I can't find a reason that the page > ever becomes writeable, so seal it. > > If there is a compain, we can make this configurable. > > Signed-off-by: Jeff Xu > --- > fs/binfmt_elf.c | 4 ++++ > include/linux/mm.h | 4 ++++ > mm/mseal.c | 2 +- > 3 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 19fa49cd9907..e4d35d6f5d65 100644 > --- a/fs/binfmt_elf.c > +++ b/fs/binfmt_elf.c > @@ -1314,6 +1314,10 @@ static int load_elf_binary(struct linux_binprm *bprm) > emulate the SVr4 behavior. Sigh. */ > error = vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC, > MAP_FIXED | MAP_PRIVATE, 0); > + > +#ifdef CONFIG_64BIT > + do_mseal(0, PAGE_SIZE, 0); > +#endif Instead of wrapping this in #ifdefs, does it make more sense to adjust the mm.h declaration instead, like this below... > } > > regs = current_pt_regs(); > diff --git a/include/linux/mm.h b/include/linux/mm.h > index c4b238a20b76..b5fed60ddcd9 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -4201,4 +4201,8 @@ void vma_pgtable_walk_end(struct vm_area_struct *vma); > > int reserve_mem_find_by_name(const char *name, phys_addr_t *start, phys_addr_t *size); > > +#ifdef CONFIG_64BIT > +int do_mseal(unsigned long start, size_t len_in, unsigned long flags); #else static inline int do_mseal(unsigned long start, size_t len_in, unsigned long flags) { return -ENOTSUPP; } > +#endif > + > #endif /* _LINUX_MM_H */ > diff --git a/mm/mseal.c b/mm/mseal.c > index bf783bba8ed0..7a40a84569c8 100644 > --- a/mm/mseal.c > +++ b/mm/mseal.c > @@ -248,7 +248,7 @@ static int apply_mm_seal(unsigned long start, unsigned long end) > * > * unseal() is not supported. > */ > -static int do_mseal(unsigned long start, size_t len_in, unsigned long flags) > +int do_mseal(unsigned long start, size_t len_in, unsigned long flags) > { > size_t len; > int ret = 0; > -- > 2.46.0.rc1.232.g9752f9e123-goog > And if it returns an error code, should we check it when used in load_elf_binary()? (And if so, should the mm.h return 0 for non-64bit?) -- Kees Cook