linux-kernel - Re: DMA using data buffer vmapped in kernel space

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

Message-Id: <20100309.022015.162981335.davem@davemloft.net>
Date:	Tue, 09 Mar 2010 02:20:15 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	linux@....linux.org.uk
Cc:	mkl0301@...il.com, thomas@...ller.dyndns.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: DMA using data buffer vmapped in kernel space

From: Russell King - ARM Linux <linux@....linux.org.uk>
Date: Tue, 9 Mar 2010 10:16:11 +0000

> It looks like the firmware interface may return a pointer to either the
> kernel binary itself for built-in firmware, or to a set of pages which
> have been vmap'd.  In the former case, vmalloc_to_page() will fail.

Indeed, then you're right, the firmware layer would need to provide
the interface since only it knows where the memory is.

However, there's also no real portable way to compute physical
addresses from kernel image virtual addresses.

BTW, it's been my experience that drivers copy the firmware into a
locally allocated buffer exactly to avoid this problem.
--
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/