linux-kernel - Re: NETIF_F_HIGHDMA misuse in networking drivers?

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: <20100222.155357.235673585.davem@davemloft.net>
Date:	Mon, 22 Feb 2010 15:53:57 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	hancockrwd@...il.com
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: NETIF_F_HIGHDMA misuse in networking drivers?

From: Robert Hancock <hancockrwd@...il.com>
Date: Sat, 20 Feb 2010 12:29:14 -0600

> Was just part of a discussion in another thread talking about 64-bit
> DMA support issues where NETIF_F_HIGHDMA came up. I was originally
> under the impression that this flag indicated the device supported
> 64-bit DMA addressing. However, from looking at the code that checks
> for it (and, well, the actual comment for the flag) it really means
> "can access highmem" which has nothing to do with 64-bit at all. And
> if there's no highmem (like on x86_64) it has no effect at all.

I think it's trying to do two things, and doing only one of them
well :-)

It's trying to keep drivers from receiving highmem pages if they are
not able to access them properly.  F.e. imagine a driver that copies
data out of the packet assuming that page_address() is always valid on
the SKB pages.

It's also trying to use this to prevent physical addresses beyond 4GB
from reaching the driver, which as you note is not implemented
precisely here.

Without knowing something about how the driver "DMAs" packet data we
can't really do an accurate test here.  Maybe the driver directly DMAs
using physical addressing (an ASIC inside of a CPU, for example,
drivers/net/niu.c has a case of this).

Maybe the platform uses an IOMMU with 32-bit virtual addressing, so
any physical address is fine even if the card only supports 32-bit
addressing (basically any PCI coard on sparc64 is an example of this).

And finally maybe the card supports 64-bit DMA addressing so anything
works on any platform.

How to test all of these possible cases precisely that at this spot in
the transmit path is the question at hand.  To be honest I consider
the current hack "good enough" :-)

--
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/