[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXHXeiPiksuOabp-NXu0ORmmP1Jd1wZPmgAi09jsjaDAsQ@mail.gmail.com>
Date: Fri, 13 Dec 2024 09:26:14 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Shijie Huang <shijie@...eremail.onmicrosoft.com>
Cc: Huang Shijie <shijie@...amperecomputing.com>, catalin.marinas@....com, will@...nel.org,
anshuman.khandual@....com, corbet@....net, patches@...erecomputing.com,
cl@...ux.com, akpm@...ux-foundation.org, thuth@...hat.com,
rostedt@...dmis.org, xiongwei.song@...driver.com, inux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 1/2 fix] arm64: refactor the rodata=xxx
On Fri, 13 Dec 2024 at 09:23, Shijie Huang
<shijie@...eremail.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@...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@...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?
Powered by blists - more mailing lists