On Tue, 9 Feb 2016 10:10:03 +0100
Ingo Molnar <mingo(a)kernel.org> wrote:
* Toshi Kani <toshi.kani(a)hpe.com> wrote:
> Since 4.1, ioremap() supports large page (pud/pmd) mappings in
> x86_64 and PAE. vmalloc_fault() however assumes that the vmalloc
> range is limited to pte mappings.
>
> pgd_ctor() sets the kernel's pgd entries to user's during fork(),
> which makes user processes share the same page tables for the
> kernel ranges. When a call to ioremap() is made at run-time that
> leads to allocate a new 2nd level table (pud in 64-bit and pmd in
> PAE), user process needs to re-sync with the updated kernel pgd
> entry with vmalloc_fault().
>
> Following changes are made to vmalloc_fault().
So what were the effects of this shortcoming? Were large page
ioremap()s unusable? Was this harmless because no driver used this
facility?
Drivers do use huge ioremap()s. Now if a pre-existing mm is used to
access the device memory a #PF and the call to vmalloc_fault would
eventually make the kernel treat device memory as if it was a
pagetable.
The results are illegal reads/writes on iomem and dereferencing iomem
content like it was a pointer to a lower level pagetable.
- #PF if you are lucky
- funny modification of arbitrary memory possible
- can be abused with uio or regular userland ??
Henning
If so then the changelog needs to spell this out clearly ...
Thanks,
Ingo