[PATCH v4 1/2 fix] arm64: refactor the rodata=xxx

[Ard Biesheuvel]

On Fri, 13 Dec 2024 at 09:23, Shijie Huang
<shijie at amperemail.onmicrosoft.com> wrote:
>
> Hi Ard,
>
> On 2024/12/13 15:30, Ard Biesheuvel wrote:
> > Hello Huang Shije,
> >
> > On Fri, 13 Dec 2024 at 06:32, Huang Shijie
> > <shijie at os.amperecomputing.com> wrote:
> >> As per admin guide documentation, "rodata=on" should be the default on
> >> platforms. Documentation/admin-guide/kernel-parameters.txt describes
> >> these options as
> >>
> >>     rodata=         [KNL,EARLY]
> >>             on      Mark read-only kernel memory as read-only (default).
> >>             off     Leave read-only kernel memory writable for debugging.
> >>             full    Mark read-only kernel memory and aliases as read-only
> >>                     [arm64]
> >>
> >> But on arm64 platform, "rodata=full" is the default instead. This patch
> >> implements the following changes.
> >>
> >>   - Make "rodata=on" behaviour same as the original "rodata=full"
> >>   - Make "rodata=noalias" (new) behaviour same as the original "rodata=on"
> >>   - Drop the original "rodata=full"
> >>   - Add comment for arch_parse_debug_rodata()
> >>   - Update kernel-parameters.txt as required
> >>
> >> After this patch, the "rodata=on" will be the default on arm64 platform
> >> as well.
> >>
> >> Signed-off-by: Huang Shijie <shijie at os.amperecomputing.com>
> >> ---
> >> Add more descriptions for "noalias":
> >>    It is not a security feature yet.
> > Why did you add that?
> The following is the current status of "rodata=noalias" by checking the
> kernel page table in my machine:
>
>     1) the kernel code keeps read-only in both the "vmalloc area" and
> the "linear area".
>
>     2) But there is a read-only memory range which is read-only in
> "vmalloc area", but its linear alias is read-write in the "linear area".
>
>
> Maybe the "security" is not a proper word.
>

There is nothing wrong with the word 'security' as long as you are
clear about the fact that rodata=noalias decreases it.

>
> >
> > How do you envisage 'noalias' becoming a security feature? The point
>
> for the case 2) above, if its linear alias is also mapped as read-only,
>
> can we think it is safe as the original "rodata=full"?
>

No, it is not. Why would we bother with rodata=full (which is costly
in terms of TLB pressure) if rodata=noalias is equally safe?