can't find file to patch at input line 109 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |From patchwork Mon Nov 15 15:27:12 2021 |Content-Type: text/plain; charset="utf-8" |MIME-Version: 1.0 |Content-Transfer-Encoding: 7bit |X-Patchwork-Submitter: Mark Brown |X-Patchwork-Id: 47681 |Return-Path: |X-Original-To: patchwork@sourceware.org |Delivered-To: patchwork@sourceware.org |Received: from server2.sourceware.org (localhost [IPv6:::1]) | by sourceware.org (Postfix) with ESMTP id 1E5883857C4F | for ; Mon, 15 Nov 2021 15:29:12 +0000 (GMT) |DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1E5883857C4F |DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; | s=default; t=1636990152; | bh=RamjuPvDwjnvIqPutwWNXGWaG2c/MDVRexA3t9Zn3f4=; | h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: | List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: | From; | b=sPDnTROwaYLI5H/eP7p7+I+sm4MaFKpydj9X6Qbkp5l+PebNYRks//zELVH6DDOgV | djXxVaRGm644b1Iq6w8u8Tv0GbNbGRDeLWh8MaT7sZR0hpKBzPCA4wMDdBmVUBMWd9 | 3SgzF6KU4WtCbiC7Qj8e4xQoPNhRd22ILnN7p6rU= |X-Original-To: libc-alpha@sourceware.org |Delivered-To: libc-alpha@sourceware.org |Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) | by sourceware.org (Postfix) with ESMTPS id E47463858027 | for ; Mon, 15 Nov 2021 15:27:29 +0000 (GMT) |DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E47463858027 |Received: by mail.kernel.org (Postfix) with ESMTPSA id DA32461AA5; | Mon, 15 Nov 2021 15:27:26 +0000 (UTC) |To: Catalin Marinas , | Will Deacon |Subject: [PATCH v7 2/4] arm64: Enable BTI for main executable as well as the | interpreter |Date: Mon, 15 Nov 2021 15:27:12 +0000 |Message-Id: <20211115152714.3205552-3-broonie@kernel.org> |X-Mailer: git-send-email 2.30.2 |In-Reply-To: <20211115152714.3205552-1-broonie@kernel.org> |References: <20211115152714.3205552-1-broonie@kernel.org> |MIME-Version: 1.0 |X-Developer-Signature: v=1; a=openpgp-sha256; l=3271; h=from:subject; | bh=D7YPrbFYzpSg2f9JH5grl1r/4F+OGQUL22/T47/t85M=; | b=owGbwMvMwMWocq27KDak/QLjabUkhsRJNT57ChhYpK70qFaudWLbdspCVSrVxKboWkOE7zn1O7YS | OXmdjMYsDIxcDLJiiixrn2WsSg+X2Dr/0fxXMINYmUCmMHBxCsBEWqzZ/ymKHBIP4PrmsU9ClGFxs+ | tst+8RMlO49jpMfpb7U+Nh1DS7PfxtW469eHh85dbTBmaOTyqj+nZ807XbbGil3ugxb750SLGcaV+/ | 8CE/gx33cxPeHzfb0Rj/tdlcNTDVslVWcdlU8dDlyoez+iu8Je5nbRWyF+nYnfFVrJ2tSvvGg+oE9g | WGO6WuNvNc+rAnNnPLwm7bEv9llxemHDP96POoeomD3gzzB36HrAsfiZwSnemwJYYvulave5nHEWau | TVt5fwV7Vz5KjPAv+bz754QnbE9vlk9LMmt8YZbmG2t6RvyKucKuLMsMqaJP9kvKS7a0bZ00UzRpz4 | /2O3lTO96X317jfsci3k+iVXEyAA== |X-Developer-Key: i=broonie@kernel.org; a=openpgp; | fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB |X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, | DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, | SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 |X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on | server2.sourceware.org |X-BeenThere: libc-alpha@sourceware.org |X-Mailman-Version: 2.1.29 |Precedence: list |List-Id: Libc-alpha mailing list |List-Unsubscribe: , | |List-Archive: |List-Post: |List-Help: |List-Subscribe: , | |X-Patchwork-Original-From: Mark Brown via Libc-alpha | |From: Mark Brown |Reply-To: Mark Brown |Cc: linux-arch@vger.kernel.org, Yu-cheng Yu , | libc-alpha@sourceware.org, Szabolcs Nagy , | Jeremy Linton , Mark Brown , | Dave Martin , linux-arm-kernel@lists.infradead.org |Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org |Sender: "Libc-alpha" | | |Currently for dynamically linked ELF executables we only enable BTI for |the interpreter, expecting the interpreter to do this for the main |executable. This is a bit inconsistent since we do map main executable and |is causing issues with systemd's MemoryDenyWriteExecute feature which is |implemented using a seccomp filter which prevents setting PROT_EXEC on |already mapped memory and lacks the context to be able to detect that |memory is already mapped with PROT_EXEC. | |Resolve this by checking the BTI property for the main executable and |enabling BTI if it is present when doing the initial mapping. This does |mean that we may get more code with BTI enabled if running on a system |without BTI support in the dynamic linker, this is expected to be a safe |configuration and testing seems to confirm that. It also reduces the |flexibility userspace has to disable BTI but it is expected that for cases |where there are problems which require BTI to be disabled it is more likely |that it will need to be disabled on a system level. | |Signed-off-by: Mark Brown |Reviewed-by: Dave Martin |Tested-by: Jeremy Linton |--- | arch/arm64/include/asm/elf.h | 15 ++++++++++++--- | arch/arm64/kernel/process.c | 14 ++------------ | 2 files changed, 14 insertions(+), 15 deletions(-) | |diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h |index 5cc002376abe..c4aa60db76a4 100644 |--- a/arch/arm64/include/asm/elf.h |+++ b/arch/arm64/include/asm/elf.h -------------------------- No file to patch. Skipping patch. 2 out of 2 hunks ignored can't find file to patch at input line 148 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c |index aacf2f5559a8..a6b6b587cab9 100644 |--- a/arch/arm64/kernel/process.c |+++ b/arch/arm64/kernel/process.c -------------------------- No file to patch. Skipping patch. 1 out of 1 hunk ignored