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 36010E810D5 for ; Fri, 29 Sep 2023 12:06:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BFE3F8D00ED; Fri, 29 Sep 2023 08:06:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BAE338D0023; Fri, 29 Sep 2023 08:06:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A75AC8D00ED; Fri, 29 Sep 2023 08:06:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 925D48D0023 for ; Fri, 29 Sep 2023 08:06:53 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5BA5B41132 for ; Fri, 29 Sep 2023 12:06:53 +0000 (UTC) X-FDA: 81289508706.29.EE15AB0 Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) by imf01.hostedemail.com (Postfix) with ESMTP id 8435340019 for ; Fri, 29 Sep 2023 12:06:50 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="dqFh/6U/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.217.41 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695989210; a=rsa-sha256; cv=none; b=Ks9eg23aDumVmGSjx/waCLMhLxFCRGOlSh052jR+I4qAQ6A/Wg3nCCeoxoqMpd+zZgL98B tL2u4n2R03iKQxWx85xjfTNb5q7sSwkKLKBDv0KjfWJ3KP1nqOSEjIZo2ln0Dyc7FAkKiy 03kieF4hsCHa1ZGhkE4wsUPzjZ3jQDk= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="dqFh/6U/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.217.41 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695989210; 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=WklKxHvJ4lWh9tljSeh/U+ySuT04KyfAmm6d+l7zSl4=; b=17p2kEg7VWdbD/a+i59KqWcjY86ObUj+roDbipONW+sMB4+4fTtf2I2uuAflK8MZrUHgxW hKl/pf3zyD3TdCyGpte6vet+ousdG1UfRGsb9wk0mwo4wDYZv3ycOLONCRJZolKmpXvTz/ +7DPV08PtXH6dgcYz1HzMlspi78+VQI= Received: by mail-vs1-f41.google.com with SMTP id ada2fe7eead31-4545d8a95d9so1886799137.2 for ; Fri, 29 Sep 2023 05:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695989209; x=1696594009; darn=kvack.org; 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=WklKxHvJ4lWh9tljSeh/U+ySuT04KyfAmm6d+l7zSl4=; b=dqFh/6U/ZYl+60CCSh9NJc5XFLwSmcAgR0D//lvQnSomN5JzTWNiemF8Tk/Zgl9gB0 idmv0zfe9LwEup1jjwtCUlrr9X9N6tfz/GutjaNxZGxn14eKRoshPRNMC/68WXY5eLCa nvnCYuzPUhbD0Np6zVfsI36zwq2I3M/b2YHo0cXzA2pqNyEZQhCxiPJgkpmWvjSymPu2 wW0q78OMcNd28WlifVhBqThSYyWgz3aU0dahvMZ6sHFFzFQW5nCBBHOm61K3k5mtKsnm eCb7mO5UfaVkEiaSW7NuzDniQX+YE0CYobvWdmJfuKwfHa0El3yc4KBI365Bkmk5l27Q 4PJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695989209; x=1696594009; 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=WklKxHvJ4lWh9tljSeh/U+ySuT04KyfAmm6d+l7zSl4=; b=o8elPiEcPu1P7x0N4FYvZG9z3HjVmdUl/IKAwv5Y5yLuow4KKRXnqbmTUnfrooWosS iwGLRCy/mX5aU0IjkZK0wnrjYulksMVFC9m4zrUSqayZFWYtIV8Hfe16VM9GC2i4SrCy JM+PEPzVdM+oTIa1gQUlhzcH25RJSmiIJrCBEvnMD3QRR0uUSABZrU0zrD89vBZqb4Bo TIEWancqoFLDtArEbNMwBF3GK0eDC4My2S8FRpVZW4R2VgEWe295kNZJevdyTPdv22dg OSyWOKS3mLM39Qfcl1E0C4NuJu7PAjgJOnyUa7LLcMy7cO5Y5lCAhk34yURxmGOoZF0V q3BQ== X-Gm-Message-State: AOJu0YzwqsbYAGNUu6aP2SaMw+ZKmi6qlewGxlbQDVL08NKMkOBH894p FMon9q+gODigN1UIJKioPu51FbcQ9ieFvaCxcd6XetidVvk= X-Google-Smtp-Source: AGHT+IHPnnp9Tml6BPyPUla6wu4iber8g42aabZ9OhsBHrXPZZSJc8ot7WEgSaDN7oTUpTxc+9F3wRzKXu/a/+Psc84= X-Received: by 2002:a05:6102:d4:b0:452:94b8:2fe9 with SMTP id u20-20020a05610200d400b0045294b82fe9mr2992035vsp.21.1695989209499; Fri, 29 Sep 2023 05:06:49 -0700 (PDT) MIME-Version: 1.0 References: <20230929031716.it.155-kees@kernel.org> <20230929032435.2391507-1-keescook@chromium.org> In-Reply-To: <20230929032435.2391507-1-keescook@chromium.org> From: Pedro Falcato Date: Fri, 29 Sep 2023 13:06:38 +0100 Message-ID: Subject: Re: [PATCH v4 1/6] binfmt_elf: Support segments with 0 filesz and misaligned starts To: Kees Cook Cc: Eric Biederman , Sebastian Ott , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , Al Viro , Christian Brauner , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@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-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8435340019 X-Stat-Signature: a54y6ytqotp7xfry5wfhpqp7xiyw7rrj X-HE-Tag: 1695989210-894044 X-HE-Meta: U2FsdGVkX1/2LAfLnn0x4kIceE/uhhH+7ph4VcM5P2bE6c2QEHRJg0Hg+UBUnPGHgC9IcCEHAaXUvNQoIwJH6Y9ACn/vkgUBq++1edJgdoL2cqV9o7bxNMVviLehJrp1UrmIbtIxrwOcMCvX2FNWu+DEjPhGA4QKrWEoNxxNvjWQg5L0Uzqt0L7VF7zl4hJBh8enbUrir+eYxRng3fnF4ySPGA8vCBuW8kKZARk0hqZFCL0rJAAHnN8flLmZ9HiIgGc+qJw3Pcb4tnRYeX1VYE3Hd90TdgJh6Q07I31yuY08FhoQJX7ghO/kCOIPtrENbYi9pQL65P+WkidaebhpTZJDY9rT4pEBGtr+pAesDJx2mXfv5w34vcp79E+Zu7lTBulSN+2gyvi1FQiMxTN6/MdSn43Ho89HSQ31HhSFubLP0e9VB6h3vexyIaoDMhCEkF8hR09zbhY3nlddyBd+nmeP083JgEHGH7NK6UP9BSeqUoft5GEPHS/JOZmQMZSuN4Ikh4T8N1lY1xIMMemWvt0rYQaysNvuAwvtiTgeRApSpcUMZ5SvB+zygG8UM5K/vavcB5+veldR+PJb76Dv1VEq2yoV1b/kJpJQCVbpeTc+k0KFTGiivbPajV0JPzMCgcUvBFWZmv3gYYJGKR2fQEZGD+1aV9QQ3rq4w0Ic7R8o3xBzRWAsaFLaPMZTVARMRlMxxDsRXg42wmbnx+BzdeT1j/765bwkLuKViUjp9Z+bjofBaz2WOp9mik04Odcne3m47iU8+n34xzTH+SvApSpq+mC1a5HYMI0jDY375uBeswP0LHcxWFvuHY+/qY2sezBXTfeh/EAUOWJaMmml44K0qAxAVzTXLWGSDKQOlJQwQNv/2AgUsAQAWo1CoXklH2ua04M+eQcWKKrs/QpEdaTcIA5w73Zi1OUrFGFUxVW7JGy2bIuGJqR/p83ZdLwgxXa0qtNal2BvAVA4zGD lzFGfQT1 DOVYelyZD2t9VjVA+ZSu7x1QgjHeSzJ6iaAu1DyPsHeRG53nSxMKmiqe4wP9T3lLjVQciaqQrDhlJkDkbJsZy5VGy0Spozu4DhoBmdeQU5L6HA9zWYq8bVvQyHu545gTj4BAJwDg00AZ7xoCac8cxvdLC3DOFlh3IPvBQ9BCI13Yh7k57meqITYoCGKR0eCqRixGTaKXTxkKBetIUuKaUBPLiWRLQo8Xn/rJwaxAvQHQrL2UsenW8TKqqGKbcCpYtnSGMyMtbsyn5uSF66oUCsbXKozJFQ1bx42egS05WcdpwFV7n93fdudoGSdZa7ZA6FuN1+C0SoWggYqM53l10MVXvFj78n2/DQv6btKQhzOYSAV5dDczwfRoEQGCxFejTeTZUnCv+Z6NaXIzpvorHeUrPtH06/WTH8aEid6MoSqfV3kIY5nui9u7n0hfRUe61x45qn/5AChE+OkZucU6Q6OUHZXs9xzWVK0V/6sJU8nG4f5yMbszvXqe5+6692Y+1tgTF3ixhw0J+XaBVDqEdIR5DLGiocwSdd0+kDqZVfO+l0GJeyIXavmhjE73YWV1pVX12cdBIlY2zOlD5CyqnPvXFIONFec8Zk9JhJNy530mKY1N5c2FhGlgECczWdfhioNtVVodEGOzFegTdSV5ZEnhBVg5Lb7fqShm2Sb8KDpSylEtNEC+1x23q2wS5lRFNbD65unr68AkHNvBtONtJqo09pBdtjCoRI6+VCI5nP8txxcDItzsDlQPIGD23H7Opv6ey01ZyQmJpd0Q= 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: On Fri, Sep 29, 2023 at 4:24=E2=80=AFAM Kees Cook w= rote: > > From: "Eric W. Biederman" > > Implement a helper elf_load() that wraps elf_map() and performs all > of the necessary work to ensure that when "memsz > filesz" the bytes > described by "memsz > filesz" are zeroed. > > An outstanding issue is if the first segment has filesz 0, and has a > randomized location. But that is the same as today. > > In this change I replaced an open coded padzero() that did not clear > all of the way to the end of the page, with padzero() that does. > > I also stopped checking the return of padzero() as there is at least > one known case where testing for failure is the wrong thing to do. > It looks like binfmt_elf_fdpic may have the proper set of tests > for when error handling can be safely completed. > > I found a couple of commits in the old history > https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git, > that look very interesting in understanding this code. > > commit 39b56d902bf3 ("[PATCH] binfmt_elf: clearing bss may fail") > commit c6e2227e4a3e ("[SPARC64]: Missing user access return value checks = in fs/binfmt_elf.c and fs/compat.c") > commit 5bf3be033f50 ("v2.4.10.1 -> v2.4.10.2") > > Looking at commit 39b56d902bf3 ("[PATCH] binfmt_elf: clearing bss may fai= l"): > > commit 39b56d902bf35241e7cba6cc30b828ed937175ad > > Author: Pavel Machek > > Date: Wed Feb 9 22:40:30 2005 -0800 > > > > [PATCH] binfmt_elf: clearing bss may fail > > > > So we discover that Borland's Kylix application builder emits weird= elf > > files which describe a non-writeable bss segment. > > > > So remove the clear_user() check at the place where we zero out the= bss. I > > don't _think_ there are any security implications here (plus we've = never > > checked that clear_user() return value, so whoops if it is a proble= m). > > > > Signed-off-by: Pavel Machek > > Signed-off-by: Andrew Morton > > Signed-off-by: Linus Torvalds > > It seems pretty clear that binfmt_elf_fdpic with skipping clear_user() fo= r > non-writable segments and otherwise calling clear_user(), aka padzero(), > and checking it's return code is the right thing to do. > > I just skipped the error checking as that avoids breaking things. > > And notably, it looks like Borland's Kylix died in 2005 so it might be > safe to just consider read-only segments with memsz > filesz an error. > > Reported-by: Sebastian Ott > Reported-by: Thomas Wei=C3=9Fschuh > Closes: https://lkml.kernel.org/r/20230914-bss-alloc-v1-1-78de67d2c6dd@we= issschuh.net > Signed-off-by: "Eric W. Biederman" > Link: https://lore.kernel.org/r/87sf71f123.fsf@email.froward.int.ebiederm= .org > Signed-off-by: Kees Cook > --- > fs/binfmt_elf.c | 111 +++++++++++++++++++++--------------------------- > 1 file changed, 48 insertions(+), 63 deletions(-) > > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 7b3d2d491407..2a615f476e44 100644 > --- a/fs/binfmt_elf.c > +++ b/fs/binfmt_elf.c > @@ -110,25 +110,6 @@ static struct linux_binfmt elf_format =3D { > > #define BAD_ADDR(x) (unlikely((unsigned long)(x) >=3D TASK_SIZE)) > > -static int set_brk(unsigned long start, unsigned long end, int prot) > -{ > - start =3D ELF_PAGEALIGN(start); > - end =3D ELF_PAGEALIGN(end); > - if (end > start) { > - /* > - * Map the last of the bss segment. > - * If the header is requesting these pages to be > - * executable, honour that (ppc32 needs this). > - */ > - int error =3D vm_brk_flags(start, end - start, > - prot & PROT_EXEC ? VM_EXEC : 0); > - if (error) > - return error; > - } > - current->mm->start_brk =3D current->mm->brk =3D end; > - return 0; > -} > - > /* We need to explicitly zero any fractional pages > after the data section (i.e. bss). This would > contain the junk from the file that should not > @@ -406,6 +387,51 @@ static unsigned long elf_map(struct file *filep, uns= igned long addr, > return(map_addr); > } > > +static unsigned long elf_load(struct file *filep, unsigned long addr, > + const struct elf_phdr *eppnt, int prot, int type, > + unsigned long total_size) > +{ > + unsigned long zero_start, zero_end; > + unsigned long map_addr; > + > + if (eppnt->p_filesz) { > + map_addr =3D elf_map(filep, addr, eppnt, prot, type, tota= l_size); > + if (BAD_ADDR(map_addr)) > + return map_addr; > + if (eppnt->p_memsz > eppnt->p_filesz) { > + zero_start =3D map_addr + ELF_PAGEOFFSET(eppnt->p= _vaddr) + > + eppnt->p_filesz; > + zero_end =3D map_addr + ELF_PAGEOFFSET(eppnt->p_v= addr) + > + eppnt->p_memsz; > + > + /* Zero the end of the last mapped page */ > + padzero(zero_start); > + } > + } else { > + map_addr =3D zero_start =3D ELF_PAGESTART(addr); > + zero_end =3D zero_start + ELF_PAGEOFFSET(eppnt->p_vaddr) = + > + eppnt->p_memsz; What happens if a previous segment has mapped ELF_PAGESTART(addr)? Don't we risk mapping over that? Whereas AFAIK old logic would just padzero the bss bytes. --=20 Pedro