Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp1196563rwi; Wed, 26 Oct 2022 12:00:12 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7i23qERuXpGx3We8PU4NDfP20Y9pGg0MFerIbKhFzYgVbRK7g5EWr/JO20k2rpi1gjfBPM X-Received: by 2002:a05:6a00:1412:b0:557:d887:2025 with SMTP id l18-20020a056a00141200b00557d8872025mr45235902pfu.39.1666810801067; Wed, 26 Oct 2022 12:00:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666810801; cv=none; d=google.com; s=arc-20160816; b=BfXLceg+C0Joj70m+A6xAebO7KL6k9aFp2PHxKiSIo4Qj0O913Ex9cpSg2jqhtsf06 aSb3L7vNUDuuIahBxSaz4YUYZBaE2EQXEKKaj73DAWBxg+yRJxm+JxBfmMx+pR3wFgX8 UFFYcQlcqHyG3riw/Ab87kK2k9NX1LCcQVNARrw7qbBaM+NeLdeAdJW7I2ldkiKEd2DK 3gDuJ/BBMJiiWtTFZjxrKWWGGKONhtflJspjHQKgCygxJYvrfCG/lW2RXVfmNhZBYSzS hLYmvO2SSawm7nlsGhvb+Wd2cpVraBl4wejaZFLPfvVQm8QH4CoB4LLams475zUzPrdq ufSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=GoDDP+xnbVQ4x7skEFOwsY4I4Z3qguLizOfgJeu8odg=; b=HCa8a/2VHI+rK5vYqINuUjc6g63ht1FvYyXpW6DQIdaEZeQY4R+YZYXjuZKUTucowr uLObQv/0PV0k1TLy1dzu3LoFxsOQKCooTglKf+CqLeF9+RksYUlFPUuH9f+03lpSz8CH WrwdaA0Z9cEt/Wz3N309piOXhNZwVSuywpsvzDCOFLM9KMVYczvNf/XVOrpGmygDD+Dk 6LiGFhJVRxrzDQGglGD0bPSSo//OPeyuA8Df4/1vHjWCODoiJFO1EDQAFSA2CC5a0TtW jETHxVSE+NhVVn20BRLBqWAbnqUhVLlfvMViSWK7jJOTYMyh3B+3OVG5MYEX1JazwuJ1 4cow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="C/6h2zxa"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 23-20020a630017000000b0045166930a46si6884200pga.609.2022.10.26.11.59.49; Wed, 26 Oct 2022 12:00:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b="C/6h2zxa"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233160AbiJZSIc (ORCPT + 99 others); Wed, 26 Oct 2022 14:08:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233536AbiJZSIa (ORCPT ); Wed, 26 Oct 2022 14:08:30 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80D2B9A9D4 for ; Wed, 26 Oct 2022 11:08:28 -0700 (PDT) Received: from zn.tnic (p200300ea9733e7b8329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e7b8:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id A1C4D1EC06A7; Wed, 26 Oct 2022 20:08:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1666807706; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=GoDDP+xnbVQ4x7skEFOwsY4I4Z3qguLizOfgJeu8odg=; b=C/6h2zxadK03BQiP92QBsVy+pue+mv7tPB/0IBZl3dZxIQH1gQSl61x6N5sAOOUgzWQCs8 WksbWYRJtrxk9LCeu3yQItTLkWBHU8kjnPdruFoOuAo978RgWC2rMGjdTQ3cb/TpdjqsMn qjNAV4yuejOCVpC0OCcboxDHo77nmGY= Date: Wed, 26 Oct 2022 20:08:22 +0200 From: Borislav Petkov To: Julian Pidancet Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH] x86/alternative: Consistently patch SMP locks in vmlinux and modules Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 30, 2022 at 09:42:37AM +0200, Julian Pidancet wrote: > The alternatives_smp_module_add() function restricts patching of SMP > lock prefixes to the text address range passed as an argument. > > For vmlinux, patching all the instructions located between the _text and > _etext symbols is allowed. That includes the .text section but also > other sections such as .text.hot and .text.unlikely. > > As per the comment inside the 'struct smp_alt_module' definition, the > original purpose of this restriction is to avoid patching the init code > which may have been deallocated when the alternatives code run. > > For modules, the current code only allows patching instructions located > inside the .text segment, excluding other sections such as .text.hot or > .text.unlikely, which may need patching. Is this something you noticed by inspection or is there a real failure behind it? > This change aims to make patching of the kernel core and modules more Avoid having "This patch" or "This commit" and so on, in the commit message. It is tautologically useless. Also, do $ git grep 'This patch' Documentation/process for more details. > consistent, by allowing all text sections of modules except .init.text > to be patched in module_finalize(). > > For that we use mod->core_layout.base/mod->core_layout.text_size as the Please use passive voice in your commit message: no "we" or "I", etc, and describe your changes in imperative mood. Bottom line is: personal pronouns are ambiguous in text, especially with so many parties/companies/etc developing the kernel so let's avoid them please. > address range allowed to be patched, which include all the code sections > except the init code. > > Signed-off-by: Julian Pidancet > --- > Public tests: https://gist.github.com/jpidancet/1ee457623426f3e3902a28edaf2c80d0 Looks like you wrote a module to verify that :) > Related thread: https://marc.info/?t=130864398400006 Aha, someone else noticed this inconsistency. > arch/x86/kernel/module.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c > index b1abf663417c..da22193eb5e0 100644 > --- a/arch/x86/kernel/module.c > +++ b/arch/x86/kernel/module.c > @@ -251,14 +251,12 @@ int module_finalize(const Elf_Ehdr *hdr, > const Elf_Shdr *sechdrs, > struct module *me) > { > - const Elf_Shdr *s, *text = NULL, *alt = NULL, *locks = NULL, > - *para = NULL, *orc = NULL, *orc_ip = NULL, > - *retpolines = NULL, *returns = NULL, *ibt_endbr = NULL; > + const Elf_Shdr *s, *alt = NULL, *locks = NULL, *para = NULL, > + *orc = NULL, *orc_ip = NULL, *retpolines = NULL, > + *returns = NULL, *ibt_endbr = NULL; > char *secstrings = (void *)hdr + sechdrs[hdr->e_shstrndx].sh_offset; > > for (s = sechdrs; s < sechdrs + hdr->e_shnum; s++) { > - if (!strcmp(".text", secstrings + s->sh_name)) > - text = s; > if (!strcmp(".altinstructions", secstrings + s->sh_name)) > alt = s; > if (!strcmp(".smp_locks", secstrings + s->sh_name)) > @@ -302,12 +300,13 @@ int module_finalize(const Elf_Ehdr *hdr, > void *iseg = (void *)ibt_endbr->sh_addr; > apply_ibt_endbr(iseg, iseg + ibt_endbr->sh_size); > } > - if (locks && text) { > + if (locks) { > void *lseg = (void *)locks->sh_addr; > - void *tseg = (void *)text->sh_addr; > + void *text = me->core_layout.base; > + void *text_end = text + me->core_layout.text_size; > alternatives_smp_module_add(me, me->name, > lseg, lseg + locks->sh_size, > - tseg, tseg + text->sh_size); > + text, text_end); > } > > if (orc && orc_ip) > -- I don't see anything wrong with doing that on a quick glance... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette