linux-kernel - Re: [PATCH] kmemleak: Ignore the aperture memory hole on x86

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 15 Aug 2009 23:34:41 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kmemleak: Ignore the aperture memory hole on x86_64

On Sat, 2009-08-15 at 15:17 +0100, Ingo Molnar wrote:
> * Catalin Marinas <catalin.marinas@....com> wrote:
> > +     /*
> > +      * Kmemleak should not scan this block as it may not be mapped via the
> > +      * kernel direct mapping.
> > +      */
> > +     kmemleak_ignore(p);
> 
> More importantly, kmemleak should _never_ do the garbage collection
> scan for device memory (such as the agp aperture above). All the
> aperture areas are in that category - PCI aperture, IOMMU areas,
> etc. etc.
> 
> Please double check that kmemleak does not check those - there are
> devices where pure reading of that address space can have
> side-effects.

I'll do a grep. But would such memory still be mapped in the kernel
direct mapping? In this particular case, it was alloc_bootmem() memory
which seems to have been unmapped (and cause an oops), otherwise, at
least on some architectures, may have problems with speculative fetches.

Kmemleak doesn't track other mappings like ioremap, so it should not
scan device memory.

Since you raised this, I realised there is a class of kmalloc'ed memory
blocks that may have some issues on non-coherent architectures. If such
blocks are used for DMA and cache invalidation is only done in
dma_map_single(FROM_DEVICE) (the ARM case), kmemleak scanning before
dma_unmap_single() may pollute the cache. One solution is to invalidate
the caches again in dma_unmap_single(). I'm not sure ignoring GFP_DMA
blocks would be feasible if this flag is used for other blocks
containing pointers. I need to do some tests but I don't think x86 is
affected.

Thanks.

-- 
Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/