arm64 code looking for variable rodata_enabled when STRICT_KERNEL_RWX = n

Chan Kim ckim at etri.re.kr
Sat Mar 19 19:10:14 EDT 2022


Hello Fabio and all,

I realized what was wrong.

If I wanted to change ARCH_OPTIONAL_KERNEL_RWX to =y, I should have changed it in my defconfig.

I’ve done doing that several times in the past but I temporarily forgot that.

After putting ARCH_OPTIONAL_KERNEL_RWX=y in my xxx_defconfig (for my board), and reverting the source to the original, it builds ok.

(of course after you change something with menuconfig, and if you want to save that config, you should use ‘make savedefconfig’ and store that generated defconfig file as arch/arm64/configs/xxx_defconfig)

I think I don’t have to change the default setting for arm64 and there should be an error in my qemu code(this was to avoid an error during u-boot/linux test on qemu).

Chan

 

From: FMDF <fmdefrancesco at gmail.com> 
Sent: Saturday, March 19, 2022 7:24 PM
To: Chan Kim <ckim at etri.re.kr>
Cc: kernelnewbies <kernelnewbies at kernelnewbies.org>
Subject: Re: arm64 code looking for variable rodata_enabled when STRICT_KERNEL_RWX = n

 

On Fri, 18 Mar 2022, 07:04 Chan Kim, <ckim at etri.re.kr <mailto:ckim at etri.re.kr> > wrote:

Hello all,

This is what I see when I search “KERNEL_RWX” during “make menuconfig” for arm64 kernel(5-10.0-rc5).  

The Kconfig file says CONFIG_STRICT_KERNEL_RWX is for setting text and rodata read-only.

     Symbol: ARCH_OPTIONAL_KERNEL_RWX [=n]   

     Type  : bool   

     Defined at arch/Kconfig:928  

     Symbol: ARCH_OPTIONAL_KERNEL_RWX_DEFAULT [=n]   

     Type  : bool   

     Defined at arch/Kconfig:931   

 

     Symbol: STRICT_KERNEL_RWX [=y]   

     Type  : bool   

     Defined at arch/Kconfig:937   

       Prompt: Make kernel text and rodata read-only   

       Depends on: ARCH_HAS_STRICT_KERNEL_RWX [=y]   

       Visible if: ARCH_HAS_STRICT_KERNEL_RWX [=y] && ARCH_OPTIONAL_KERNEL_RWX [=n]   

       Location:   

     (1) -> General architecture-dependent options  

I wanted to try setting STRICT_KERNEL_RWX to =n. It says this option is visible when ARCH_OPTIONAL_KERNEL_RWX is =y which is now =n.

Now I'm a bit confused... why do you say that "It says this option is visible when ARCH_OPTIONAL_KERNEL_RWX is =y"?

 

I haven't ever written Kbuild rules but as far as I understand that message  "Symbol: STRICT_KERNEL_RWX [=y] [is] Visible if: ARCH_HAS_STRICT_KERNEL_RWX [=y] && ARCH_OPTIONAL_KERNEL_RWX [=n]" seems to say that we can see and enable/disable STRICT_KERNEL_RWX if and only if ARCH_HAS_STRICT_KERNEL_RWX is set to "yes" AND ARCH_OPTIONAL_KERNEL_RWX is set to "no".

 

Is it me that I'm misunderstanding the above-mentioned message from "make menuconfig"?

So I modified to ARCH_OPTIONAL_KERNEL_RWX=y in arch/Kconfig line 928. (BTW, is it correct to modify this Kconfig file directly? I’m not sure at the moment)

For sure, I'd never do this. Why don't you simply use make menuconfig for enabling/disabling options? Options are strictly interrelated and largely  depend on others. Why do you want to bypass dependency checks?

Then I could see the STRICT_KERNEL_RWX menu in the menuconfig and I set it to =n as I wanted.  

But when I build the kernel, I see this errors. 

Again, if it's not me that I'm missing something, the following errors are simply explained by your weird way to enable/disable options.

 

Please correct me if I didn't get something that you wrote (I'm very tired now after a long night staying awoke :))

 

Regards,

 

Fabio M. De Francesco

 

    ckim at ckim-ubuntu:~/ProjX/LinuxDevDrv/kernel-release-RD-INFRA-2020.11.30$ <mailto:ckim at ckim-ubuntu:~/ProjX/LinuxDevDrv/kernel-release-RD-INFRA-2020.11.30$>  makeit

      CALL    scripts/atomic/check-atomics.sh

      CALL    scripts/checksyscalls.sh

      CHK     include/generated/compile.h

      CC      arch/arm64/mm/mmu.o

    arch/arm64/mm/mmu.c: In function 'parse_rodata':

    arch/arm64/mm/mmu.c:595:28: error: 'rodata_enabled' undeclared (first use in this function)

      595 |  int ret = strtobool(arg, &rodata_enabled);

          |                            ^~~~~~~~~~~~~~

    arch/arm64/mm/mmu.c:595:28: note: each undeclared identifier is reported only once for each function it appears in

    arch/arm64/mm/mmu.c: In function 'map_entry_trampoline':

    arch/arm64/mm/mmu.c:614:18: error: 'rodata_enabled' undeclared (first use in this function)

      614 |  pgprot_t prot = rodata_enabled ? PAGE_KERNEL_ROX : PAGE_KERNEL_EXEC;

          |                  ^~~~~~~~~~~~~~

    arch/arm64/mm/mmu.c: In function 'map_kernel':

    arch/arm64/mm/mmu.c:669:23: error: 'rodata_enabled' undeclared (first use in this function)

      669 |  pgprot_t text_prot = rodata_enabled ? PAGE_KERNEL_ROX : PAGE_KERNEL_EXEC;

          |                       ^~~~~~~~~~~~~~

    make[2]: *** [scripts/Makefile.build:283: arch/arm64/mm/mmu.o] Error 1

    make[1]: *** [scripts/Makefile.build:500: arch/arm64/mm] Error 2

    make: *** [Makefile:1799: arch/arm64] Error 2

variable “rodata_enabled” is defined in init/main.c as below.

    #if defined(CONFIG_STRICT_KERNEL_RWX) || defined(CONFIG_STRICT_MODULE_RWX)

    bool rodata_enabled __ro_after_init = true;

    static int __init set_debug_rodata(char *str)

    {

        return strtobool(str, &rodata_enabled);

    }

    __setup("rodata=", set_debug_rodata);

    #endif

But now since CONFIG_STRICT_KERNEL_RWX=n, it is not defined here(CONFIG_STRICT_MODULE_RWX=n too). 

and arch/arm64/mm/mmu.c code is still using `rodata_enabled`. Is this a bug of the code? Or am I missing something?

I can modify init/main.c and include/linux/init.h so that this rodata_enabled and related functions be defined regardless of these CONFIG values and make the errors go away, but I’m curious if this a kind of kernel bug raising compiler error.

Any comment will be really appreciated.

Thank you!

 

Chan Kim

 

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org <mailto:Kernelnewbies at kernelnewbies.org> 
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20220320/13ce1a2c/attachment-0001.html>


More information about the Kernelnewbies mailing list