Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp1365659pxb; Sat, 4 Sep 2021 07:47:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy99MhkR13cdoFEYy8FJVJTgSZ0eKtKcHMex927y8P67797Bduq4/qtQWj5at3jGxY0qldb X-Received: by 2002:a17:906:3148:: with SMTP id e8mr4489897eje.240.1630766850199; Sat, 04 Sep 2021 07:47:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630766850; cv=none; d=google.com; s=arc-20160816; b=QRwEwuQ/TpLyEoWh7RdDcc2WV9E8KG5YegDWmisRIyF9OzxH7Umg3ROgMFNyMisxXA 1Jh+VoxxBx2jpjdaQjO4mDyB/x4FBYnblad0kybcoPLxxzJIYzl63fyBW0VjQ65pAFDK WlvWUm+TRzLbCb9LkfyH3VqifvPK5TGncMzlKT7HpvZ5IGsfWzLabhND8A98evKoKbtV fV7YijMzLfS1rcE8vzs/2vtueajXCk4utp4krtNxJpQhOhkWTfHaMIc2iHZAihuAnkn2 VUIKWMblWwWDARjSNd5Eij8NpUuLcKSEqTLDGXWP2W4VxHrnA+Jf4abKCn4/7B7KKBVT BNJw== 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=rT9D3cD6AK/U9ynMxv4dnPjLHMnSzhI3eW+DvMhMYv4=; b=MdF30OJMf/kbRc+d9V6v/UPQMA8VgBGT8nuAZvw89O/Yf5dO85wcJnaiDWocxkdgCZ djnRgGBiAMPlT3x/B6qWZbO3ZIoNo4zorx4o7VZNC20wKl4ktK+XDs9jHFWZqc2xfO97 QaS0GzWU4PS/lwxjfIxJoqQAhkNNHOWoc5FP/6Vx66Q8QKmntSU/cH8XAq9LZEBpwoG5 djJsdwGN1dqPmexiPVwnllo4sLmpqCuNxwbVEGs4Ul3goylIzvyHasP2UAdwsiBHhlea 8F2yoP3qvserB0A54OpekaYrKpjCQj3DierX30jSDga9dffAPTA7SsSoGCi9gffT3Wgk 0Xfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=bA7994xB; 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 j10si2745856edq.258.2021.09.04.07.47.06; Sat, 04 Sep 2021 07:47:30 -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=bA7994xB; 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 S236581AbhIDOlM (ORCPT + 99 others); Sat, 4 Sep 2021 10:41:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231987AbhIDOlM (ORCPT ); Sat, 4 Sep 2021 10:41:12 -0400 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA71AC061575 for ; Sat, 4 Sep 2021 07:40:10 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id bg1so1265272plb.13 for ; Sat, 04 Sep 2021 07:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=rT9D3cD6AK/U9ynMxv4dnPjLHMnSzhI3eW+DvMhMYv4=; b=bA7994xBs5m1ZQvCLablElQZ97mYGS2txQ6t1KugHdJ9bOTKQn/g1ykQb6kf+VW1kj x53d9bgkmnic8+HM/3c01odPUM/1NaKqTuMfBesS5QBLCQov39J4DsNKc4fDhIo5uKGu QmkVEDxUwaKxGfTW9JqRWsG1vFwPPcYyrSs1A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rT9D3cD6AK/U9ynMxv4dnPjLHMnSzhI3eW+DvMhMYv4=; b=laTtmNKMc5KkwznslAywqoBUSoO2J7IzOadJe5jXfDeDkHfZpq44iQzT7A8sfty9m8 yRz+79O3SU9K+lzpqU7jLMcBoZ7K2GQXc6n3OS2MQDZy1UL04U9BI58kWkNSCS8mLabe uZronpIObYJh87Z3xRkOLQhgLZzsd8SeoOgr/JE2QTeMNCJOeQylsCd/1srj19kEoOgF kqEovHAJiWXx0KOI/ETQ3iQYIGfn9bj2vFMuBT4k8HobFlt42R5a7/IVzlrTeEBjli7/ jD0On8xuibWgU9kqhmptyc15DTBsEQ0CJPKITfi3txeTb+QAEJ8cOgS4pwTal6/TF+Ev YgQQ== X-Gm-Message-State: AOAM531fVOzm9qR+0zFyUk1jYGUXCrunu70zN0K5GXXzT15CbkQgG0Se pSrCLYnGbJvL2FxiItsQOWKosQ== X-Received: by 2002:a17:902:a50f:b029:11a:b033:e158 with SMTP id s15-20020a170902a50fb029011ab033e158mr3561213plq.26.1630766410054; Sat, 04 Sep 2021 07:40:10 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id u6sm2949081pgr.3.2021.09.04.07.40.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Sep 2021 07:40:09 -0700 (PDT) Date: Sat, 4 Sep 2021 07:40:08 -0700 From: Kees Cook To: Josh Poimboeuf Cc: Arnd Bergmann , Jessica Yu , Peter Zijlstra , linux-arch@vger.kernel.org, Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Alexander Egorenkov , Sven Schnelle , Ilya Leoshkevich , "Steven Rostedt (VMware)" , Ingo Molnar , Sami Tolvanen , linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-hardening@vger.kernel.org, Sean Christopherson Subject: Re: [PATCH 3/4] module: Use a list of strings for ro_after_init sections Message-ID: <202109040739.F973371BD@keescook> References: <20210901233757.2571878-1-keescook@chromium.org> <20210901233757.2571878-4-keescook@chromium.org> <20210903064951.to4dhiu7zua7s6dn@treble> <202109030932.1358C4093@keescook> <20210904040903.tgkkoo2x76zpuj62@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210904040903.tgkkoo2x76zpuj62@treble> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 03, 2021 at 09:09:03PM -0700, Josh Poimboeuf wrote: > On Fri, Sep 03, 2021 at 09:38:42AM -0700, Kees Cook wrote: > > On Thu, Sep 02, 2021 at 11:49:51PM -0700, Josh Poimboeuf wrote: > > > On Wed, Sep 01, 2021 at 04:37:56PM -0700, Kees Cook wrote: > > > > Instead of open-coding the section names, use a list for the sections that > > > > need to be marked read-only after init. Unfortunately, it seems we can't > > > > do normal section merging with scripts/module.lds.S as ld.bfd doesn't > > > > correctly update symbol tables. For more details, see commit 6a3193cdd5e5 > > > > ("kbuild: lto: Merge module sections if and only if CONFIG_LTO_CLANG > > > > is enabled"). > > > > > > I'm missing what this has to do with section merging. Can you connect > > > the dots here, i.e. what sections would we want to merge and how would > > > that help here? > > > > Right, sorry, if ld.bfd didn't have this issue, we could use section > > merging in the module.lds.S file the way we do in vmlinux.lds: > > > > #ifndef RO_AFTER_INIT_DATA > > #define RO_AFTER_INIT_DATA \ > > . = ALIGN(8); \ > > __start_ro_after_init = .; \ > > *(.data..ro_after_init) \ > > JUMP_TABLE_DATA \ > > STATIC_CALL_DATA \ > > __end_ro_after_init = .; > > #endif > > ... > > . = ALIGN((align)); \ > > .rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \ > > __start_rodata = .; \ > > *(.rodata) *(.rodata.*) \ > > SCHED_DATA \ > > RO_AFTER_INIT_DATA /* Read only after init */ \ > > . = ALIGN(8); \ > > __start___tracepoints_ptrs = .; \ > > KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \ > > __stop___tracepoints_ptrs = .; \ > > *(__tracepoints_strings)/* Tracepoints: strings */ \ > > } \ > > > > Then jump_table and static_call sections could be collected into a > > new section, as the module loader would only need to look for that > > single name. > > Hm, that could be a really nice way to converge things for vmlinux and > module linking. Agreed! I had really wanted to do more of this, but was stumped by the weird symbol behavior. > After some digging, 6a3193cdd5e5 isn't necessarily a linker bug. It may > be some kind of undefined behavior when the section address isn't > specified. If you just explicitly set the section address to zero then > the "bug" goes away. Well that's a nice find! I'll play more with this to see if I can make a cleaner solution. Thanks! -Kees > > diff --git a/scripts/module.lds.S b/scripts/module.lds.S > index 04c5685c25cf..80b09b7d405c 100644 > --- a/scripts/module.lds.S > +++ b/scripts/module.lds.S > @@ -30,23 +30,22 @@ SECTIONS { > > __patchable_function_entries : { *(__patchable_function_entries) } > > -#ifdef CONFIG_LTO_CLANG > /* > * With CONFIG_LTO_CLANG, LLD always enables -fdata-sections and > * -ffunction-sections, which increases the size of the final module. > * Merge the split sections in the final binary. > */ > - .bss : { > + .bss 0 : { > *(.bss .bss.[0-9a-zA-Z_]*) > *(.bss..L*) > } > > - .data : { > + .data 0 : { > *(.data .data.[0-9a-zA-Z_]*) > *(.data..L*) > } > > - .rodata : { > + .rodata 0 : { > *(.rodata .rodata.[0-9a-zA-Z_]*) > *(.rodata..L*) > } > @@ -55,11 +54,10 @@ SECTIONS { > * With CONFIG_CFI_CLANG, we assume __cfi_check is at the beginning > * of the .text section, and is aligned to PAGE_SIZE. > */ > - .text : ALIGN_CFI { > + .text 0 : ALIGN_CFI { > *(.text.__cfi_check) > *(.text .text.[0-9a-zA-Z_]* .text..L.cfi*) > } > -#endif > } > > /* bring in arch-specific sections */ > -- Kees Cook