linux-kernel - RE: [PATCH] arm64: mm: add support for memmap kernel parameters

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]
Date:   Wed, 18 Nov 2020 23:55:33 +0000
From:   "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>
To:     Ard Biesheuvel <ardb@...nel.org>
CC:     Will Deacon <will@...nel.org>, Mike Rapoport <rppt@...nel.org>,
        "anshuman.khandual@....com" <anshuman.khandual@....com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        Linuxarm <linuxarm@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH] arm64: mm: add support for memmap kernel parameters



> -----Original Message-----
> From: Ard Biesheuvel [mailto:ardb@...nel.org]
> Sent: Thursday, November 19, 2020 11:38 AM
> To: Song Bao Hua (Barry Song) <song.bao.hua@...ilicon.com>
> Cc: Will Deacon <will@...nel.org>; Mike Rapoport <rppt@...nel.org>;
> anshuman.khandual@....com; catalin.marinas@....com; Linuxarm
> <linuxarm@...wei.com>; linux-kernel@...r.kernel.org;
> akpm@...ux-foundation.org; linux-arm-kernel@...ts.infradead.org
> Subject: Re: [PATCH] arm64: mm: add support for memmap kernel parameters
> 
> On Wed, 18 Nov 2020 at 21:27, Song Bao Hua (Barry Song)
> <song.bao.hua@...ilicon.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Will Deacon [mailto:will@...nel.org]
> > > Sent: Thursday, November 19, 2020 8:15 AM
> > > To: Mike Rapoport <rppt@...nel.org>
> > > Cc: Song Bao Hua (Barry Song) <song.bao.hua@...ilicon.com>;
> > > catalin.marinas@....com; linux-arm-kernel@...ts.infradead.org;
> > > linux-kernel@...r.kernel.org; akpm@...ux-foundation.org;
> > > anshuman.khandual@....com; Linuxarm <linuxarm@...wei.com>
> > > Subject: Re: [PATCH] arm64: mm: add support for memmap kernel
> parameters
> > >
> > > On Wed, Nov 18, 2020 at 07:38:54PM +0200, Mike Rapoport wrote:
> > > > On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote:
> > > > > memmap should be an useful kernel parameter which has been
> supported
> > > by
> > > > > x86, mips and xtensa.
> > > >
> > > > Why is this parameter should be useful for ARM64?
> > > > My understanding is that it is required only to work around really
> > > > broken bootloaders, isn't it?
> > >
> >
> > Good question. Originally I wrote this patch to debug and verify the
> vmemmap
> > leak issue reported in this patch:
> > [PATCH v2] arm64: mm: free unused memmap for sparse memory model that
> define VMEMMAP
> >
> https://lore.kernel.org/linux-arm-kernel/20200812010655.96339-1-liwei213@
> huawei.com/
> > I don't have a machine which really has holes in memory_section to debug,
> but memmap
> > can help. With memmap, I could specified a machine with various holds in
> mem_sections.
> >
> > After that, I figured out this is not only useful for debugging purpose. it can
> have some real user cases.
> > For example:
> >
> > 1. DAX on DRAM.
> > kernel parameter memmap=XG!YG specifies a range of RAM to emulate
> pmem. Then we are able
> > to run DAX and filesystem on top of it. Furthermore, this will probably also
> benefit the case
> > this big patchset wants to "fix" via direct access to memory:
> >
> https://lore.kernel.org/lkml/cover.1602093760.git.yuleixzhang@tencent.com/T
> /#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
> > as the comments have clearly shown.
> >
> > 2. reserve some memory for userspace to manage via /dev/mem
> >
> 
> Apologies for the bluntness, but what you are saying here is that you
> need a hack to pile those other hacks onto.
> 
> Currently, we use the NOMAP attribute in memblock to describe memory
> that is omitted from the direct map. Removing memory from memblock
> entirely also strips it of this annotation, which means that
> phys_mem_access_prot() will identify it as device memory not DRAM, and
> use the wrong attributes when using /dev/mem.
> 
> There are likely other places where this distinction matters, and so I
> am not buying the justification that we can make meaningful use of
> this memory in the general case, and anything that relies on it will
> be fragile, and probably only limited to very specific debug
> scenarios.

Yep. originally I did that for debugging purpose to emulate a machine with
some holes in mem_section. I guess it should be also useful to other people
if they need the same thing for debugging.

> 
> So I don't think we should merge this.

It should be in the same situation for other platforms like x86, mips and xtensa
but they have enabled this kernel parameter.

maybe the emulated pmem by DRAM is an useful scenario other than debugging.

Later, https://lore.kernel.org/lkml/cover.1602093760.git.yuleixzhang@tencent.com/T/#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780
might be able to use this parameter.

Anyway, I don't mind keeping it local for debugging at this stage and waiting for a
more convincing use case.

> 
> 
> >
> > > Agreed, I can't see this being something we really want to support. If it
> > > turns out that it is generally useful, then the implementation should
> > > probably be somewhere outside of arch/ where I don't have to look at it :)
> > >
> >
> > What stops this becoming common code is that each platform has different
> ways
> > and boot sequences to populate memblock.
> > For example, on Arm64, while early_param is populated, dt has populated
> > memblock before that. Other platforms might been much different.
> >
> > > Will
> >

Thanks
Barry