Messages in this thread | | | From | Bjorn Helgaas <> | Subject | Re: [RFC] prevent "dd if=/dev/mem" crash | Date | Mon, 20 Oct 2003 09:17:10 -0600 |
| |
On Friday 17 October 2003 6:21 pm, David Mosberger wrote: > What about memory-mapped device registers? Isn't all memory > physically contiguous on x86 and that's why the "p >= > __pa(high_memory)" test saves you from that?
As others have mentioned, using read/write on /dev/mem to get at memory-mapped registers is unlikely to work on ia64 anyway, because read/write use cacheable mappings. Using mmap does work (using uncacheable mappings), and my patch doesn't change that path.
> >> On ia64, a read to non-existent physical memory causes the processor > >> to time out and take a machine check. I'm not sure it's even possible > >> to recover from that. > > Andrew> ick. That would be very poor form. > > Reasonable people can disagree on that. One philosophy states that if > your kernel touches random addresses, it's better to signal a visible > error (machine-check) than to risk silent data corruption.
It occurred to me over the weekend that part of this confusion is related to the fact that ia64 doesn't have page tables for the kernel identity-mapped segments. (We're talking about reading physical memory, but read/write_mem() actually convert the address using __va() before doing the copy.)
I bet that ia32 does have page tables for this case, and that an attempt to read non-existent physical memory will cause a TLB miss from which copy_*_user() can easily recover.
On ia64, the same TLB miss would occur, but since there are no page tables, the miss handler assumes the kernel knows what it is doing and happily synthesizes a mapping that points nowhere.
Bjorn
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |