From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Pitre Date: Thu, 30 Apr 2020 01:59:46 +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> In-Reply-To: <20200429215620.GM1551@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Russell King - ARM Linux admin Cc: Rich Felker , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Jann Horn , Christophe Lyon , linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, Oleg Nesterov , linux-mm@kvack.org, Alexander Viro , Mark Salter , linux-fsdevel@vger.kernel.org, Andrew Morton , Aurelien Jacquiot , Linus Torvalds , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, "Eric W . Biederman" On Wed, 29 Apr 2020, Russell King - ARM Linux admin wrote: > On Wed, Apr 29, 2020 at 11:49:49PM +0200, Jann Horn wrote: > > At the moment, we have that rather ugly mmget_still_valid() helper to > > work around : ELF core dumping > > doesn't take the mmap_sem while traversing the task's VMAs, and if > > anything (like userfaultfd) then remotely messes with the VMA tree, > > fireworks ensue. So at the moment we use mmget_still_valid() to bail > > out in any writers that might be operating on a remote mm's VMAs. > > > > With this series, I'm trying to get rid of the need for that as > > cleanly as possible. > > In particular, I want to avoid holding the mmap_sem across unbounded > > sleeps. > > > > > > Patches 1, 2 and 3 are relatively unrelated cleanups in the core > > dumping code. > > > > Patches 4 and 5 implement the main change: Instead of repeatedly > > accessing the VMA list with sleeps in between, we snapshot it at the > > start with proper locking, and then later we just use our copy of > > the VMA list. This ensures that the kernel won't crash, that VMA > > metadata in the coredump is consistent even in the presence of > > concurrent modifications, and that any virtual addresses that aren't > > being concurrently modified have their contents show up in the core > > dump properly. > > > > The disadvantage of this approach is that we need a bit more memory > > during core dumping for storing metadata about all VMAs. > > > > After this series has landed, we should be able to rip out > > mmget_still_valid(). > > > > > > Testing done so far: > > > > - Creating a simple core dump on X86-64 still works. > > - The created coredump on X86-64 opens in GDB, and both the stack and the > > exectutable look vaguely plausible. > > - 32-bit ARM compiles with FDPIC support, both with MMU and !MMU config. > > > > I'm CCing some folks from the architectures that use FDPIC in case > > anyone wants to give this a spin. > > I've never had any reason to use FDPIC, and I don't have any binaries > that would use it. Nicolas Pitre added ARM support, so I guess he > would be the one to talk to about it. (Added Nicolas.) It's been a while since I worked with it. However Christophe Lyon (in CC) added support for ARM FDPIC to mainline gcc recently, so hopefully he might still be set up and able to help. Nicolas 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=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 14393C83003 for ; Thu, 30 Apr 2020 01:59:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DC4B920757 for ; Thu, 30 Apr 2020 01:59:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="U/bgW78L"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=fluxnic.net header.i=@fluxnic.net header.b="jpEXcJur" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726550AbgD3B7w (ORCPT ); Wed, 29 Apr 2020 21:59:52 -0400 Received: from pb-smtp2.pobox.com ([64.147.108.71]:51728 "EHLO pb-smtp2.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726282AbgD3B7v (ORCPT ); Wed, 29 Apr 2020 21:59:51 -0400 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F416F4999C; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type; s=sasl; bh=ErazowRay1P/AwFSRhYIU6Y2Vtg=; b=U/bgW7 8LRuDwed7cFJI+OLHcNjS2azezYw4bDECsXxOtmXzamJa8j9tAdCdRFr37MXprd5 ErxVxpe2KVIBpAKAVf2dKTwzyPiZ3RDGm+EfMP70RzW2Zf/0ARTOupK3h0F1z+hz mQJPY4L14N4+MX2vB7h1kvD7/e18IFTZLuIv8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EA42A4999B; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fluxnic.net; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type; s=2016-12.pbsmtp; bh=OH9QgA1zs57t3X+399BRoLLVjiVfyd9x67bP0Lvx9VY=; b=jpEXcJureDScwgQSTF9eHzcwhmQuFrOHxRs892SZDNVkINIFS5TbHDpabFpo7Gs7IHlBnmskokz8D4i2YY5ViibSy+NBswTJ776BfV1BmS29V/WPbozOzfLFQDTEEXWotrT//LfOGQVTKKoMRDg2y4UW+ua6jfMPr/mLDlS+tJQ= Received: from yoda.home (unknown [24.203.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6E06D4999A; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id 91EAD2DA0A91; Wed, 29 Apr 2020 21:59:46 -0400 (EDT) Date: Wed, 29 Apr 2020 21:59:46 -0400 (EDT) From: Nicolas Pitre To: Russell King - ARM Linux admin cc: Jann Horn , Andrew Morton , Linus Torvalds , Christoph Hellwig , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Alexander Viro , "Eric W . Biederman" , Oleg Nesterov , linux-arm-kernel@lists.infradead.org, Mark Salter , Aurelien Jacquiot , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Rich Felker , linux-sh@vger.kernel.org, Christophe Lyon Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there In-Reply-To: <20200429215620.GM1551@shell.armlinux.org.uk> Message-ID: References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Pobox-Relay-ID: 44EB08B6-8A86-11EA-B6B5-D1361DBA3BAF-78420484!pb-smtp2.pobox.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 Apr 2020, Russell King - ARM Linux admin wrote: > On Wed, Apr 29, 2020 at 11:49:49PM +0200, Jann Horn wrote: > > At the moment, we have that rather ugly mmget_still_valid() helper to > > work around : ELF core dumping > > doesn't take the mmap_sem while traversing the task's VMAs, and if > > anything (like userfaultfd) then remotely messes with the VMA tree, > > fireworks ensue. So at the moment we use mmget_still_valid() to bail > > out in any writers that might be operating on a remote mm's VMAs. > > > > With this series, I'm trying to get rid of the need for that as > > cleanly as possible. > > In particular, I want to avoid holding the mmap_sem across unbounded > > sleeps. > > > > > > Patches 1, 2 and 3 are relatively unrelated cleanups in the core > > dumping code. > > > > Patches 4 and 5 implement the main change: Instead of repeatedly > > accessing the VMA list with sleeps in between, we snapshot it at the > > start with proper locking, and then later we just use our copy of > > the VMA list. This ensures that the kernel won't crash, that VMA > > metadata in the coredump is consistent even in the presence of > > concurrent modifications, and that any virtual addresses that aren't > > being concurrently modified have their contents show up in the core > > dump properly. > > > > The disadvantage of this approach is that we need a bit more memory > > during core dumping for storing metadata about all VMAs. > > > > After this series has landed, we should be able to rip out > > mmget_still_valid(). > > > > > > Testing done so far: > > > > - Creating a simple core dump on X86-64 still works. > > - The created coredump on X86-64 opens in GDB, and both the stack and the > > exectutable look vaguely plausible. > > - 32-bit ARM compiles with FDPIC support, both with MMU and !MMU config. > > > > I'm CCing some folks from the architectures that use FDPIC in case > > anyone wants to give this a spin. > > I've never had any reason to use FDPIC, and I don't have any binaries > that would use it. Nicolas Pitre added ARM support, so I guess he > would be the one to talk to about it. (Added Nicolas.) It's been a while since I worked with it. However Christophe Lyon (in CC) added support for ARM FDPIC to mainline gcc recently, so hopefully he might still be set up and able to help. Nicolas 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=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 85DC3C83003 for ; Thu, 30 Apr 2020 01:59:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1409320757 for ; Thu, 30 Apr 2020 01:59:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="U/bgW78L"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=fluxnic.net header.i=@fluxnic.net header.b="jpEXcJur" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1409320757 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fluxnic.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9548E8E0005; Wed, 29 Apr 2020 21:59:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 904A58E0001; Wed, 29 Apr 2020 21:59:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 842488E0005; Wed, 29 Apr 2020 21:59:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 6D7228E0001 for ; Wed, 29 Apr 2020 21:59:49 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3A9734DB2 for ; Thu, 30 Apr 2020 01:59:49 +0000 (UTC) X-FDA: 76762865298.30.feet91_8fe039068cb4d X-HE-Tag: feet91_8fe039068cb4d X-Filterd-Recvd-Size: 5628 Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Apr 2020 01:59:48 +0000 (UTC) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F416F4999C; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type; s=sasl; bh=ErazowRay1P/AwFSRhYIU6Y2Vtg=; b=U/bgW7 8LRuDwed7cFJI+OLHcNjS2azezYw4bDECsXxOtmXzamJa8j9tAdCdRFr37MXprd5 ErxVxpe2KVIBpAKAVf2dKTwzyPiZ3RDGm+EfMP70RzW2Zf/0ARTOupK3h0F1z+hz mQJPY4L14N4+MX2vB7h1kvD7/e18IFTZLuIv8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EA42A4999B; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fluxnic.net; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type; s=2016-12.pbsmtp; bh=OH9QgA1zs57t3X+399BRoLLVjiVfyd9x67bP0Lvx9VY=; b=jpEXcJureDScwgQSTF9eHzcwhmQuFrOHxRs892SZDNVkINIFS5TbHDpabFpo7Gs7IHlBnmskokz8D4i2YY5ViibSy+NBswTJ776BfV1BmS29V/WPbozOzfLFQDTEEXWotrT//LfOGQVTKKoMRDg2y4UW+ua6jfMPr/mLDlS+tJQ= Received: from yoda.home (unknown [24.203.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6E06D4999A; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id 91EAD2DA0A91; Wed, 29 Apr 2020 21:59:46 -0400 (EDT) Date: Wed, 29 Apr 2020 21:59:46 -0400 (EDT) From: Nicolas Pitre To: Russell King - ARM Linux admin cc: Jann Horn , Andrew Morton , Linus Torvalds , Christoph Hellwig , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Alexander Viro , "Eric W . Biederman" , Oleg Nesterov , linux-arm-kernel@lists.infradead.org, Mark Salter , Aurelien Jacquiot , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Rich Felker , linux-sh@vger.kernel.org, Christophe Lyon Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there In-Reply-To: <20200429215620.GM1551@shell.armlinux.org.uk> Message-ID: References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Pobox-Relay-ID: 44EB08B6-8A86-11EA-B6B5-D1361DBA3BAF-78420484!pb-smtp2.pobox.com 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 Wed, 29 Apr 2020, Russell King - ARM Linux admin wrote: > On Wed, Apr 29, 2020 at 11:49:49PM +0200, Jann Horn wrote: > > At the moment, we have that rather ugly mmget_still_valid() helper to > > work around : ELF core dumping > > doesn't take the mmap_sem while traversing the task's VMAs, and if > > anything (like userfaultfd) then remotely messes with the VMA tree, > > fireworks ensue. So at the moment we use mmget_still_valid() to bail > > out in any writers that might be operating on a remote mm's VMAs. > > > > With this series, I'm trying to get rid of the need for that as > > cleanly as possible. > > In particular, I want to avoid holding the mmap_sem across unbounded > > sleeps. > > > > > > Patches 1, 2 and 3 are relatively unrelated cleanups in the core > > dumping code. > > > > Patches 4 and 5 implement the main change: Instead of repeatedly > > accessing the VMA list with sleeps in between, we snapshot it at the > > start with proper locking, and then later we just use our copy of > > the VMA list. This ensures that the kernel won't crash, that VMA > > metadata in the coredump is consistent even in the presence of > > concurrent modifications, and that any virtual addresses that aren't > > being concurrently modified have their contents show up in the core > > dump properly. > > > > The disadvantage of this approach is that we need a bit more memory > > during core dumping for storing metadata about all VMAs. > > > > After this series has landed, we should be able to rip out > > mmget_still_valid(). > > > > > > Testing done so far: > > > > - Creating a simple core dump on X86-64 still works. > > - The created coredump on X86-64 opens in GDB, and both the stack and the > > exectutable look vaguely plausible. > > - 32-bit ARM compiles with FDPIC support, both with MMU and !MMU config. > > > > I'm CCing some folks from the architectures that use FDPIC in case > > anyone wants to give this a spin. > > I've never had any reason to use FDPIC, and I don't have any binaries > that would use it. Nicolas Pitre added ARM support, so I guess he > would be the one to talk to about it. (Added Nicolas.) It's been a while since I worked with it. However Christophe Lyon (in CC) added support for ARM FDPIC to mainline gcc recently, so hopefully he might still be set up and able to help. Nicolas 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=-2.3 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,USER_AGENT_SANE_1 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 C144DC83006 for ; Thu, 30 Apr 2020 01:59:54 +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 93AC720757 for ; Thu, 30 Apr 2020 01:59: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="P+/0EBdj"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="U/bgW78L"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=fluxnic.net header.i=@fluxnic.net header.b="jpEXcJur" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93AC720757 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fluxnic.net 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:MIME-Version:References:Message-ID: In-Reply-To:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0dL+7IeRcOg9DnqdtWXQqspGl56TUXc/5iIDDFqlpuM=; b=P+/0EBdj3ZMkG8 UVdfve6XtFvvC3GlfWinkIWm/u+u+jMUADhEeCv0vPIUlHfkX1ZmGBraairasBgQJqBYH5rcZ7is8 TJBpwW7AUaoDUiNt7+hWnf2LKGuDMVSEDO4gziHi9wQiOMb+VE/RtWUJGABuSpZ/iBjr4IfAzAub1 hrGuMxv0KXeZgpuXijI9Ab6iszPxzalQ2TWEmvnh5E3+OvNMrXXqnKFRJ6SX/jV/szoNUGXWQ+vLp h01/M60PnSmG+ztLpWr6rHGg8Iz1hJKnuKKFkmT5DfoHxwb/Vmf82TAvA7XhNhbZ9a7fqLIwnvA4Q 3rnQ2z2MPo34VqcDqtZw==; 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 1jTyUT-0001DQ-V6; Thu, 30 Apr 2020 01:59:53 +0000 Received: from pb-smtp2.pobox.com ([64.147.108.71]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTyUQ-0001CK-2d for linux-arm-kernel@lists.infradead.org; Thu, 30 Apr 2020 01:59:51 +0000 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F416F4999C; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type; s=sasl; bh=ErazowRay1P/AwFSRhYIU6Y2Vtg=; b=U/bgW7 8LRuDwed7cFJI+OLHcNjS2azezYw4bDECsXxOtmXzamJa8j9tAdCdRFr37MXprd5 ErxVxpe2KVIBpAKAVf2dKTwzyPiZ3RDGm+EfMP70RzW2Zf/0ARTOupK3h0F1z+hz mQJPY4L14N4+MX2vB7h1kvD7/e18IFTZLuIv8= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EA42A4999B; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fluxnic.net; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type; s=2016-12.pbsmtp; bh=OH9QgA1zs57t3X+399BRoLLVjiVfyd9x67bP0Lvx9VY=; b=jpEXcJureDScwgQSTF9eHzcwhmQuFrOHxRs892SZDNVkINIFS5TbHDpabFpo7Gs7IHlBnmskokz8D4i2YY5ViibSy+NBswTJ776BfV1BmS29V/WPbozOzfLFQDTEEXWotrT//LfOGQVTKKoMRDg2y4UW+ua6jfMPr/mLDlS+tJQ= Received: from yoda.home (unknown [24.203.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6E06D4999A; Wed, 29 Apr 2020 21:59:47 -0400 (EDT) (envelope-from nico@fluxnic.net) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id 91EAD2DA0A91; Wed, 29 Apr 2020 21:59:46 -0400 (EDT) Date: Wed, 29 Apr 2020 21:59:46 -0400 (EDT) From: Nicolas Pitre To: Russell King - ARM Linux admin Subject: Re: [PATCH v2 0/5] Fix ELF / FDPIC ELF core dumping, and use mmap_sem properly in there In-Reply-To: <20200429215620.GM1551@shell.armlinux.org.uk> Message-ID: References: <20200429214954.44866-1-jannh@google.com> <20200429215620.GM1551@shell.armlinux.org.uk> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 X-Pobox-Relay-ID: 44EB08B6-8A86-11EA-B6B5-D1361DBA3BAF-78420484!pb-smtp2.pobox.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200429_185950_275098_FDC4A701 X-CRM114-Status: GOOD ( 24.99 ) 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: Rich Felker , linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Jann Horn , Christophe Lyon , linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org, Oleg Nesterov , linux-mm@kvack.org, Alexander Viro , Mark Salter , linux-fsdevel@vger.kernel.org, Andrew Morton , Aurelien Jacquiot , Linus Torvalds , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, "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 Wed, 29 Apr 2020, Russell King - ARM Linux admin wrote: > On Wed, Apr 29, 2020 at 11:49:49PM +0200, Jann Horn wrote: > > At the moment, we have that rather ugly mmget_still_valid() helper to > > work around : ELF core dumping > > doesn't take the mmap_sem while traversing the task's VMAs, and if > > anything (like userfaultfd) then remotely messes with the VMA tree, > > fireworks ensue. So at the moment we use mmget_still_valid() to bail > > out in any writers that might be operating on a remote mm's VMAs. > > > > With this series, I'm trying to get rid of the need for that as > > cleanly as possible. > > In particular, I want to avoid holding the mmap_sem across unbounded > > sleeps. > > > > > > Patches 1, 2 and 3 are relatively unrelated cleanups in the core > > dumping code. > > > > Patches 4 and 5 implement the main change: Instead of repeatedly > > accessing the VMA list with sleeps in between, we snapshot it at the > > start with proper locking, and then later we just use our copy of > > the VMA list. This ensures that the kernel won't crash, that VMA > > metadata in the coredump is consistent even in the presence of > > concurrent modifications, and that any virtual addresses that aren't > > being concurrently modified have their contents show up in the core > > dump properly. > > > > The disadvantage of this approach is that we need a bit more memory > > during core dumping for storing metadata about all VMAs. > > > > After this series has landed, we should be able to rip out > > mmget_still_valid(). > > > > > > Testing done so far: > > > > - Creating a simple core dump on X86-64 still works. > > - The created coredump on X86-64 opens in GDB, and both the stack and the > > exectutable look vaguely plausible. > > - 32-bit ARM compiles with FDPIC support, both with MMU and !MMU config. > > > > I'm CCing some folks from the architectures that use FDPIC in case > > anyone wants to give this a spin. > > I've never had any reason to use FDPIC, and I don't have any binaries > that would use it. Nicolas Pitre added ARM support, so I guess he > would be the one to talk to about it. (Added Nicolas.) It's been a while since I worked with it. However Christophe Lyon (in CC) added support for ARM FDPIC to mainline gcc recently, so hopefully he might still be set up and able to help. Nicolas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel