From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Date: Thu, 30 Apr 2020 16:54:28 +0000 Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there Message-Id: List-Id: References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> In-Reply-To: <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Greg Ungerer Cc: Mark Salter , Rich Felker , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Nicolas Pitre , Linux-sh list , Jann Horn , Linux Kernel Mailing List , Russell King - ARM Linux admin , Linux-MM , Alexander Viro , Oleg Nesterov , linux-fsdevel , Andrew Morton , Aurelien Jacquiot , Christoph Hellwig , Linux ARM , "Eric W . Biederman" On Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote: > > > in load_flat_file() - which is also used to loading _libraries_. Where > > it makes no sense at all. > > I haven't looked at the shared lib support in there for a long time, > but I thought that "id" is only 0 for the actual final program. > Libraries have a slot or id number associated with them. Yes, that was my assumption, but looking at the code, it really isn't obvious that that is the case at all. 'id' gets calculated from fields that very much look like they could be zero (eg by taking the top bits from another random field). > > Most of that file goes back to pre-git days. And most of the commits > > since are not so much about binfmt_flat, as they are about cleanups or > > changes elsewhere where binfmt_flat was just a victim. > > I'll have a look at this. Thanks. > Quick hack test shows moving setup_new_exec(bprm) to be just before > install_exec_creds(bprm) works fine for the static binaries case. > Doing the flush_old_exec(bprm) there too crashed out - I'll need to > dig into that to see why. Just moving setup_new_exec() would at least allow us to then join the two together, and just say "setup_new_exec() does the credential installation too". So to some degree, that's the important one. But that flush_old_exec() does look odd in load_flat_file(). It's not like anything but executing a binary should flush the old exec. Certainly not loading a library, however odd that flat library code is. My _guess_ is that the reason for this is that "load_flat_file()" also does a lot of verification of the file and does that whole "return -ENOEXEC if the file format isn't right". So we don't want to flush the old exec before that is done, but we obviously also don't want to flush the old exec after we've actually loaded the new one into memory.. So the location of flush_old_exec() makes that kind of sense, but it would have made it better if that flat file support had a clear separation of "check the file" from "load the file". Oh well. As mentioned, the whole "at least put setup_new_exec() and install_exec_creds() together" is the bigger thing. But if it's true that nobody really uses the odd flat library support any more and there are no testers, maybe we should consider ripping it out... Linus 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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D5BFC47247 for ; Thu, 30 Apr 2020 16:54:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5796420731 for ; Thu, 30 Apr 2020 16:54:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588265692; bh=GRz0MjdAJYUSKX0qjB7uaN1+gBpFef7jlGLPAFPcUn0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=wdRPAdpNXNYa0dYupRkJPReGU/YhB5Zd58On7cNCSX3vUoDjhpIvTb0ydpjVFYiCc BpX7juOR6ywjdkBZ797U2w12of3LvCauGprB5ylp5Xq71pEqwTVHUEGHy5J2XXciZy N+a36/z1Ox3rKaohAGNV9EMW4ftp6TqE0hilMdJs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726679AbgD3Qyv (ORCPT ); Thu, 30 Apr 2020 12:54:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726272AbgD3Qyv (ORCPT ); Thu, 30 Apr 2020 12:54:51 -0400 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A22CDC035494 for ; Thu, 30 Apr 2020 09:54:50 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id a21so40116ljj.11 for ; Thu, 30 Apr 2020 09:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jusIkjp3Dz4is1PZPLtprnCAT5bOhq5lF7YlVU3AWyQ=; b=K/L1x2WLoEDVhKcajWjRfk8di4UnhY9fQ857BctryF99FXnh8lvm/+FMFP7To9VzLC Oeh5Zl2gS6/3rwg+PAIfEpUDm0vFKxb3sBkuIMd/j+tdM33ErRljDKSRox35DyrhVqQy cxTvpJRHT1GSdzAq5WmfU86CiiQNmQ4AcXgOg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jusIkjp3Dz4is1PZPLtprnCAT5bOhq5lF7YlVU3AWyQ=; b=JdjxCR9B3TWfZWtVRiU6rp8SIRyq1H5xV4mfYnA625wjVrgRIaN8kcY/fSrgl1HWuj R329ym6twrBiubGPlBRVbTKErROetNPHXWy3e02GJozlD/n+KGJc2UBpXlSrMIAWfuFH POY8z8IdcT3ZvaMXUm8kwhL+3vhqxo5bFv1+AsvaLZ7Z9x54cOYLfqYjv1g1mTgphEH0 +OJYB4Riym7f68qJ3efvkc85jqohy6SkWzcHlrkbZEVOmCy/JxBdi5o/kh9/Wqo0xu51 X5KpflxbbwVuTnVzXbcJPtQJNtFS566dwVMBLs35R+FLP0c1vy5w69zSmB2rG/Ps5Wue tZNg== X-Gm-Message-State: AGi0PuaFsbQ13X2Pme4XhdZqHHrm5gLbPym3IovFmMLNAdekVVQrWlVw rCIeGGJzBsCZ73imnTmcl9WJHQkh6wI= X-Google-Smtp-Source: APiQypImXeEbxtL7c3uuxIaXyJw9GW1Gz1zvC/A4TrCZhI3oJTRqVBrNKH5JRJeYLUsuQGs7Iiz5vg== X-Received: by 2002:a05:651c:39b:: with SMTP id e27mr130566ljp.145.1588265687533; Thu, 30 Apr 2020 09:54:47 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id g3sm255111ljk.27.2020.04.30.09.54.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 09:54:46 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id j14so1813586lfg.9 for ; Thu, 30 Apr 2020 09:54:45 -0700 (PDT) X-Received: by 2002:a05:6512:405:: with SMTP id u5mr2728777lfk.192.1588265685113; Thu, 30 Apr 2020 09:54:45 -0700 (PDT) MIME-Version: 1.0 References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> In-Reply-To: <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> From: Linus Torvalds Date: Thu, 30 Apr 2020 09:54:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there To: Greg Ungerer Cc: Russell King - ARM Linux admin , Jann Horn , Nicolas Pitre , Andrew Morton , Christoph Hellwig , Linux Kernel Mailing List , Linux-MM , linux-fsdevel , Alexander Viro , "Eric W . Biederman" , Oleg Nesterov , Linux ARM , Mark Salter , Aurelien Jacquiot , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Rich Felker , Linux-sh list 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 Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote: > > > in load_flat_file() - which is also used to loading _libraries_. Where > > it makes no sense at all. > > I haven't looked at the shared lib support in there for a long time, > but I thought that "id" is only 0 for the actual final program. > Libraries have a slot or id number associated with them. Yes, that was my assumption, but looking at the code, it really isn't obvious that that is the case at all. 'id' gets calculated from fields that very much look like they could be zero (eg by taking the top bits from another random field). > > Most of that file goes back to pre-git days. And most of the commits > > since are not so much about binfmt_flat, as they are about cleanups or > > changes elsewhere where binfmt_flat was just a victim. > > I'll have a look at this. Thanks. > Quick hack test shows moving setup_new_exec(bprm) to be just before > install_exec_creds(bprm) works fine for the static binaries case. > Doing the flush_old_exec(bprm) there too crashed out - I'll need to > dig into that to see why. Just moving setup_new_exec() would at least allow us to then join the two together, and just say "setup_new_exec() does the credential installation too". So to some degree, that's the important one. But that flush_old_exec() does look odd in load_flat_file(). It's not like anything but executing a binary should flush the old exec. Certainly not loading a library, however odd that flat library code is. My _guess_ is that the reason for this is that "load_flat_file()" also does a lot of verification of the file and does that whole "return -ENOEXEC if the file format isn't right". So we don't want to flush the old exec before that is done, but we obviously also don't want to flush the old exec after we've actually loaded the new one into memory.. So the location of flush_old_exec() makes that kind of sense, but it would have made it better if that flat file support had a clear separation of "check the file" from "load the file". Oh well. As mentioned, the whole "at least put setup_new_exec() and install_exec_creds() together" is the bigger thing. But if it's true that nobody really uses the odd flat library support any more and there are no testers, maybe we should consider ripping it out... Linus 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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50483C47247 for ; Thu, 30 Apr 2020 17:03:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 10BCB20787 for ; Thu, 30 Apr 2020 17:03:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="K/L1x2WL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 10BCB20787 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 797D38E0005; Thu, 30 Apr 2020 13:03:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7499A8E0001; Thu, 30 Apr 2020 13:03:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 610478E0005; Thu, 30 Apr 2020 13:03:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0050.hostedemail.com [216.40.44.50]) by kanga.kvack.org (Postfix) with ESMTP id 461768E0001 for ; Thu, 30 Apr 2020 13:03:05 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 06A02824805A for ; Thu, 30 Apr 2020 17:03:05 +0000 (UTC) X-FDA: 76765141530.27.night76_1ada7f78fb64c X-HE-Tag: night76_1ada7f78fb64c X-Filterd-Recvd-Size: 6380 Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Apr 2020 17:03:04 +0000 (UTC) Received: by mail-ej1-f66.google.com with SMTP id pg17so5258143ejb.9 for ; Thu, 30 Apr 2020 10:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jusIkjp3Dz4is1PZPLtprnCAT5bOhq5lF7YlVU3AWyQ=; b=K/L1x2WLoEDVhKcajWjRfk8di4UnhY9fQ857BctryF99FXnh8lvm/+FMFP7To9VzLC Oeh5Zl2gS6/3rwg+PAIfEpUDm0vFKxb3sBkuIMd/j+tdM33ErRljDKSRox35DyrhVqQy cxTvpJRHT1GSdzAq5WmfU86CiiQNmQ4AcXgOg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jusIkjp3Dz4is1PZPLtprnCAT5bOhq5lF7YlVU3AWyQ=; b=D9xu4LJflctqnucWrZ4Uigd06UU6hgBv6iAwAfNqLYqxV1eae3n89RO6AERiI6pCOn ginsdeuN0unc6tzFbe7oiwJ4PVQSYjav46vgmIbKucj3Bd9fGGUyd0xCM89zHwy9yx/N e8pA4lx1eyc6VwVMEfM+4dQI+jetlfbO7Z6eUoKYVXCnykkTeTLlcMXQdxKoYlQ96W7C 7OVqfTWKeP3DZeiEM/TunZ1ZKfnUKlE8rZWl5bhc0kaSKpKfRZGgOtc4hrNMRZe6fHqg cwWQIuv7UvlMfRABlIU1w3QgyfJ/SLA5mET0kKtbiMnG5vOoLDIQec5X9RFzWMccgV/Z 9q0g== X-Gm-Message-State: AGi0PuaoImyl956EPUG/feeAqyFrwWZgN8m8WZzFFb7aNlFlsTuM72Tr c2X36ZsJLdG5r0PqkpSHcbq9WXdvgzk= X-Google-Smtp-Source: APiQypIXLKSGQ0xA2ZfpdYpANl/fWLFkNZ77oVoaCkhf1QQ4XcRP1kNMHFifsITIyyTLwsNvD2vJMA== X-Received: by 2002:a17:907:4033:: with SMTP id nk3mr3767476ejb.273.1588266182369; Thu, 30 Apr 2020 10:03:02 -0700 (PDT) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com. [209.85.208.53]) by smtp.gmail.com with ESMTPSA id x11sm26761edi.25.2020.04.30.10.03.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 10:03:02 -0700 (PDT) Received: by mail-ed1-f53.google.com with SMTP id s10so5114473edy.9 for ; Thu, 30 Apr 2020 10:03:02 -0700 (PDT) X-Received: by 2002:a05:6512:405:: with SMTP id u5mr2728777lfk.192.1588265685113; Thu, 30 Apr 2020 09:54:45 -0700 (PDT) MIME-Version: 1.0 References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> In-Reply-To: <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> From: Linus Torvalds Date: Thu, 30 Apr 2020 09:54:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there To: Greg Ungerer Cc: Russell King - ARM Linux admin , Jann Horn , Nicolas Pitre , Andrew Morton , Christoph Hellwig , Linux Kernel Mailing List , Linux-MM , linux-fsdevel , Alexander Viro , "Eric W . Biederman" , Oleg Nesterov , Linux ARM , Mark Salter , Aurelien Jacquiot , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Rich Felker , Linux-sh list Content-Type: text/plain; charset="UTF-8" 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 Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote: > > > in load_flat_file() - which is also used to loading _libraries_. Where > > it makes no sense at all. > > I haven't looked at the shared lib support in there for a long time, > but I thought that "id" is only 0 for the actual final program. > Libraries have a slot or id number associated with them. Yes, that was my assumption, but looking at the code, it really isn't obvious that that is the case at all. 'id' gets calculated from fields that very much look like they could be zero (eg by taking the top bits from another random field). > > Most of that file goes back to pre-git days. And most of the commits > > since are not so much about binfmt_flat, as they are about cleanups or > > changes elsewhere where binfmt_flat was just a victim. > > I'll have a look at this. Thanks. > Quick hack test shows moving setup_new_exec(bprm) to be just before > install_exec_creds(bprm) works fine for the static binaries case. > Doing the flush_old_exec(bprm) there too crashed out - I'll need to > dig into that to see why. Just moving setup_new_exec() would at least allow us to then join the two together, and just say "setup_new_exec() does the credential installation too". So to some degree, that's the important one. But that flush_old_exec() does look odd in load_flat_file(). It's not like anything but executing a binary should flush the old exec. Certainly not loading a library, however odd that flat library code is. My _guess_ is that the reason for this is that "load_flat_file()" also does a lot of verification of the file and does that whole "return -ENOEXEC if the file format isn't right". So we don't want to flush the old exec before that is done, but we obviously also don't want to flush the old exec after we've actually loaded the new one into memory.. So the location of flush_old_exec() makes that kind of sense, but it would have made it better if that flat file support had a clear separation of "check the file" from "load the file". Oh well. As mentioned, the whole "at least put setup_new_exec() and install_exec_creds() together" is the bigger thing. But if it's true that nobody really uses the odd flat library support any more and there are no testers, maybe we should consider ripping it out... Linus 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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3379FC47253 for ; Thu, 30 Apr 2020 16:54:55 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 09DDE20731 for ; Thu, 30 Apr 2020 16:54:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="WzAXTAhE"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="K/L1x2WL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 09DDE20731 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pXgc0DuM+UZK806b3CTYEz9e4r7oLbLMGVPySfAsHU8=; b=WzAXTAhEtmmiF2 xPuZHGOVcFPA+s4oLpuREUVZnZNCh62qhXBpxXoS8u/xPurXXREAl4XyxiqZymgXjDdpuZjzVS7vV ouoidNz4h9oiz13n9VXdgRooeznQTB1a7QjzjAwUYZtbiIZSUpSgpKcoIADYdBa8KlbjXUDiLjvHG uvsqtpoNS9v8gfPF5m/VSRJQzI3YlH/V7WRt7d5jQnZ4sRs1QnSBzaI+/Qpt218+Td+YJpuuSB+3+ QCzgGp8U0vAPS1bxPAVNXm8mwf256XKF5h6G3SCbxaW/ofrsoTuJVYRq4GNt4fCeupa2wtFatiVuC kg9MvcuiEv3I7M9fTLKQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jUCSb-00081s-RU; Thu, 30 Apr 2020 16:54:53 +0000 Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jUCSY-00081C-O2 for linux-arm-kernel@lists.infradead.org; Thu, 30 Apr 2020 16:54:52 +0000 Received: by mail-lf1-x141.google.com with SMTP id b24so1819500lfp.7 for ; Thu, 30 Apr 2020 09:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jusIkjp3Dz4is1PZPLtprnCAT5bOhq5lF7YlVU3AWyQ=; b=K/L1x2WLoEDVhKcajWjRfk8di4UnhY9fQ857BctryF99FXnh8lvm/+FMFP7To9VzLC Oeh5Zl2gS6/3rwg+PAIfEpUDm0vFKxb3sBkuIMd/j+tdM33ErRljDKSRox35DyrhVqQy cxTvpJRHT1GSdzAq5WmfU86CiiQNmQ4AcXgOg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jusIkjp3Dz4is1PZPLtprnCAT5bOhq5lF7YlVU3AWyQ=; b=W2GYNGEyw0hwe4Tg30i+SLHT97DwDmwpib9MeVRPNH3wPUx8DcJJ+FQcu/HmjmrxoJ K9GgVyFZlQP4/n7StAc1PD7KsXQ+Fzzf9QjZPYqS3Y4ugM6a8DZEbQ06ps1eHAltd11b f3hqpC430zi8aIYi5Wn1JDVbd4FwwXebnhGN9sPcX/G0+YrkKXy+mD7gSBtvvE60jhzp wY1bht/ENvZLqSF8r4GcP6D+t6DTfbIn3zhc6S6Ppdun5FUCFX0rqqihNgwxNqd73VJZ G4NnC/9AQKjiPkHmeprYpOTbpJLriQgogJqS1bAO+KuNL0yrIe9Jo8IemVcwSLx4ahpT LGiw== X-Gm-Message-State: AGi0PuY8H1Vcw/IL0FT8VjgrKWwBxk/Urc052jvn69dL8xnJQVEtzkDj bnwISLvkIBaaURmbp42Gu8+TJo4MXAI= X-Google-Smtp-Source: APiQypJo6XVK7ThzYduWWHPNiJrZuKu37m5kv8+dchGllJm+cflrcwVapkY+5bhmKZ0bj/tcW8mWsw== X-Received: by 2002:ac2:50ce:: with SMTP id h14mr2802847lfm.76.1588265687327; Thu, 30 Apr 2020 09:54:47 -0700 (PDT) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id v2sm192087ljv.86.2020.04.30.09.54.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 09:54:46 -0700 (PDT) Received: by mail-lf1-f44.google.com with SMTP id y3so1823729lfy.1 for ; Thu, 30 Apr 2020 09:54:45 -0700 (PDT) X-Received: by 2002:a05:6512:405:: with SMTP id u5mr2728777lfk.192.1588265685113; Thu, 30 Apr 2020 09:54:45 -0700 (PDT) MIME-Version: 1.0 References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> In-Reply-To: <31196268-2ff4-7a1d-e9df-6116e92d2190@linux-m68k.org> From: Linus Torvalds Date: Thu, 30 Apr 2020 09:54:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there To: Greg Ungerer X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200430_095450_790773_9CE9882F X-CRM114-Status: GOOD ( 20.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Salter , Rich Felker , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Nicolas Pitre , Linux-sh list , Jann Horn , Linux Kernel Mailing List , Russell King - ARM Linux admin , Linux-MM , Alexander Viro , Oleg Nesterov , linux-fsdevel , Andrew Morton , Aurelien Jacquiot , Christoph Hellwig , Linux ARM , "Eric W . Biederman" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote: > > > in load_flat_file() - which is also used to loading _libraries_. Where > > it makes no sense at all. > > I haven't looked at the shared lib support in there for a long time, > but I thought that "id" is only 0 for the actual final program. > Libraries have a slot or id number associated with them. Yes, that was my assumption, but looking at the code, it really isn't obvious that that is the case at all. 'id' gets calculated from fields that very much look like they could be zero (eg by taking the top bits from another random field). > > Most of that file goes back to pre-git days. And most of the commits > > since are not so much about binfmt_flat, as they are about cleanups or > > changes elsewhere where binfmt_flat was just a victim. > > I'll have a look at this. Thanks. > Quick hack test shows moving setup_new_exec(bprm) to be just before > install_exec_creds(bprm) works fine for the static binaries case. > Doing the flush_old_exec(bprm) there too crashed out - I'll need to > dig into that to see why. Just moving setup_new_exec() would at least allow us to then join the two together, and just say "setup_new_exec() does the credential installation too". So to some degree, that's the important one. But that flush_old_exec() does look odd in load_flat_file(). It's not like anything but executing a binary should flush the old exec. Certainly not loading a library, however odd that flat library code is. My _guess_ is that the reason for this is that "load_flat_file()" also does a lot of verification of the file and does that whole "return -ENOEXEC if the file format isn't right". So we don't want to flush the old exec before that is done, but we obviously also don't want to flush the old exec after we've actually loaded the new one into memory.. So the location of flush_old_exec() makes that kind of sense, but it would have made it better if that flat file support had a clear separation of "check the file" from "load the file". Oh well. As mentioned, the whole "at least put setup_new_exec() and install_exec_creds() together" is the bigger thing. But if it's true that nobody really uses the odd flat library support any more and there are no testers, maybe we should consider ripping it out... Linus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel