Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp147390pxu; Tue, 6 Oct 2020 22:15:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzvl/xUc0ZZNv1bsAifw4aA/gEPEqmhZkPf/QUFuMI5CBM1I4r5BpOusVPv6xnydIS1fHKs X-Received: by 2002:a17:906:3a8c:: with SMTP id y12mr1457815ejd.531.1602047728312; Tue, 06 Oct 2020 22:15:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602047728; cv=none; d=google.com; s=arc-20160816; b=Ei2h+A6reYyFhsZTOs+BEk37eSKeEgHKMVzwt3Bu/IdOZGDjfEXRhYm7o02/Hy2ATP ZQUopsuWdkNL+eEJIVxFzILwYlsFFIQdI6Giz8om9JfHca/DyHZB3yjKrt5rMeV46lqe OpIKBrXVxClFjUcZiuE1ytt5kyG5NXFDSvP7162AK12b1c9Yv/clCl0x18HLLLKq6E9h s2m9mTl1BJH3pog0mU8Eaz8MJbneSEtYi8e2B/tNQKaI07J3vWk9/aQvTPVbWQ3XH8ui pPOZuMUNtfy5vzkJj36DEvaHcgYE5TCfn4VY+guo6oemiUvX8lkUwnF6cMvCE4A2hSfX /89A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=Y42f+xCeFC9aJfaprUfLKsV1W6cjiDKd4zVBYm3so2c=; b=xF8ZKcs0KZvCHJIP4u8i2rS1AQ8x4nIm5ujWCLrQErj31zvAz7PzlYrdVKM+B3AS8L ztJyqT4x19PNWtuWiVlWtfjmeFzGv8tlYJNwI4/ic/B0v9kukQojE30g38hEDyps1SSe 4SE5hMYDXOuvry0xq0EH85+Hvuxr7pH+EUZas6Ws81vVJN/VvCQ+4/ng17LVALTFgnbU RlEO6l0huABr4oNJ7fmMRmK//2MD/aSty04BZaVwG0o4PlWuEnwciao5LrxkhjGVGj0u j8sMxJifuKGi6CpyFSbhscyMaOUxVtoszh2kQA2e4EhNpsCcSojXZIHsGcAw0BHwrdMd k+iQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Am626B1m; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g10si745890edv.314.2020.10.06.22.15.04; Tue, 06 Oct 2020 22:15:28 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=Am626B1m; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726157AbgJGEMQ (ORCPT + 99 others); Wed, 7 Oct 2020 00:12:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725970AbgJGEMQ (ORCPT ); Wed, 7 Oct 2020 00:12:16 -0400 Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00EDAC061755 for ; Tue, 6 Oct 2020 21:12:15 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id t23so2249385pji.0 for ; Tue, 06 Oct 2020 21:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=Y42f+xCeFC9aJfaprUfLKsV1W6cjiDKd4zVBYm3so2c=; b=Am626B1mMSzKkJtKZO1KtVxoCrwhVXv6gfab3stoZ4ewy7b5+MYDP5R7eYl4JXL9kX ngSMaYqPVKvRv6wfttCJyW7VySrZdpDbLVd7OXy+XZCkdwvcmrH1JLH8ZQ0zqNwHMdhZ RZ3ankVeIu7omdFnqWFsJolMHytMcIUGg66DgJJxck6zBkvtdO8i2MrZAocOAIq3aHsp 5iLjQ/pLIF+y0LHaRinPO/bNl9vZoIsTNCOKSfB3ekqC+P+gxY4eSuLt5B6wI3DOSxb0 oXGMvUdklTynf3UE5QGClSGXUMnp/GW7uNrd+7RMirJIs1rUp948JKc47+jePxPQJnkc 1E9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=Y42f+xCeFC9aJfaprUfLKsV1W6cjiDKd4zVBYm3so2c=; b=oyUiG2U9oMPnMUlCxkSMeCX0SEVFIcGO7G87q/fCGltzq9r+W4bsUV/5KYdRchhAhQ vZHOz1HXzZD/CxgNuuXz1pY45h0vOlYljZuy+VUGJL2vVk1g//NUc+mntBXWDBg4beyz VuWWKyHdrdRtcjWk9r3cuhL9XWj1FO8xDU4MOjns69PAmlg4Tf7CIjQwTO/EGXhdy9Du cDyjCCkhM1bb9j8ttDQdUuu2v+OLP3G2PuL888Z181c/8zxZjHx8BjdpmMSgFRUD65Mb d/WSqp0c8Oy4cXEAdLSjKBk61VkQfpaQ6/8ekZD9/8p130N1C7rl2+2ytIa9iIhTL/VX h+1g== X-Gm-Message-State: AOAM533PWMT2uGXCa89BD5AoysPftkSjrzahx07REgluMlHtWRIJbLbG VF6mYN1l3NkD/G3Xe1UBHIjL3FNE0ht9Ng== X-Received: by 2002:a17:90b:698:: with SMTP id m24mr1227870pjz.154.1602043935036; Tue, 06 Oct 2020 21:12:15 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id h9sm810241pgk.52.2020.10.06.21.12.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2020 21:12:14 -0700 (PDT) Date: Tue, 06 Oct 2020 21:12:14 -0700 (PDT) X-Google-Original-Date: Tue, 06 Oct 2020 20:22:44 PDT (-0700) Subject: Re: [PATCH] riscv: Fixup bootup failure with HARDENED_USERCOPY In-Reply-To: <1602002973-92934-1-git-send-email-guoren@kernel.org> CC: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, guoren@linux.alibaba.com, atishp@atishpatra.org, schwab@linux-m68k.org From: Palmer Dabbelt To: guoren@kernel.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 06 Oct 2020 09:49:33 PDT (-0700), guoren@kernel.org wrote: > From: Guo Ren > > As Aurelien has reported: > > [ 3.484586] AppArmor: AppArmor sha1 policy hashing enabled > [ 4.749835] Freeing unused kernel memory: 492K > [ 4.752017] Run /init as init process > [ 4.753571] usercopy: Kernel memory overwrite attempt detected to kernel text (offset 507879, size 11)! > [ 4.754838] ------------[ cut here ]------------ > [ 4.755651] kernel BUG at mm/usercopy.c:99! > [ 4.756445] Kernel BUG [#1] > [ 4.756815] Modules linked in: > [ 4.757542] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.8.0-1-riscv64 #1 Debian 5.8.7-1 > [ 4.758372] epc: ffffffe0003b5120 ra : ffffffe0003b5120 sp : ffffffe07f783ca0 > [ 4.758960] gp : ffffffe000cc7230 tp : ffffffe07f77cec0 t0 : ffffffe000cdafc0 > [ 4.759772] t1 : 0000000000000064 t2 : 0000000000000000 s0 : ffffffe07f783cf0 > [ 4.760534] s1 : ffffffe00095d780 a0 : 000000000000005b a1 : 0000000000000020 > [ 4.761309] a2 : 0000000000000005 a3 : 0000000000000000 a4 : ffffffe000c1f340 > [ 4.761848] a5 : ffffffe000c1f340 a6 : 0000000000000000 a7 : 0000000000000087 > [ 4.762684] s2 : ffffffe000941848 s3 : 000000000007bfe7 s4 : 000000000000000b > [ 4.763500] s5 : 0000000000000000 s6 : ffffffe00091cc00 s7 : fffffffffffff000 > [ 4.764376] s8 : 0000003ffffff000 s9 : ffffffe0769f3200 s10: 000000000000000b > [ 4.765208] s11: ffffffe07d548c40 t3 : 0000000000000000 t4 : 000000000001dcd0 > [ 4.766059] t5 : ffffffe000cc8510 t6 : ffffffe000cd64aa > [ 4.766712] status: 0000000000000120 badaddr: 0000000000000000 cause: 0000000000000003 > [ 4.768308] ---[ end trace 1f8e733e834d4c3e ]--- > [ 4.769129] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b > [ 4.770070] SMP: stopping secondary CPUs > [ 4.771110] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- > > Above failure is relate to commit: a0fa4027dc911 (riscv: Fixup That commit isn't in Linus' tree (at least, as far as I see it). I have 6184358da000 ("riscv: Fixup static_obj() fail"), so I'm going to fix that -- in fact, I'm going to essentially just replace most of this rationale with what I wrote up in my revert as this is all a bit too long for a commit message. I was kind of worried the initdata move was a bit too risky, but after reading the users of __init_{begin,end} I think it's safe. Here's what I ended up with on fixes. Thanks! commit 84814460eef9af0fb56a4698341c9cb7996a6312 (HEAD -> fixes, riscv/fixes) gpg: Signature made Tue 06 Oct 2020 09:11:35 PM PDT gpg: using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889 gpg: issuer "palmer@dabbelt.com" gpg: Good signature from "Palmer Dabbelt " [ultimate] gpg: aka "Palmer Dabbelt " [ultimate] Author: Guo Ren Date: Tue Oct 6 16:49:33 2020 +0000 riscv: Fixup bootup failure with HARDENED_USERCOPY 6184358da000 ("riscv: Fixup static_obj() fail") attempted to elide a lockdep failure by rearranging our kernel image to place all initdata within [_stext, _end], thus triggering lockdep to treat these as static objects. These objects are released and eventually reallocated, causing check_kernel_text_object() to trigger a BUG(). This backs out the change to make [_stext, _end] all-encompassing, instead just moving initdata. This results in initdata being outside of [__init_begin, __init_end], which means initdata can't be freed. Link: https://lore.kernel.org/linux-riscv/1593266228-61125-1-git-send-email-guoren@kernel.org/T/#t Signed-off-by: Guo Ren Reported-by: Aurelien Jarno Tested-by: Aurelien Jarno [Palmer: Clean up commit text] Signed-off-by: Palmer Dabbelt > static_obj() fail). When we expand static_obj include INIT_DATA, > we also include INIT_TEXT into usercopy check kernel text: > > /* Is this address range in the kernel text area? */ > static inline void check_kernel_text_object(const unsigned long ptr, > unsigned long n, bool to_user) > { > unsigned long textlow = (unsigned long)_stext; > unsigned long texthigh = (unsigned long)_etext; > unsigned long textlow_linear, texthigh_linear; > > if (overlaps(ptr, n, textlow, texthigh)) > usercopy_abort("kernel text", NULL, to_user, ptr - textlow, n); > > When INIT_TEXT/DATA are freed, new allocation will reuse these > memory and overlaps check will be triggered. > > The patch met static_obj and check_kernel_text_object requirements. > > Link: https://lore.kernel.org/linux-riscv/1593266228-61125-1-git-send-email-guoren@kernel.org/T/#t > Signed-off-by: Guo Ren > Reported-by: Aurelien Jarno > Tested-by: Aurelien Jarno > Cc: Palmer Dabbelt > Cc: Atish Patra > Cc: Andreas Schwab > --- > arch/riscv/kernel/vmlinux.lds.S | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S > index f3586e3..34d00d9 100644 > --- a/arch/riscv/kernel/vmlinux.lds.S > +++ b/arch/riscv/kernel/vmlinux.lds.S > @@ -22,13 +22,11 @@ SECTIONS > /* Beginning of code and text segment */ > . = LOAD_OFFSET; > _start = .; > - _stext = .; > HEAD_TEXT_SECTION > . = ALIGN(PAGE_SIZE); > > __init_begin = .; > INIT_TEXT_SECTION(PAGE_SIZE) > - INIT_DATA_SECTION(16) > . = ALIGN(8); > __soc_early_init_table : { > __soc_early_init_table_start = .; > @@ -55,6 +53,7 @@ SECTIONS > . = ALIGN(SECTION_ALIGN); > .text : { > _text = .; > + _stext = .; > TEXT_TEXT > SCHED_TEXT > CPUIDLE_TEXT > @@ -67,6 +66,8 @@ SECTIONS > _etext = .; > } > > + INIT_DATA_SECTION(16) > + > /* Start of data section */ > _sdata = .; > RO_DATA(SECTION_ALIGN)