[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1412094303-28183-1-git-send-email-fhrbata@redhat.com>
Date: Tue, 30 Sep 2014 18:24:59 +0200
From: Frantisek Hrbata <fhrbata@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, tglx@...utronix.de, mingo@...hat.com,
hpa@...or.com, x86@...nel.org, oleg@...hat.com,
kamaleshb@...ibm.com, hechjie@...ibm.com,
akpm@...ux-foundation.org, dave.hansen@...el.com,
dvlasenk@...hat.com, prarit@...hat.com, lwoodman@...hat.com,
hannsj_uhl@...ibm.com, torvalds@...ux-foundation.org
Subject: [PATCH v2 0/4] x86: /dev/mem fixes
This is a second version of the patch set. The only change is in
2/4 x86: add phys addr validity check for /dev/mem mmap
where the "count" was replaced with "len_bytes" for better readability.
The rest is just a refresh because of this change.
The original message follows ...
Hi all,
this is a combination of two patch sets I sent a while ago
1) Prevent possible PTE corruption with /dev/mem mmap
2) x86: allow read/write /dev/mem to access non-system RAM above high_memory
The original thread with both patch sets can be found here
https://lkml.org/lkml/2014/8/14/229
lkml: <1408025927-16826-1-git-send-email-fhrbata@...hat.com>
1) Prevent possible PTE corruption with /dev/mem mmap
x86: add arch_pfn_possible helper
x86: add phys addr validity check for /dev/mem mmap
Many thanks goes to Dave Hansen, who helped with the "final" check. Other than
that it did not get much attention, except H. Peter Anvin's complain that having
two checks for mmap and read/write for /dev/mem access is ridiculous. I for sure
do not object to this, but AFAICT it's not that simple to unify them and it's not
"directly" related to the PTE corruption. Please note that there are other
archs(ia64, arm) using these check. But I for sure can be missing something.
What this patch set does is using the existing interface to implement x86 specific
check in the least invasive way.
Anyway I tried to remove the high_memory check with a follow-up patch set 2)
2) x86: allow read/write /dev/mem to access non-system RAM above high_memory
x86: add high_memory check to (xlate|unxlate)_dev_mem_ptr
x86: remove high_memory check from valid_phys_addr_range
This is an attempt to remove the high_memory limit for the read/write access to
/dev/mem. IMHO there is no reason for this limit on x86. It is presented in
the generic valid_phys_addr_range, which is used only by (read|write)_mem. IIUIC
it's main purpose is for the generic xlate_dev_mem_ptr, which is using only the
direct kernel mapping __va translation. Since the valid_phys_addr_range is
called as the first check in (read|write)_mem, it basically does not allow to
access anything above high_memory on x86.
The first patch adds high_memory check to x86's (xlate|unxlate)_dev_mem_ptr, so
the direct kernel mapping can be safely used for system RAM bellow high_memory.
This is IMHO the only valid reason to use high_memory check in (read|write)_mem.
The second patch removes the high_memory check from valid_phys_addr_range,
allowing read/write to access non-system RAM above high_memory. So far this
was possible only by using mmap.
I hope I haven't overlooked something.
Many thanks
Frantisek Hrbata (4):
x86: add arch_pfn_possible helper
x86: add phys addr validity check for /dev/mem mmap
x86: add high_memory check to (xlate|unxlate)_dev_mem_ptr
x86: remove high_memory check from valid_phys_addr_range
arch/x86/include/asm/io.h | 4 ++++
arch/x86/mm/ioremap.c | 9 ++++++---
arch/x86/mm/mmap.c | 12 ++++++++++++
arch/x86/mm/physaddr.h | 9 +++++++--
4 files changed, 29 insertions(+), 5 deletions(-)
--
1.9.3
--
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/
Powered by blists - more mailing lists