Received: by 2002:a17:90b:8d0:0:0:0:0 with SMTP id ds16csp5062575pjb; Mon, 27 Jul 2020 11:58:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0EMImO3cbkEEMUVhjkG/UTO1LkRhv1y0MX61SJv4jvebYDJsLpc2aBYL+mREf5gKMd126 X-Received: by 2002:aa7:dd14:: with SMTP id i20mr23529765edv.41.1595876288483; Mon, 27 Jul 2020 11:58:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595876288; cv=none; d=google.com; s=arc-20160816; b=HbbcmqzKlWJn1xgmMIJ/y0eLF18VBX0LtM94gwHr6zrbFCr8l7xH0EClc6THw+Pyin zQzkXoO1vg3HXe9hspNpRpqzoYycAs4Cb+6KiVmtOnVvs4RQA2q4id8CI0o64dUeAc58 Ja42/mqbR9vvrqg+eKAcunsACnKgTS3hxp+tCpLSzdBnfrGwx3Vv73PlC0NBDOxdr5op K9sFQoQBcyvSCcj0TO4myapxXZcABll14GvZEjtzZtQSYBhty72QMQumbT2PeSHutCVw OyF9/MxwYb8qqrnxKrFquIm3LqkiI5gPDr/6WonfmQ35O1w9I/msSBjdApLSxKuRp3kw JWXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from; bh=Kh8tMA3yZTOzc8FZMuhhJiK8R6OsH6/0+m29g12K7uY=; b=hfkBTSY/yuC5Y03zuiLCpEWqPXQQiLSLltXsQdvIz4kVtCOe1djxaxlTOXzhhSHnIa 6WYEHd04YaUR2h680VCqteog/JBoO2ndsMva8W8ok2YNx44aVJpqsiOcvUm0aZCHDVoN xwE6Kurd+SP23s3jKCQdwBj2qHYjyIfc+8lkqduhiuwVCERvqdDdHnszTQ9QaxeEdxXC BVWLrjLm+7dcn6bJ66O3ta82oXpPakaJx017CR3U29PpBbUHt5UdJt1rv/DtA4wnjgom Ta4dD4kBFaFMEhM5JKOEAL+QrVG4xWcBCFQLJ6ysWy6dwqyDbP2E7ViNGFPM5lbn398l FBIg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z13si6050541ejc.295.2020.07.27.11.57.46; Mon, 27 Jul 2020 11:58:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728908AbgG0RLR (ORCPT + 99 others); Mon, 27 Jul 2020 13:11:17 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:49706 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728712AbgG0RLQ (ORCPT ); Mon, 27 Jul 2020 13:11:16 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k06eR-00019I-TD; Mon, 27 Jul 2020 11:10:59 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1k06eQ-0006Sd-Sl; Mon, 27 Jul 2020 11:10:59 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Anthony Yznaga Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, mhocko@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, arnd@arndb.de, keescook@chromium.org, gerg@linux-m68k.org, ktkhai@virtuozzo.com, christian.brauner@ubuntu.com, peterz@infradead.org, esyr@redhat.com, jgg@ziepe.ca, christian@kellner.me, areber@redhat.com, cyphar@cyphar.com, steven.sistare@oracle.com References: <1595869887-23307-1-git-send-email-anthony.yznaga@oracle.com> Date: Mon, 27 Jul 2020 12:07:53 -0500 In-Reply-To: <1595869887-23307-1-git-send-email-anthony.yznaga@oracle.com> (Anthony Yznaga's message of "Mon, 27 Jul 2020 10:11:22 -0700") Message-ID: <87pn8glwd2.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1k06eQ-0006Sd-Sl;;;mid=<87pn8glwd2.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+gamZ8xvQHBIctI0vkZJ1IBG5dzD/MEwA= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa07.xmission.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,XMNoVowels autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4980] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 0; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: ; sa07 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Anthony Yznaga X-Spam-Relay-Country: X-Spam-Timing: total 602 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 11 (1.8%), b_tie_ro: 10 (1.6%), parse: 1.04 (0.2%), extract_message_metadata: 4.7 (0.8%), get_uri_detail_list: 2.3 (0.4%), tests_pri_-1000: 3.9 (0.6%), tests_pri_-950: 1.26 (0.2%), tests_pri_-900: 1.07 (0.2%), tests_pri_-90: 198 (32.8%), check_bayes: 196 (32.5%), b_tokenize: 9 (1.5%), b_tok_get_all: 10 (1.7%), b_comp_prob: 3.2 (0.5%), b_tok_touch_all: 169 (28.1%), b_finish: 1.03 (0.2%), tests_pri_0: 361 (59.9%), check_dkim_signature: 0.81 (0.1%), check_dkim_adsp: 2.6 (0.4%), poll_dns_idle: 0.26 (0.0%), tests_pri_10: 2.4 (0.4%), tests_pri_500: 9 (1.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC PATCH 0/5] madvise MADV_DOEXEC X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Anthony Yznaga writes: > This patchset adds support for preserving an anonymous memory range across > exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for > sharing memory in this manner, as opposed to re-attaching to a named shared > memory segment, is to ensure it is mapped at the same virtual address in > the new process as it was in the old one. An intended use for this is to > preserve guest memory for guests using vfio while qemu exec's an updated > version of itself. By ensuring the memory is preserved at a fixed address, > vfio mappings and their associated kernel data structures can remain valid. > In addition, for the qemu use case, qemu instances that back guest RAM with > anonymous memory can be updated. What is wrong with using a file descriptor to a possibly deleted file and re-mmaping it? There is already MAP_FIXED that allows you to ensure you have the same address. I think all it would take would be a small protocol from one version to the next to say map file descriptor #N and address #A. Something easily passed on the command line. There is just enough complexity in exec currently that our implementation of exec is already teetering. So if we could use existing mechanisms it would be good. And I don't see why this version of sharing a mmap area would be particularly general. I do imagine that being able to force a mmap area into a setuid executable would be a fun attack vector. Perhaps I missed this in my skim of these patches but I did not see anything that guarded this feature against an exec that changes an applications privileges. Eric > Patches 1 and 2 ensure that loading of ELF load segments does not silently > clobber existing VMAS, and remove assumptions that the stack is the only > VMA in the mm when the stack is set up. Patch 1 re-introduces the use of > MAP_FIXED_NOREPLACE to load ELF binaries that addresses the previous issues > and could be considered on its own. > > Patches 3, 4, and 5 introduce the feature and an opt-in method for its use > using an ELF note. > > Anthony Yznaga (5): > elf: reintroduce using MAP_FIXED_NOREPLACE for elf executable mappings > mm: do not assume only the stack vma exists in setup_arg_pages() > mm: introduce VM_EXEC_KEEP > exec, elf: require opt-in for accepting preserved mem > mm: introduce MADV_DOEXEC > > arch/x86/Kconfig | 1 + > fs/binfmt_elf.c | 196 +++++++++++++++++++++++++-------- > fs/exec.c | 33 +++++- > include/linux/binfmts.h | 7 +- > include/linux/mm.h | 5 + > include/uapi/asm-generic/mman-common.h | 3 + > kernel/fork.c | 2 +- > mm/madvise.c | 25 +++++ > mm/mmap.c | 47 ++++++++ > 9 files changed, 266 insertions(+), 53 deletions(-)