Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1771017pxf; Fri, 19 Mar 2021 15:50:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNoieFVBe9TCQZEUfL4AlKEj69YtoEWe8qWK3vRmarWtDCEEqt677435QFb63m4ROaUq2g X-Received: by 2002:a05:6402:46:: with SMTP id f6mr12410309edu.252.1616194235987; Fri, 19 Mar 2021 15:50:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616194235; cv=none; d=google.com; s=arc-20160816; b=epQdrCy589qJ+55C6XMClxksIcBD6iYDXMem6D1wPC09s8uc9M3nuh1REPp+lXVmNu z+u0l6hoJDk9dJekWngrLj1L+KyPOd1K1KCgPWMw1fCaU+qI8jMmuW8tUEedEstiGxUh t6Vm9V3tiWn9b3IThz51iDejEj2t7BXFgCbPOkmy5I+fXi+RDpavAjPif2dCbJ6JuxdV saRmtvGXdT8HkFODqm2u7G6FxHo0r0XR+1u/Z/+VwRJlz6krDjYZUSa22EHMDmiOyqze pI2vw06Y3mlca5hgMZJGIk5ZbDJAqzaAeM32qsosGh2QkqyRzxl458gqgNa8iB3topzm jTig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=0Ja0Bm0pbGPbVCQFMQ5kja3rpS5JFuQnqh3OEFTkD4Q=; b=D1fHB4JoxaLZ56Yzn93O2t024NT2tkHWfw01CcIBcOPIyp32bSbiRFUIfIAum8Y4RK qyY/mV1QTrL1EkaQC8DhudaZzUp6qnC/qOohsnHr52M8km1IZ3U5+6cxr3lLzekH7KHN KU++WAYQujKCbuXX/Ef+D5axLrdUBkFWlqshmnbK+6hwvyuCdbkrJQVBQAxUR83A9Pd7 tkyL1G3L2JdAGPTXlfSLSSLhEXyEisNZTvtn7aKPfP9lvFjX5LwJT0Pt6B6F2+Y7fg6x Vx0ssETVT3wOjM8pf4kqeuJF8Uqys/W5P17HAlYhxlnCgF6TPi6Sc0c1qdoDwIwvonVq JKJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="PoDC/F7a"; 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=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lc20si5491544ejb.492.2021.03.19.15.50.12; Fri, 19 Mar 2021 15:50:35 -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=@chromium.org header.s=google header.b="PoDC/F7a"; 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=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230092AbhCSWs7 (ORCPT + 99 others); Fri, 19 Mar 2021 18:48:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50424 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230281AbhCSWsy (ORCPT ); Fri, 19 Mar 2021 18:48:54 -0400 Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2B87C061764 for ; Fri, 19 Mar 2021 15:48:53 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id l13so4326436vst.8 for ; Fri, 19 Mar 2021 15:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0Ja0Bm0pbGPbVCQFMQ5kja3rpS5JFuQnqh3OEFTkD4Q=; b=PoDC/F7a+9JZAGRETtRCTuh/CByXpenl8koD2/6Hh5xX7JZwYLzkYFLgq5yj4vnUUe Wj40+WfDascmSBDQLbtwgrrHUgKOS2DLakB95E0WOZRlG7PoOqcGWoIt00uy7pLQB8C+ jqKXsgXWkQYjCoc8G54zX5rvXpYIPZ5us1Fk4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0Ja0Bm0pbGPbVCQFMQ5kja3rpS5JFuQnqh3OEFTkD4Q=; b=FgTCQii1oE+1vfchXXfJk++udcmMRL0JFCe1EiXUc9y3Vtno6Jv50zqxFJ/qsZuefa 9lAQy2OCjcpCnZCs6nzvXRri3L1BrWdWzsaJlfqnFB2COSgtUKCaS3KCiliw14KUBING nBFFl0w6ZPo5TlLmCMO3xTPYtjOcsOB8zVdhwCc+R85OBj+RvMMJzVurXBHQqOCBwWGy jTLpNuojvngUjRdRQgWiORcMNGsXrCyPBzm++I+nuzPgk8RH3psGTQRvGysk20zMbJz4 0fwaJW9ZWRoqbL+eC51xwYu/HKbZGG7tlKN5nxKFk0t5arbtbTlCRZGxSD5/3i0ffbT1 x5mw== X-Gm-Message-State: AOAM533wV14nLckzptQJCJ/bdGWuwqioW2z1E0q/XyAzoKOVYuTEqYjT YKpy4de/AqAMMlfn9hl/9yrrvdZM90V9QXGeMJUtfw== X-Received: by 2002:a05:6102:3a06:: with SMTP id b6mr4437876vsu.21.1616194132651; Fri, 19 Mar 2021 15:48:52 -0700 (PDT) MIME-Version: 1.0 References: <20210318235416.794798-1-drinkcat@chromium.org> <20210319075410.for-stable-4.19.1.I222f801866f71be9f7d85e5b10665cd4506d78ec@changeid> In-Reply-To: From: Nicolas Boichat Date: Sat, 20 Mar 2021 06:48:41 +0800 Message-ID: Subject: Re: [for-stable-4.19 PATCH 1/2] vmlinux.lds.h: Create section for protection against instrumentation To: Greg Kroah-Hartman Cc: Alexandre Chartre , stable , Thomas Gleixner , Peter Zijlstra , Arnd Bergmann , Benjamin Herrenschmidt , Christopher Li , Daniel Axtens , Masahiro Yamada , Michael Ellerman , Michal Marek , "Naveen N. Rao" , Nicholas Piggin , Paul Mackerras , Sasha Levin , linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org, lkml , linux-sparse@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Guenter Roeck Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 19, 2021 at 7:55 PM Greg Kroah-Hartman wrote: > > On Fri, Mar 19, 2021 at 12:20:22PM +0100, Alexandre Chartre wrote: > > > > On 3/19/21 11:39 AM, Greg Kroah-Hartman wrote: > > > On Fri, Mar 19, 2021 at 07:54:15AM +0800, Nicolas Boichat wrote: > > > > From: Thomas Gleixner > > > > > > > > commit 6553896666433e7efec589838b400a2a652b3ffa upstream. > > > > > > > > Some code pathes, especially the low level entry code, must be prot= ected > > > > against instrumentation for various reasons: > > > > > > > > - Low level entry code can be a fragile beast, especially on x86. > > > > > > > > - With NO_HZ_FULL RCU state needs to be established before using = it. > > > > > > > > Having a dedicated section for such code allows to validate with to= oling > > > > that no unsafe functions are invoked. > > > > > > > > Add the .noinstr.text section and the noinstr attribute to mark > > > > functions. noinstr implies notrace. Kprobes will gain a section che= ck > > > > later. > > > > > > > > Provide also a set of markers: instrumentation_begin()/end() > > > > > > > > These are used to mark code inside a noinstr function which calls > > > > into regular instrumentable text section as safe. > > > > > > > > The instrumentation markers are only active when CONFIG_DEBUG_ENTRY= is > > > > enabled as the end marker emits a NOP to prevent the compiler from = merging > > > > the annotation points. This means the objtool verification requires= a > > > > kernel compiled with this option. > > > > > > > > Signed-off-by: Thomas Gleixner > > > > Reviewed-by: Alexandre Chartre > > > > Acked-by: Peter Zijlstra > > > > Link: https://lkml.kernel.org/r/20200505134100.075416272@linutronix= .de > > > > > > > > [Nicolas: context conflicts in: > > > > arch/powerpc/kernel/vmlinux.lds.S > > > > include/asm-generic/vmlinux.lds.h > > > > include/linux/compiler.h > > > > include/linux/compiler_types.h] > > > > Signed-off-by: Nicolas Boichat > > > > > > Did you build this on x86? > > > > > > I get the following build error: > > > > > > ld:./arch/x86/kernel/vmlinux.lds:20: syntax error > > > > > > And that line looks like: > > > > > > . =3D ALIGN(8); *(.text.hot .text.hot.*) *(.text .text.fixup) *(.te= xt.unlikely .text.unlikely.*) *(.text.unknown .text.unknown.*) . =3D ALIGN(= 8); __noinstr_text_start =3D .; *(.__attribute__((noinline)) __attribute__(= (no_instrument_function)) __attribute((__section__(".noinstr.text"))).text)= __noinstr_text_end =3D .; *(.text..refcount) *(.ref.text) *(.meminit.text*= ) *(.memexit.text*) > > > > > > > In the NOINSTR_TEXT macro, noinstr is expanded with the value of the no= instr > > macro from linux/compiler_types.h while it shouldn't. > > > > The problem is possibly that the noinstr macro is defined for assembly.= Make > > sure that the macro is not defined for assembly e.g.: > > > > #ifndef __ASSEMBLY__ > > > > /* Section for code which can't be instrumented at all */ > > #define noinstr = \ > > noinline notrace __attribute((__section__(".noinstr.text"))) > > > > #endif > > This implies that the backport is incorrect, so I'll wait for an updated > version... Yep, sorry about that. I did test on ARM64 only and these patches happily went through our Chrome OS CQ (we don't have gcc coverage though). Guenter has a fixup here with explanation: https://crrev.com/c/2776332, I'll look carefully and resubmit. Thanks, > thanks, > > greg k-h