Section .static_call_sites holds data structures that need to be sorted and
processed only at module load time. This initial processing happens in
static_call_add_module(), which is invoked as a callback to the
MODULE_STATE_COMING notification from prepare_coming_module().
The section is never modified afterwards. Make it therefore read-only after
module initialization to avoid any (non-)accidental modifications.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
kernel/module/strict_rwx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/module/strict_rwx.c b/kernel/module/strict_rwx.c
index fa701dad4ed1..a3fc8d603750 100644
--- a/kernel/module/strict_rwx.c
+++ b/kernel/module/strict_rwx.c
@@ -120,6 +120,15 @@ static const char *const ro_after_init[] = {
* section, which are marked as such at module load time.
*/
"__jump_table",
+
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+ /*
+ * Section .static_call_sites holds data structures that need to be
+ * sorted and processed at module load time but are never modified
+ * afterwards.
+ */
+ ".static_call_sites",
+#endif
};
void module_mark_ro_after_init(const Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
--
2.43.0
Le 06/03/2025 à 14:13, Petr Pavlu a écrit :
> Section .static_call_sites holds data structures that need to be sorted and
> processed only at module load time. This initial processing happens in
> static_call_add_module(), which is invoked as a callback to the
> MODULE_STATE_COMING notification from prepare_coming_module().
>
> The section is never modified afterwards. Make it therefore read-only after
> module initialization to avoid any (non-)accidental modifications.
Maybe this suggestion is stupid, I didn't investigate the feasability
but: why don't we group everything that is ro_after_init in a single
section just like we do in vmlinux ? That would avoid having to add
every new possible section in the C code.
Like we have in asm-generic/vmlinux.lds.h:
#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 = .;
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> kernel/module/strict_rwx.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/kernel/module/strict_rwx.c b/kernel/module/strict_rwx.c
> index fa701dad4ed1..a3fc8d603750 100644
> --- a/kernel/module/strict_rwx.c
> +++ b/kernel/module/strict_rwx.c
> @@ -120,6 +120,15 @@ static const char *const ro_after_init[] = {
> * section, which are marked as such at module load time.
> */
> "__jump_table",
> +
> +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> + /*
> + * Section .static_call_sites holds data structures that need to be
> + * sorted and processed at module load time but are never modified
> + * afterwards.
> + */
> + ".static_call_sites",
> +#endif
> };
>
> void module_mark_ro_after_init(const Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
On Thu, Mar 06, 2025 at 06:28:58PM +0100, Christophe Leroy wrote: > > > Le 06/03/2025 à 14:13, Petr Pavlu a écrit : > > Section .static_call_sites holds data structures that need to be sorted and > > processed only at module load time. This initial processing happens in > > static_call_add_module(), which is invoked as a callback to the > > MODULE_STATE_COMING notification from prepare_coming_module(). > > > > The section is never modified afterwards. Make it therefore read-only after > > module initialization to avoid any (non-)accidental modifications. > > Maybe this suggestion is stupid, I didn't investigate the feasability but: > why don't we group everything that is ro_after_init in a single section just > like we do in vmlinux ? That would avoid having to add every new possible > section in the C code. > > Like we have in asm-generic/vmlinux.lds.h: > > #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 = .; I like this idea. Grouping the sections in the module linker script feels cleaner than having an array of section names in the code. To be fair, I think this code predates v5.10, where scripts/module.lds.S was first added. Sami
On 3/7/25 01:12, Sami Tolvanen wrote: > On Thu, Mar 06, 2025 at 06:28:58PM +0100, Christophe Leroy wrote: >> Le 06/03/2025 à 14:13, Petr Pavlu a écrit : >>> Section .static_call_sites holds data structures that need to be sorted and >>> processed only at module load time. This initial processing happens in >>> static_call_add_module(), which is invoked as a callback to the >>> MODULE_STATE_COMING notification from prepare_coming_module(). >>> >>> The section is never modified afterwards. Make it therefore read-only after >>> module initialization to avoid any (non-)accidental modifications. >> >> Maybe this suggestion is stupid, I didn't investigate the feasability but: >> why don't we group everything that is ro_after_init in a single section just >> like we do in vmlinux ? That would avoid having to add every new possible >> section in the C code. >> >> Like we have in asm-generic/vmlinux.lds.h: >> >> #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 = .; > > I like this idea. Grouping the sections in the module linker script > feels cleaner than having an array of section names in the code. To be > fair, I think this code predates v5.10, where scripts/module.lds.S was > first added. I agree in principle. I like that the information about ro_after_init sections for vmlinux and modules would be in the same source form, in linker scripts. This could eventually allow us to share the definition of ro_after_init sections between vmlinux and modules. The problem is however how to find the location of the __jump_table and static_call_sites data. In vmlinux, as a final binary, they are annotated with start and end symbols. In modules, as relocatable files, the approach is to rely on them being separate sections, see function find_module_sections(). I could add start+end symbols for __jump_table and static_call_sites data in scripts/module.lds.S and use them by the module loader, but this would create an inconsistency in how various data is looked up. Another problem is that I can't find a way to tell the linker to add these symbols only if the specific data is actually present. -- Cheers, Petr
Hi Petr, On Wed, Mar 12, 2025 at 5:05 AM Petr Pavlu <petr.pavlu@suse.com> wrote: > > On 3/7/25 01:12, Sami Tolvanen wrote: > > On Thu, Mar 06, 2025 at 06:28:58PM +0100, Christophe Leroy wrote: > >> Le 06/03/2025 à 14:13, Petr Pavlu a écrit : > >>> Section .static_call_sites holds data structures that need to be sorted and > >>> processed only at module load time. This initial processing happens in > >>> static_call_add_module(), which is invoked as a callback to the > >>> MODULE_STATE_COMING notification from prepare_coming_module(). > >>> > >>> The section is never modified afterwards. Make it therefore read-only after > >>> module initialization to avoid any (non-)accidental modifications. > >> > >> Maybe this suggestion is stupid, I didn't investigate the feasability but: > >> why don't we group everything that is ro_after_init in a single section just > >> like we do in vmlinux ? That would avoid having to add every new possible > >> section in the C code. > >> > >> Like we have in asm-generic/vmlinux.lds.h: > >> > >> #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 = .; > > > > I like this idea. Grouping the sections in the module linker script > > feels cleaner than having an array of section names in the code. To be > > fair, I think this code predates v5.10, where scripts/module.lds.S was > > first added. > > I agree in principle. I like that the information about ro_after_init > sections for vmlinux and modules would be in the same source form, in > linker scripts. This could eventually allow us to share the definition > of ro_after_init sections between vmlinux and modules. > > The problem is however how to find the location of the __jump_table and > static_call_sites data. In vmlinux, as a final binary, they are > annotated with start and end symbols. In modules, as relocatable files, > the approach is to rely on them being separate sections, see function > find_module_sections(). > > I could add start+end symbols for __jump_table and static_call_sites > data in scripts/module.lds.S and use them by the module loader, but this > would create an inconsistency in how various data is looked up. That's a fair point. Perhaps it makes sense to keep these sections separate for consistency, and look into cleaning this up later if needed. > Another problem is that I can't find a way to tell the linker to add these > symbols only if the specific data is actually present. You can use the preprocessor to add the symbols only if the relevant kernel config is present, similarly to how STATIC_CALL_DATA is defined in include/asm-generic/vmlinux.lds.h. In any case, the code looks correct to me. For the series: Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Sami
On 3/13/25 00:21, Sami Tolvanen wrote:
> Hi Petr,
>
> On Wed, Mar 12, 2025 at 5:05 AM Petr Pavlu <petr.pavlu@suse.com> wrote:
>>
>> On 3/7/25 01:12, Sami Tolvanen wrote:
>>> On Thu, Mar 06, 2025 at 06:28:58PM +0100, Christophe Leroy wrote:
>>>> Le 06/03/2025 à 14:13, Petr Pavlu a écrit :
>>>>> Section .static_call_sites holds data structures that need to be sorted and
>>>>> processed only at module load time. This initial processing happens in
>>>>> static_call_add_module(), which is invoked as a callback to the
>>>>> MODULE_STATE_COMING notification from prepare_coming_module().
>>>>>
>>>>> The section is never modified afterwards. Make it therefore read-only after
>>>>> module initialization to avoid any (non-)accidental modifications.
>>>>
>>>> Maybe this suggestion is stupid, I didn't investigate the feasability but:
>>>> why don't we group everything that is ro_after_init in a single section just
>>>> like we do in vmlinux ? That would avoid having to add every new possible
>>>> section in the C code.
>>>>
>>>> Like we have in asm-generic/vmlinux.lds.h:
>>>>
>>>> #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 = .;
>>>
>>> I like this idea. Grouping the sections in the module linker script
>>> feels cleaner than having an array of section names in the code. To be
>>> fair, I think this code predates v5.10, where scripts/module.lds.S was
>>> first added.
>>
>> I agree in principle. I like that the information about ro_after_init
>> sections for vmlinux and modules would be in the same source form, in
>> linker scripts. This could eventually allow us to share the definition
>> of ro_after_init sections between vmlinux and modules.
>>
>> The problem is however how to find the location of the __jump_table and
>> static_call_sites data. In vmlinux, as a final binary, they are
>> annotated with start and end symbols. In modules, as relocatable files,
>> the approach is to rely on them being separate sections, see function
>> find_module_sections().
>>
>> I could add start+end symbols for __jump_table and static_call_sites
>> data in scripts/module.lds.S and use them by the module loader, but this
>> would create an inconsistency in how various data is looked up.
>
> That's a fair point. Perhaps it makes sense to keep these sections
> separate for consistency, and look into cleaning this up later if
> needed.
>
>> Another problem is that I can't find a way to tell the linker to add these
>> symbols only if the specific data is actually present.
>
> You can use the preprocessor to add the symbols only if the relevant
> kernel config is present, similarly to how STATIC_CALL_DATA is defined
> in include/asm-generic/vmlinux.lds.h.
Right, that works but only statically. Let's say I update module.lds.S
to:
SECTIONS {
[...]
.data..ro_after_init {
*(.data..ro_after_init)
__start___jump_table = .;
*(__jump_table)
__end___jump_table = .;
#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
__start_static_call_sites = .;
*(.static_call_sites)
__end_static_call_sites = .;
#endif
}
}
What I had in mind is that you can configure the kernel with
CONFIG_HAVE_STATIC_CALL_INLINE, but some modules might not contain any
static calls and so wouldn't have a .static_call_sites section. When
using the above script, such modules would still end up with unnecessary
symbols __start_static_call_sites and __end_static_call_sites defining
an empty range. Worse, if the module doesn't contain any ro_after_init
data, the added symbols would force the linker to create an empty
.data..ro_after_init section.
>
> In any case, the code looks correct to me. For the series:
>
> Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
--
Thanks,
Petr
© 2016 - 2026 Red Hat, Inc.