Received: by 10.223.176.5 with SMTP id f5csp3242861wra; Thu, 1 Feb 2018 13:11:15 -0800 (PST) X-Google-Smtp-Source: AH8x2262O/xtHbMJr+N/sWKhoQ8Kj70F5ajuIx04TQJkQhThu9RUboUy8r19S/O3psggOnrRA9lT X-Received: by 2002:a17:902:d24:: with SMTP id 33-v6mr32768394plu.40.1517519475303; Thu, 01 Feb 2018 13:11:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517519475; cv=none; d=google.com; s=arc-20160816; b=za8r7LvHFr12vBjBDHDFx+A/lbqQwE3C8Bh7/R5xR55mZVh37mQFMFcBW2WWPq/1I5 4Ix57tOYIQHrQHlvWD6rh9dp+wtIbu9fPaycsTcojiWq9kQsvl5yjyV2k6EnjCKNB2gS zSaQE9t3HYb0u/esnL1fO5R/wRvNDNBaqEc7b1sF95SA8b+MTQ++9QpJxYVNVPSC1j+z 8fzXpQET5uNdYMuDaB602HorxOowRrogFYFRulzanLfey2YvmHz/s0PKimYCGK5eOOJd byFZeas4w2A9vbDeuTIDsguovwtv/ckLPzpsydPGzLMq0u+lHku9g5wAPL9wL4qRYXsU yJNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=W0D0Pw8L3r950WkCrOzU8VzwO3/0JlL/rMaZYLHLgQ0=; b=00eTOYjl0AypwjOdPXELGDwHsTfyL/XrpnPQ9oNOZ08QdUUqXsORMRUGDojmspwFRu XH5KWnAEXk1oSPL8VVhx6Qq1qWJL9zImrEWsbDSpmgtrk+h8T12yPoWe5UQxXuvfjThq 4g+jQ6r1EN4xmZuWLZQ6wAufYoVD7PrUFAy2kPEnfpAaZqZBjIq7mJf/BuBaUc1XkBan fvs9fU9jhQwPCIEetNKOKi6KGg7VOlxXBEi5+obJq6CfjI4y/WEo8AvM3BCIJydWjJgT Z4MvyF/ZEKvomTnWJZUOvLZ0FKSk3+B+/DUjg00AxLrlCvkSCfXnXZNQW0wz9SODpAIb W+IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=jKACB//x; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i1si276386pgn.373.2018.02.01.13.10.25; Thu, 01 Feb 2018 13:11:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=jKACB//x; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751630AbeBAVGe (ORCPT + 99 others); Thu, 1 Feb 2018 16:06:34 -0500 Received: from mail-vk0-f52.google.com ([209.85.213.52]:37397 "EHLO mail-vk0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751012AbeBAVG0 (ORCPT ); Thu, 1 Feb 2018 16:06:26 -0500 Received: by mail-vk0-f52.google.com with SMTP id g83so12169915vki.4 for ; Thu, 01 Feb 2018 13:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W0D0Pw8L3r950WkCrOzU8VzwO3/0JlL/rMaZYLHLgQ0=; b=jKACB//xZ7oxOyvC1qac9naf8/6mo/93wTokeTfI69ljyITIE5HPoK11wtotNBB8Ut k69h7yC/wgYiyE3JVJcST8oTZqqVuukQiiziyxd7putLANHH4ChPdw9a1Nfp+h3MiDRh O6qg2sgh0XcIG2T75hX0bI5p8RpiUUwC3uGCpGNOifd9tns4dKhmU6J53tIwMtc25tPB H6Q8edm7gTo7za+cAWIEfA5ySlp+ZLlPLjGG5rYL8Zt4eUToOzkG6dNC2iH79Xjn5Ji6 ooF2wXGMzkaLkUzkZdf62n4RyQpaRb1wymgi5Rl6fdh2c6pYWRxNab92dmzx/9I4iFTe x/Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W0D0Pw8L3r950WkCrOzU8VzwO3/0JlL/rMaZYLHLgQ0=; b=L0o4APN0UWxIDaD94HPHK3h7QTIeGUhbDaqiasE0U4mG/Do/j2dshIMd9WVX6+UXsC 39zWLsTkf7wMEeaB/bAdDgmf8rIzhUSIcldUH7W2Uz5OkgTPF4Zs1V1P5RpSMO8xzprd 734AKSr8gpFRXw7lB5IaGfjgBk9bwA0ZlQxHzvz3ahfjrTdlNXnPV6ktdJiHChT/1BMc zdsqgwVoXEiVSg4uYOk9sMXS/SS16oMqavvPW+Zmn4ZuT2qzYajTxpTUm18i99IIG6CC thJ/ykiejuAPFmbage8rNVPiIaSaf0oB/KPdw9IXRMiwaXJ7QJtywJhjxG11PRgDOHoU Oltw== X-Gm-Message-State: AKwxytekWbCrTXTLKvtLIe0LPZHP0LmZqaMyCIsTNJVvP24NAfNCrtmp x0a0cmlGqpQiOJTM1JfP5HuBT4w8sJbN1Y+sYNj+4g== X-Received: by 10.31.164.69 with SMTP id n66mr29024019vke.49.1517519185810; Thu, 01 Feb 2018 13:06:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.67.196 with HTTP; Thu, 1 Feb 2018 13:06:25 -0800 (PST) In-Reply-To: <20180201134829.GL21609@dhcp22.suse.cz> References: <5acba3c2-754d-e449-24ff-a72a0ad0d895@linux.vnet.ibm.com> <20180126140415.GD5027@dhcp22.suse.cz> <15da8c87-e6db-13aa-01c8-a913656bfdb6@linux.vnet.ibm.com> <6db9b33d-fd46-c529-b357-3397926f0733@linux.vnet.ibm.com> <20180129132235.GE21609@dhcp22.suse.cz> <87k1w081e7.fsf@concordia.ellerman.id.au> <20180130094205.GS21609@dhcp22.suse.cz> <5eccdc1b-6a10-b48a-c63f-295f69473d97@linux.vnet.ibm.com> <20180131131937.GA6740@dhcp22.suse.cz> <20180201134829.GL21609@dhcp22.suse.cz> From: Kees Cook Date: Fri, 2 Feb 2018 08:06:25 +1100 Message-ID: Subject: Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE To: Michal Hocko Cc: Anshuman Khandual , Michael Ellerman , "akpm@linux-foundation.org" , mm-commits@vger.kernel.org, LKML , Linux-MM , "linux-fsdevel@vger.kernel.org" , Linux-Next , Stephen Rothwell , Mark Brown Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 2, 2018 at 12:48 AM, Michal Hocko wrote: > On Thu 01-02-18 08:43:34, Anshuman Khandual wrote: > [...] >> $dmesg | grep elf_brk >> [ 9.571192] elf_brk 10030328 elf_bss 10030000 >> >> static int load_elf_binary(struct linux_binprm *bprm) >> --------------------- >> >> if (unlikely (elf_brk > elf_bss)) { >> unsigned long nbyte; >> >> /* There was a PT_LOAD segment with p_memsz > p_filesz >> before this one. Map anonymous pages, if needed, >> and clear the area. */ >> retval = set_brk(elf_bss + load_bias, >> elf_brk + load_bias, >> bss_prot); >> >> >> --------------------- > > Just a blind shot... Does the following make any difference? > --- > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 021fe78998ea..04b24d00c911 100644 > --- a/fs/binfmt_elf.c > +++ b/fs/binfmt_elf.c > @@ -895,7 +895,7 @@ static int load_elf_binary(struct linux_binprm *bprm) > the correct location in memory. */ > for(i = 0, elf_ppnt = elf_phdata; > i < loc->elf_ex.e_phnum; i++, elf_ppnt++) { > - int elf_prot = 0, elf_flags; > + int elf_prot = 0, elf_flags, elf_fixed = MAP_FIXED_NOREPLACE; > unsigned long k, vaddr; > unsigned long total_size = 0; > > @@ -927,6 +927,7 @@ static int load_elf_binary(struct linux_binprm *bprm) > */ > } > } > + elf_fixed = MAP_FIXED; > } > > if (elf_ppnt->p_flags & PF_R) > @@ -944,7 +945,7 @@ static int load_elf_binary(struct linux_binprm *bprm) > * the ET_DYN load_addr calculations, proceed normally. > */ > if (loc->elf_ex.e_type == ET_EXEC || load_addr_set) { > - elf_flags |= MAP_FIXED_NOREPLACE; > + elf_flags |= elf_fixed; > } else if (loc->elf_ex.e_type == ET_DYN) { > /* > * This logic is run once for the first LOAD Program > @@ -980,7 +981,7 @@ static int load_elf_binary(struct linux_binprm *bprm) > load_bias = ELF_ET_DYN_BASE; > if (current->flags & PF_RANDOMIZE) > load_bias += arch_mmap_rnd(); > - elf_flags |= MAP_FIXED_NOREPLACE; > + elf_flags |= elf_fixed; > } else > load_bias = 0; If I'm reading this patch correctly, the intention is to allow LOADs after brk-expansion to collide with the prior LOAD? (This patch will need more comments for our future sanity.) I think this makes sense, though it might be nice to be sure we're overlapping only with the prior LOAD (and nothing else), but it's not clear to me the best way to accomplish that here. Even without that extra check, I think this is a net benefit (i.e. gain MAP_FIXED_NOREPLACE without breaking page-crossing LOADs). Actually, maybe the second LOAD could be page-aligned first, so it doesn't collide with the prior LOAD, and it could keep MAP_FIXED_NOREPLACE? I'll have more time to study this on Monday... -Kees -- Kees Cook Pixel Security