From patchwork Fri Nov 22 18:55:21 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Desaulniers X-Patchwork-Id: 180073 Delivered-To: patch@linaro.org Received: by 2002:a92:38d5:0:0:0:0:0 with SMTP id g82csp632792ilf; Fri, 22 Nov 2019 10:55:29 -0800 (PST) X-Google-Smtp-Source: APXvYqwhLdINT7JF7F7CAtCmez4gaR2YP7+ObH3p8K3JzTjpgTet2eDYUak5YXKs9oRpmAt2gN0F X-Received: by 2002:a17:906:698b:: with SMTP id i11mr23304808ejr.97.1574448929422; Fri, 22 Nov 2019 10:55:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574448929; cv=none; d=google.com; s=arc-20160816; b=OFAExJ8immxFGfzb82uEAX1IrHfcNI01FF8to9K9yXKGgDPwAgmeXGpCRRtvyLrL2k yVAJW7hKml4Bw6lIfsrSPhSEiFzPmlxppjAzmVFTpnNmTgeCqmsvefQtwppFGShXwqPV R7Ko6vRrlo5vRihbCA53pEtVyWuGG8yhRddQnusLOs0L74BT1GfNmq1Ci2TJcMaJanL+ uVpB26ixXx49nO5PxJ9907GaX3oyZ7VGR6f3gslfwWBM5AqhrBZVi0gbcYSjb8SQVS/g dRZliZC+gCxyejidNul6A/sDl2Lq5HJCvfcPZAjy4jNYQSyOvrpEkF5LUdmRys9uTJO+ d+rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:from:subject:mime-version :message-id:date:dkim-signature; bh=SHVXHEGGxuqIpcBFwRHv/uk1e/S46AumK4IMAmbp/ok=; b=Fy6dWecgF2vz8O+kGGGn+S8pzC8/Kg+sWj5AnGVVl2gpBsULg07OOq/VABHU2QwxCV LZEMtI2uAlFqEePgK7A5ULwcbapQmptg/rcYdAl1WRSm1XMZz0579GGE8FRZpF/87emi bo1kes0oVCKvy90ZXFuhlUN26cVSkEMYvrvf/YBuCpNCcY3GOWRm9Gw9T2iIbJ53KefI BeyTmKiHzJH2iFxPpoIlAaTMmQfY7uP0cU5Jt+zrR7c4WdP63wqozDI4Ed1k8RCEna4C 4ijWU9awnjSVhcFDG7TZjqw2ahHffcqhcczQsoJvbToK679/PgoFW7MBdPOccWTTAwen FO5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=cpZcy7Cy; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 w12si1613017eda.292.2019.11.22.10.55.28; Fri, 22 Nov 2019 10:55:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-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=cpZcy7Cy; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-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 S1726744AbfKVSz1 (ORCPT + 15 others); Fri, 22 Nov 2019 13:55:27 -0500 Received: from mail-ua1-f73.google.com ([209.85.222.73]:43919 "EHLO mail-ua1-f73.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726980AbfKVSz1 (ORCPT ); Fri, 22 Nov 2019 13:55:27 -0500 Received: by mail-ua1-f73.google.com with SMTP id r23so1968495uam.10 for ; Fri, 22 Nov 2019 10:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=SHVXHEGGxuqIpcBFwRHv/uk1e/S46AumK4IMAmbp/ok=; b=cpZcy7CysRjVvEDBLriAw2P8/TU3cURqwBXnEv93B2t8l2xennSUdwg+CVfdB/gtFG fz8XtCFW0omCKPALWsT8iEKNvDcc2WzAa1h4wn8dmhXwwLbzyh7qRBwxDvwZ1MG4MXar TBLfcYUcznuWLGge0/XpeHXBj5Xmuy5Vdzy674qVErgGxUoHo+NNnvgQoTK4FikfXZjq B83jZXaoG++9UGZQl4PRYdgJfAV61M9O77iZe7MRy0pREg0kFwJE0FoMNy8AejyOOAWG Lpd6WqHkYN/K4PEOq2ZpUJ7Sn7oFXgWVqndd0MLXYT1vs7Sh159nYv9wwxbCIi8fjmTL ZrPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=SHVXHEGGxuqIpcBFwRHv/uk1e/S46AumK4IMAmbp/ok=; b=fpmaUFgX1s8Ev+12j90zoEQ579iDgNvuqiOdlZuCk4MlQ8qAt8LePhGPR+2gcdlWsL 7QdPkekMrQECqUd/MkF5nSqxb8SmGqME5ysit2YRSHqmmzbKUKzjiNdWgPhDm/zaGIMJ 19qu//K7RXu9DGr+TdEBioG0GNNU3/zcvVhpqrldAJVb+CbDqsd2L5yx0xxCpjQV4aAy NeaqCWEGTFfv91M+9sRF6yXlgIN1LnTDQvW9jBcsg3XHaVuCdwLzo5uNlVk5YXMlJmBI aW+Sz0Tv9H8mFMFSHTMV9TcnM2JCc3306t6jPbakTLcEpHxJbWBW5uvEjCiJYe7e9eX5 jFKQ== X-Gm-Message-State: APjAAAWu7pOICZLrZHA9ifbjFAgVw+5WOiOD3HYbxGXICrVI3/BoBJ/C 73H1NeaMuHVX83hZwGUkP0AHWFViPwJev6T7zZ0= X-Received: by 2002:a1f:e0c2:: with SMTP id x185mr10557825vkg.6.1574448926211; Fri, 22 Nov 2019 10:55:26 -0800 (PST) Date: Fri, 22 Nov 2019 10:55:21 -0800 Message-Id: <20191122185522.20582-1-ndesaulniers@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.24.0.432.g9d3f5f5b63-goog Subject: [PATCH] arm: explicitly place .fixup in .text From: Nick Desaulniers To: linux@armlinux.org.uk Cc: nico@fluxnic.net, clang-built-linux@googlegroups.com, manojgupta@google.com, natechancellor@gmail.com, Kees Cook , stable@vger.kernel.org, Nick Desaulniers , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Kees Cook There's an implicit dependency on the section ordering of the orphaned section .fixup that can break arm_copy_from_user if the linker places the .fixup section before the .text section. Since .fixup is not explicitly placed in the existing ARM linker scripts, the linker is free to order it anywhere with respect to the rest of the sections. Multiple users from different distros (Raspbian, CrOS) reported kernel panics executing seccomp() syscall with Linux kernels linked with LLD. Documentation/x86/exception-tables.rst alludes to the ordering dependency. The relevant quote: ``` NOTE: Due to the way that the exception table is built and needs to be ordered, only use exceptions for code in the .text section. Any other section will cause the exception table to not be sorted correctly, and the exceptions will fail. Things changed when 64-bit support was added to x86 Linux. Rather than double the size of the exception table by expanding the two entries from 32-bits to 64 bits, a clever trick was used to store addresses as relative offsets from the table itself. The assembly code changed from:: .long 1b,3b to: .long (from) - . .long (to) - . and the C-code that uses these values converts back to absolute addresses like this:: ex_insn_addr(const struct exception_table_entry *x) { return (unsigned long)&x->insn + x->insn; } ``` Since the addresses stored in the __ex_table are RELATIVE offsets and not ABSOLUTE addresses, ordering the fixup anywhere that's not immediately preceding .text causes the relative offset of the faulting instruction to be wrong, causing the wrong (or no) address of the fixup handler to looked up in __ex_table. x86 and arm64 place the .fixup section near the end of the .text section; follow their pattern. Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/282 Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1020633#c36 Reported-by: Manoj Gupta Reported-by: Nathan Chancellor Signed-off-by: Kees Cook Signed-off-by: Nick Desaulniers Debugged-by: Nick Desaulniers Worded-by: Nick Desaulniers Tested-by: Manoj Gupta Tested-by: Nathan Chancellor --- arch/arm/kernel/vmlinux.lds.h | 1 + 1 file changed, 1 insertion(+) -- 2.24.0.432.g9d3f5f5b63-goog diff --git a/arch/arm/kernel/vmlinux.lds.h b/arch/arm/kernel/vmlinux.lds.h index 8247bc15addc..e130f7668cf0 100644 --- a/arch/arm/kernel/vmlinux.lds.h +++ b/arch/arm/kernel/vmlinux.lds.h @@ -74,6 +74,7 @@ LOCK_TEXT \ HYPERVISOR_TEXT \ KPROBES_TEXT \ + *(.fixup) \ *(.gnu.warning) \ *(.glue_7) \ *(.glue_7t) \