linux-kernel - Re: [PATCH] arm64: Change elfcore for_each_mte

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, 23 Feb 2022 13:57:23 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Catalin Marinas <catalin.marinas@....com>
CC:     Will Deacon <will@...nel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA
 iterator

* Catalin Marinas <catalin.marinas@....com> [220223 04:39]:
> On Tue, Feb 22, 2022 at 06:54:38PM +0000, Liam Howlett wrote:
> > * Catalin Marinas <catalin.marinas@....com> [220222 12:26]:
> > > On Tue, Feb 22, 2022 at 04:20:16PM +0000, Will Deacon wrote:
> > > > On Tue, Feb 22, 2022 at 02:26:03PM +0000, Liam Howlett wrote:
> > > > > The vma iterator uses the maple tree, so this patch would resolve the
> > > > > conflict but both branches are needed.
> > > > 
> > > > I'm not really sure what to do here, then. I think the conflict is nasty
> > > > enough that we should resolve it before the trees reach Linus, but there
> > > > doesn't seem to be a way forward other than one of us merging the other
> > > > branch. I'd like to avoid having MTE coredump support depend on the maple
> > > > tree work.
> > > > 
> > > > Is there some way you could provide a branch which implements
> > > > for_each_vma() using the old vma list, and then the maple tree series
> > > > could switch that over to the maple tree without breaking things?
> > > 
> > > Without a branch, we could apply something like below on top of Liam's
> > > patch and revert it once the maple tree is upstream:
> > > 
> > > diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> > > index 930a0bc4cac4..400ec7a902df 100644
> > > --- a/arch/arm64/kernel/elfcore.c
> > > +++ b/arch/arm64/kernel/elfcore.c
> > > @@ -8,6 +8,13 @@
> > >  #include <asm/cpufeature.h>
> > >  #include <asm/mte.h>
> > > 
> > > +#ifndef VMA_ITERATOR
> > > +#define VMA_ITERATOR(name, mm, addr) \
> > > +	struct mm_struct *name = mm
> > > +#define for_each_vma(vmi, vma) \
> > > +	for (vma = vmi->mmap; vma; vma = vma->vm_next)
> > > +#endif
> > > +
> > >  #define for_each_mte_vma(vmi, vma)					\
> > >  	if (system_supports_mte())					\
> > >  		for_each_vma(vmi, vma)					\
> > 
> > Note that the current VMA_ITERATOR takes a new type and not the mm.
> 
> Well, in you proposed fix, it does take current->mm.

Sorry.  Yes, you are correct.  The VMA_ITERATOR() takes the mm.  The for
each takes the vmi.

> 
> > Since I am removing the linked list (mm->mmap and vma->vm_next), then
> > the build will fail if this patch and the maple tree branch exist
> > together.  The iterator may also not start at the start of the list (but
> > usually does) and may not run through the entire list; see
> > vma_for_each_range() in the patch set.
> 
> My hack above is only temporary to allow building the arm64 tree on its
> own (no maple tree branch) and with your patch on top. In -next, when
> merged with the maple tree branch, the VMA_ITERATOR macro is already
> defined and the above hack skipped. We'll revert this hack around -rc1.
> 
> Note that the hack above is only in the arm64 elfcore.c, not a generic
> API solution.

Okay, thanks.  This sounds good if it works on your side.  Sorry for not
getting it earlier.

Liam