linux-kernel - wrong usage of MAX_DMA

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-next>] [day] [month] [year] [list]

Message-id: <alpine.LFD.2.00.0809301513260.3635@xanadu.home>
Date:	Tue, 30 Sep 2008 15:35:01 -0400 (EDT)
From:	Nicolas Pitre <nico@....org>
To:	lkml <linux-kernel@...r.kernel.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>
Subject: wrong usage of MAX_DMA_ADDRESS in bootmem.h

I have implemented highmem for ARM.  To catch wrong usage of __pa() and 
__va() with out of range values, I added a range check when 
CONFIG_DEBUG_HIGHMEM is set.

One issue is that bootmem.h uses __pa(MAX_DMA_ADDRESS). However 
MAX_DMA_ADDRESS on ARM is defined as 0xffffffff because there is usually 
no restriction on the maximum DMA-able address.

RMK suggested that those places should be using ISA_DMA_THRESHOLD 
instead -- here's an excert of our conversation on this topic:

> I suspect all those places which are doing __pa(MAX_DMA_ADDRESS) really
> want to be using ISA_DMA_THRESHOLD - that's something to raise on LKML
> if it's causing problems.
> 
> > > Given the definition I've just given, if there's no restrictions on
> > > what can be DMA'd from, defining 'MAX_DMA_ADDRESS' to a constant well
> > > in excess of the maximum amount of RAM is quite reasonable.  Since most
> > > ARM platforms don't have any restrictions on memory that can be DMA'd,
> > > the existing code is perfectly reasonable and correct.
> > 
> > It falls apart when the range check on values passed to __pa() is 
> > enabled in a highmem context.
> 
> As I say, having it in excess of the real amount of RAM fitted is not a
> problem.  Unfortunately, it makes the range check fall apart but I suspect
> that's because of inappropriate use.

So what about this patch?

diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 95837bf..7a97ffe 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -96,21 +96,21 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat,
 				      unsigned long goal);
 #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
 #define alloc_bootmem(x) \
-	__alloc_bootmem(x, SMP_CACHE_BYTES, __pa(MAX_DMA_ADDRESS))
+	__alloc_bootmem(x, SMP_CACHE_BYTES, ISA_DMA_THRESHOLD)
 #define alloc_bootmem_nopanic(x) \
-	__alloc_bootmem_nopanic(x, SMP_CACHE_BYTES, __pa(MAX_DMA_ADDRESS))
+	__alloc_bootmem_nopanic(x, SMP_CACHE_BYTES, ISA_DMA_THRESHOLD)
 #define alloc_bootmem_low(x) \
 	__alloc_bootmem_low(x, SMP_CACHE_BYTES, 0)
 #define alloc_bootmem_pages(x) \
-	__alloc_bootmem(x, PAGE_SIZE, __pa(MAX_DMA_ADDRESS))
+	__alloc_bootmem(x, PAGE_SIZE, ISA_DMA_THRESHOLD)
 #define alloc_bootmem_pages_nopanic(x) \
-	__alloc_bootmem_nopanic(x, PAGE_SIZE, __pa(MAX_DMA_ADDRESS))
+	__alloc_bootmem_nopanic(x, PAGE_SIZE, ISA_DMA_THRESHOLD)
 #define alloc_bootmem_low_pages(x) \
 	__alloc_bootmem_low(x, PAGE_SIZE, 0)
 #define alloc_bootmem_node(pgdat, x) \
-	__alloc_bootmem_node(pgdat, x, SMP_CACHE_BYTES, __pa(MAX_DMA_ADDRESS))
+	__alloc_bootmem_node(pgdat, x, SMP_CACHE_BYTES, ISA_DMA_THRESHOLD)
 #define alloc_bootmem_pages_node(pgdat, x) \
-	__alloc_bootmem_node(pgdat, x, PAGE_SIZE, __pa(MAX_DMA_ADDRESS))
+	__alloc_bootmem_node(pgdat, x, PAGE_SIZE, ISA_DMA_THRESHOLD)
 #define alloc_bootmem_low_pages_node(pgdat, x) \
 	__alloc_bootmem_low_node(pgdat, x, PAGE_SIZE, 0)
 #endif /* !CONFIG_HAVE_ARCH_BOOTMEM_NODE */
--
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/