linux-kernel - Re: [PATCH v4] arm64: mm: fix linear mem mapping access performance degradation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YsP3xnpyPON9KsMQ@MiWiFi-R3L-srv>
Date:   Tue, 5 Jul 2022 16:35:18 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Will Deacon <will@...nel.org>, kexec@...ts.infradead.org,
        "guanghui.fgh" <guanghuifeng@...ux.alibaba.com>,
        baolin.wang@...ux.alibaba.com, catalin.marinas@....com,
        akpm@...ux-foundation.org, david@...hat.com, jianyong.wu@....com,
        james.morse@....com, quic_qiancai@...cinc.com,
        christophe.leroy@...roup.eu, jonathan@...ek.ca,
        mark.rutland@....com, thunder.leizhen@...wei.com,
        anshuman.khandual@....com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, rppt@...nel.org,
        geert+renesas@...der.be, linux-mm@...ck.org,
        yaohongbo@...ux.alibaba.com, alikernel-developer@...ux.alibaba.com
Subject: Re: [PATCH v4] arm64: mm: fix linear mem mapping access performance
 degradation

On 07/04/22 at 07:09pm, Ard Biesheuvel wrote:
> On Mon, 4 Jul 2022 at 18:38, Will Deacon <will@...nel.org> wrote:
> >
> > On Mon, Jul 04, 2022 at 10:34:07PM +0800, guanghui.fgh wrote:
> > > Thanks.
> > >
> > > 在 2022/7/4 22:23, Will Deacon 写道:
> > > > On Mon, Jul 04, 2022 at 10:11:27PM +0800, guanghui.fgh wrote:
> ...
> > > > > Namely, it's need to use non block/section mapping for crashkernel mem
> > > > > before shringking.
> > > >
> > > > Well, yes, but we can change arch_kexec_[un]protect_crashkres() not to do
> > > > that if we're leaving the thing mapped, no?
> > > >
> > > I think we should use arch_kexec_[un]protect_crashkres for crashkernel mem.
> > >
> > > Because when invalid crashkernel mem pagetable, there is no chance to rd/wr
> > > the crashkernel mem by mistake.
> > >
> > > If we don't use arch_kexec_[un]protect_crashkres to invalid crashkernel mem
> > > pagetable, there maybe some write operations to these mem by mistake which
> > > may cause crashkernel boot error and vmcore saving error.
> >
> > I don't really buy this line of reasoning. The entire main kernel is
> > writable, so why do we care about protecting the crashkernel so much? The
> > _code_ to launch the crash kernel is writable! If you care about preventing
> > writes to memory which should not be writable, then you should use
> > rodata=full.
> >
> 
> This is not entirely true - the core kernel text and rodata are
> remapped r/o in the linear map, whereas all module code and rodata are
> left writable when rodata != full.
> 
> But the conclusion is the same, imo: if you can't be bothered to
> protect a good chunk of the code and rodata that the kernel relies on,
> why should the crashkernel be treated any differently?

Kernel text and rodata are remapped r/o in linear map, whereas
module code and rodata are left writable, it's different concept
than crashkernel region being mapped r/o.

If it's doable in technology to remap module code and rodata r/o, and
stamping into those regions will corrupt the entire system, we should do
it too. However, kdump is a system error diagonosing mechanism which is
very important and helpful on server, or some application scenarios, e.g
cloud. Stamping into crashkernel region will make it useless.

I am not against removing the arch_kexec_[un]protect_crashkres on arm64.
It is a balance:

Protecting the crashkernel region, causeing severe performance
degradation. This is always felt since we usually don't specify rodata
and enable kfence.

Taking off the protecting of crashkernel region, performance improved
very much, while wrong code may stamp into crashkernel region and fail
kdump. That could happen one in a million. Once happen, it's a nightmare
of kernel dev.