* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region @ 2017-04-12 8:26 Ard Biesheuvel 2017-04-12 8:29 ` Alexander Graf 2017-04-12 8:33 ` Domenico Andreoli 0 siblings, 2 replies; 8+ messages in thread From: Ard Biesheuvel @ 2017-04-12 8:26 UTC (permalink / raw) To: linux-arm-kernel When running lscpu on an AArch64 system that has SMBIOS version 2.0 tables, it will segfault in the following way: Unable to handle kernel paging request at virtual address ffff8000bfff0000 pgd = ffff8000f9615000 [ffff8000bfff0000] *pgd=0000000000000000 Internal error: Oops: 96000007 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 task: ffff8000fa78e800 task.stack: ffff8000f9780000 PC is at __arch_copy_to_user+0x90/0x220 LR is at read_mem+0xcc/0x140 This is caused by the fact that lspci issues a read() on /dev/mem at the offset where it expects to find the SMBIOS structure array. However, this region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), and so it is omitted from the linear mapping. So let's restrict /dev/mem read/write access to those areas that are covered by the linear region. Reported-by: Alexander Graf <agraf@suse.de> Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> --- arch/arm64/mm/mmap.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c index 7b0d55756eb1..2956240d17d7 100644 --- a/arch/arm64/mm/mmap.c +++ b/arch/arm64/mm/mmap.c @@ -18,6 +18,7 @@ #include <linux/elf.h> #include <linux/fs.h> +#include <linux/memblock.h> #include <linux/mm.h> #include <linux/mman.h> #include <linux/export.h> @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm) */ int valid_phys_addr_range(phys_addr_t addr, size_t size) { - if (addr < PHYS_OFFSET) - return 0; - if (addr + size > __pa(high_memory - 1) + 1) - return 0; - - return 1; + return memblock_is_map_memory(addr) && + memblock_is_map_memory(addr + size - 1); } /* -- 2.9.3 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region 2017-04-12 8:26 [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region Ard Biesheuvel @ 2017-04-12 8:29 ` Alexander Graf 2017-04-12 8:31 ` Ard Biesheuvel 2017-04-12 8:33 ` Domenico Andreoli 1 sibling, 1 reply; 8+ messages in thread From: Alexander Graf @ 2017-04-12 8:29 UTC (permalink / raw) To: linux-arm-kernel On 12.04.17 10:26, Ard Biesheuvel wrote: > When running lscpu on an AArch64 system that has SMBIOS version 2.0 > tables, it will segfault in the following way: > > Unable to handle kernel paging request at virtual address ffff8000bfff0000 > pgd = ffff8000f9615000 > [ffff8000bfff0000] *pgd=0000000000000000 > Internal error: Oops: 96000007 [#1] PREEMPT SMP > Modules linked in: > CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 > Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 > task: ffff8000fa78e800 task.stack: ffff8000f9780000 > PC is at __arch_copy_to_user+0x90/0x220 > LR is at read_mem+0xcc/0x140 > > This is caused by the fact that lspci issues a read() on /dev/mem at the > offset where it expects to find the SMBIOS structure array. However, this > region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), > and so it is omitted from the linear mapping. > > So let's restrict /dev/mem read/write access to those areas that are > covered by the linear region. > > Reported-by: Alexander Graf <agraf@suse.de> > Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > --- > arch/arm64/mm/mmap.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c > index 7b0d55756eb1..2956240d17d7 100644 > --- a/arch/arm64/mm/mmap.c > +++ b/arch/arm64/mm/mmap.c > @@ -18,6 +18,7 @@ > > #include <linux/elf.h> > #include <linux/fs.h> > +#include <linux/memblock.h> > #include <linux/mm.h> > #include <linux/mman.h> > #include <linux/export.h> > @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm) > */ > int valid_phys_addr_range(phys_addr_t addr, size_t size) > { > - if (addr < PHYS_OFFSET) > - return 0; > - if (addr + size > __pa(high_memory - 1) + 1) > - return 0; > - > - return 1; > + return memblock_is_map_memory(addr) && > + memblock_is_map_memory(addr + size - 1); Is that safe? Are we guaranteed that size is less than one page? Otherwise, someone could map a region that spans over a reserved one: [conv mem] [reserved] [conv mem] Alex ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region 2017-04-12 8:29 ` Alexander Graf @ 2017-04-12 8:31 ` Ard Biesheuvel 2017-04-25 16:46 ` Will Deacon 0 siblings, 1 reply; 8+ messages in thread From: Ard Biesheuvel @ 2017-04-12 8:31 UTC (permalink / raw) To: linux-arm-kernel On 12 April 2017 at 09:29, Alexander Graf <agraf@suse.de> wrote: > > > On 12.04.17 10:26, Ard Biesheuvel wrote: >> >> When running lscpu on an AArch64 system that has SMBIOS version 2.0 >> tables, it will segfault in the following way: >> >> Unable to handle kernel paging request at virtual address >> ffff8000bfff0000 >> pgd = ffff8000f9615000 >> [ffff8000bfff0000] *pgd=0000000000000000 >> Internal error: Oops: 96000007 [#1] PREEMPT SMP >> Modules linked in: >> CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 >> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 >> task: ffff8000fa78e800 task.stack: ffff8000f9780000 >> PC is at __arch_copy_to_user+0x90/0x220 >> LR is at read_mem+0xcc/0x140 >> >> This is caused by the fact that lspci issues a read() on /dev/mem at the >> offset where it expects to find the SMBIOS structure array. However, this >> region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), >> and so it is omitted from the linear mapping. >> >> So let's restrict /dev/mem read/write access to those areas that are >> covered by the linear region. >> >> Reported-by: Alexander Graf <agraf@suse.de> >> Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as >> MEMBLOCK_NOMAP") >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> --- >> arch/arm64/mm/mmap.c | 9 +++------ >> 1 file changed, 3 insertions(+), 6 deletions(-) >> >> diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c >> index 7b0d55756eb1..2956240d17d7 100644 >> --- a/arch/arm64/mm/mmap.c >> +++ b/arch/arm64/mm/mmap.c >> @@ -18,6 +18,7 @@ >> >> #include <linux/elf.h> >> #include <linux/fs.h> >> +#include <linux/memblock.h> >> #include <linux/mm.h> >> #include <linux/mman.h> >> #include <linux/export.h> >> @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm) >> */ >> int valid_phys_addr_range(phys_addr_t addr, size_t size) >> { >> - if (addr < PHYS_OFFSET) >> - return 0; >> - if (addr + size > __pa(high_memory - 1) + 1) >> - return 0; >> - >> - return 1; >> + return memblock_is_map_memory(addr) && >> + memblock_is_map_memory(addr + size - 1); > > > Is that safe? Are we guaranteed that size is less than one page? Otherwise, > someone could map a region that spans over a reserved one: > > [conv mem] > [reserved] > [conv mem] > Well, I will leave it to the maintainers to decide how elaborate they want this logic to become, given that read()ing from /dev/mem is something we are not eager to support in the first place. But indeed, if the start and end of the region are covered by the linear region, there could potentially be an uncovered hole in the middle. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region 2017-04-12 8:31 ` Ard Biesheuvel @ 2017-04-25 16:46 ` Will Deacon 0 siblings, 0 replies; 8+ messages in thread From: Will Deacon @ 2017-04-25 16:46 UTC (permalink / raw) To: linux-arm-kernel On Wed, Apr 12, 2017 at 09:31:38AM +0100, Ard Biesheuvel wrote: > On 12 April 2017 at 09:29, Alexander Graf <agraf@suse.de> wrote: > > > > > > On 12.04.17 10:26, Ard Biesheuvel wrote: > >> > >> When running lscpu on an AArch64 system that has SMBIOS version 2.0 > >> tables, it will segfault in the following way: > >> > >> Unable to handle kernel paging request at virtual address > >> ffff8000bfff0000 > >> pgd = ffff8000f9615000 > >> [ffff8000bfff0000] *pgd=0000000000000000 > >> Internal error: Oops: 96000007 [#1] PREEMPT SMP > >> Modules linked in: > >> CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 > >> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 > >> task: ffff8000fa78e800 task.stack: ffff8000f9780000 > >> PC is at __arch_copy_to_user+0x90/0x220 > >> LR is at read_mem+0xcc/0x140 > >> > >> This is caused by the fact that lspci issues a read() on /dev/mem at the > >> offset where it expects to find the SMBIOS structure array. However, this > >> region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), > >> and so it is omitted from the linear mapping. > >> > >> So let's restrict /dev/mem read/write access to those areas that are > >> covered by the linear region. > >> > >> Reported-by: Alexander Graf <agraf@suse.de> > >> Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as > >> MEMBLOCK_NOMAP") > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > >> --- > >> arch/arm64/mm/mmap.c | 9 +++------ > >> 1 file changed, 3 insertions(+), 6 deletions(-) > >> > >> diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c > >> index 7b0d55756eb1..2956240d17d7 100644 > >> --- a/arch/arm64/mm/mmap.c > >> +++ b/arch/arm64/mm/mmap.c > >> @@ -18,6 +18,7 @@ > >> > >> #include <linux/elf.h> > >> #include <linux/fs.h> > >> +#include <linux/memblock.h> > >> #include <linux/mm.h> > >> #include <linux/mman.h> > >> #include <linux/export.h> > >> @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm) > >> */ > >> int valid_phys_addr_range(phys_addr_t addr, size_t size) > >> { > >> - if (addr < PHYS_OFFSET) > >> - return 0; > >> - if (addr + size > __pa(high_memory - 1) + 1) > >> - return 0; > >> - > >> - return 1; > >> + return memblock_is_map_memory(addr) && > >> + memblock_is_map_memory(addr + size - 1); > > > > > > Is that safe? Are we guaranteed that size is less than one page? Otherwise, > > someone could map a region that spans over a reserved one: > > > > [conv mem] > > [reserved] > > [conv mem] > > > > Well, I will leave it to the maintainers to decide how elaborate they > want this logic to become, given that read()ing from /dev/mem is > something we are not eager to support in the first place. > > But indeed, if the start and end of the region are covered by the > linear region, there could potentially be an uncovered hole in the > middle. I think it would be worth handling that case, even if it means we have to walk over the memblocks which the region overlaps. Will ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region 2017-04-12 8:26 [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region Ard Biesheuvel 2017-04-12 8:29 ` Alexander Graf @ 2017-04-12 8:33 ` Domenico Andreoli 2017-04-12 9:29 ` Russell King - ARM Linux 1 sibling, 1 reply; 8+ messages in thread From: Domenico Andreoli @ 2017-04-12 8:33 UTC (permalink / raw) To: linux-arm-kernel On Wed, Apr 12, 2017 at 09:26:06AM +0100, Ard Biesheuvel wrote: > When running lscpu on an AArch64 system that has SMBIOS version 2.0 > tables, it will segfault in the following way: > > Unable to handle kernel paging request at virtual address ffff8000bfff0000 > pgd = ffff8000f9615000 > [ffff8000bfff0000] *pgd=0000000000000000 > Internal error: Oops: 96000007 [#1] PREEMPT SMP > Modules linked in: > CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 > Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 > task: ffff8000fa78e800 task.stack: ffff8000f9780000 > PC is at __arch_copy_to_user+0x90/0x220 > LR is at read_mem+0xcc/0x140 > > This is caused by the fact that lspci issues a read() on /dev/mem at the > offset where it expects to find the SMBIOS structure array. However, this > region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), > and so it is omitted from the linear mapping. > > So let's restrict /dev/mem read/write access to those areas that are > covered by the linear region. > > Reported-by: Alexander Graf <agraf@suse.de> > Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > --- > arch/arm64/mm/mmap.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c > index 7b0d55756eb1..2956240d17d7 100644 > --- a/arch/arm64/mm/mmap.c > +++ b/arch/arm64/mm/mmap.c > @@ -18,6 +18,7 @@ > > #include <linux/elf.h> > #include <linux/fs.h> > +#include <linux/memblock.h> > #include <linux/mm.h> > #include <linux/mman.h> > #include <linux/export.h> > @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm) > */ > int valid_phys_addr_range(phys_addr_t addr, size_t size) > { > - if (addr < PHYS_OFFSET) > - return 0; > - if (addr + size > __pa(high_memory - 1) + 1) > - return 0; > - > - return 1; > + return memblock_is_map_memory(addr) && > + memblock_is_map_memory(addr + size - 1); > } > > /* Does arch/arm/mm/mmap.c need the same treatment? Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region 2017-04-12 8:33 ` Domenico Andreoli @ 2017-04-12 9:29 ` Russell King - ARM Linux 2017-04-12 9:37 ` Ard Biesheuvel 0 siblings, 1 reply; 8+ messages in thread From: Russell King - ARM Linux @ 2017-04-12 9:29 UTC (permalink / raw) To: linux-arm-kernel On Wed, Apr 12, 2017 at 10:33:43AM +0200, Domenico Andreoli wrote: > On Wed, Apr 12, 2017 at 09:26:06AM +0100, Ard Biesheuvel wrote: > > When running lscpu on an AArch64 system that has SMBIOS version 2.0 > > tables, it will segfault in the following way: > > > > Unable to handle kernel paging request at virtual address ffff8000bfff0000 > > pgd = ffff8000f9615000 > > [ffff8000bfff0000] *pgd=0000000000000000 > > Internal error: Oops: 96000007 [#1] PREEMPT SMP > > Modules linked in: > > CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 > > Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 > > task: ffff8000fa78e800 task.stack: ffff8000f9780000 > > PC is at __arch_copy_to_user+0x90/0x220 > > LR is at read_mem+0xcc/0x140 > > > > This is caused by the fact that lspci issues a read() on /dev/mem at the > > offset where it expects to find the SMBIOS structure array. However, this > > region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), > > and so it is omitted from the linear mapping. > > > > So let's restrict /dev/mem read/write access to those areas that are > > covered by the linear region. > > > > Reported-by: Alexander Graf <agraf@suse.de> > > Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") > > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > --- > > arch/arm64/mm/mmap.c | 9 +++------ > > 1 file changed, 3 insertions(+), 6 deletions(-) > > > > diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c > > index 7b0d55756eb1..2956240d17d7 100644 > > --- a/arch/arm64/mm/mmap.c > > +++ b/arch/arm64/mm/mmap.c > > @@ -18,6 +18,7 @@ > > > > #include <linux/elf.h> > > #include <linux/fs.h> > > +#include <linux/memblock.h> > > #include <linux/mm.h> > > #include <linux/mman.h> > > #include <linux/export.h> > > @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm) > > */ > > int valid_phys_addr_range(phys_addr_t addr, size_t size) > > { > > - if (addr < PHYS_OFFSET) > > - return 0; > > - if (addr + size > __pa(high_memory - 1) + 1) > > - return 0; > > - > > - return 1; > > + return memblock_is_map_memory(addr) && > > + memblock_is_map_memory(addr + size - 1); > > } > > > > /* > > Does arch/arm/mm/mmap.c need the same treatment? high_memory is supposed to be the virtual address of the end of the linearly mapped region. ARM conforms to that. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region 2017-04-12 9:29 ` Russell King - ARM Linux @ 2017-04-12 9:37 ` Ard Biesheuvel 2017-04-12 12:44 ` Domenico Andreoli 0 siblings, 1 reply; 8+ messages in thread From: Ard Biesheuvel @ 2017-04-12 9:37 UTC (permalink / raw) To: linux-arm-kernel On 12 April 2017 at 10:29, Russell King - ARM Linux <linux@armlinux.org.uk> wrote: > On Wed, Apr 12, 2017 at 10:33:43AM +0200, Domenico Andreoli wrote: >> On Wed, Apr 12, 2017 at 09:26:06AM +0100, Ard Biesheuvel wrote: >> > When running lscpu on an AArch64 system that has SMBIOS version 2.0 >> > tables, it will segfault in the following way: >> > >> > Unable to handle kernel paging request at virtual address ffff8000bfff0000 >> > pgd = ffff8000f9615000 >> > [ffff8000bfff0000] *pgd=0000000000000000 >> > Internal error: Oops: 96000007 [#1] PREEMPT SMP >> > Modules linked in: >> > CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 >> > Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 >> > task: ffff8000fa78e800 task.stack: ffff8000f9780000 >> > PC is at __arch_copy_to_user+0x90/0x220 >> > LR is at read_mem+0xcc/0x140 >> > >> > This is caused by the fact that lspci issues a read() on /dev/mem at the >> > offset where it expects to find the SMBIOS structure array. However, this >> > region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), >> > and so it is omitted from the linear mapping. >> > >> > So let's restrict /dev/mem read/write access to those areas that are >> > covered by the linear region. >> > >> > Reported-by: Alexander Graf <agraf@suse.de> >> > Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") >> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> > --- >> > arch/arm64/mm/mmap.c | 9 +++------ >> > 1 file changed, 3 insertions(+), 6 deletions(-) >> > >> > diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c >> > index 7b0d55756eb1..2956240d17d7 100644 >> > --- a/arch/arm64/mm/mmap.c >> > +++ b/arch/arm64/mm/mmap.c >> > @@ -18,6 +18,7 @@ >> > >> > #include <linux/elf.h> >> > #include <linux/fs.h> >> > +#include <linux/memblock.h> >> > #include <linux/mm.h> >> > #include <linux/mman.h> >> > #include <linux/export.h> >> > @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm) >> > */ >> > int valid_phys_addr_range(phys_addr_t addr, size_t size) >> > { >> > - if (addr < PHYS_OFFSET) >> > - return 0; >> > - if (addr + size > __pa(high_memory - 1) + 1) >> > - return 0; >> > - >> > - return 1; >> > + return memblock_is_map_memory(addr) && >> > + memblock_is_map_memory(addr + size - 1); >> > } >> > >> > /* >> >> Does arch/arm/mm/mmap.c need the same treatment? > > high_memory is supposed to be the virtual address of the end of the > linearly mapped region. ARM conforms to that. > Yes, but with UEFI boot, there will be holes in the linear region. This is due to the fact that those regions may have special significance to the firmware, and may be mapped with mismatched attributes. As it happens, the UEFI spec recommends that SMBIOS tables (which only have significance to the OS) are covered by a EFI_RUNTIME_SERVICE_DATA region, which is one of the types we mark MEMBLOCK_NOMAP, and omit from the linear region. So when lspcu goes looking for the SMBIOS tables, using the read() interface to /dev/mem, it will dereference a physical pointer into an unmapped region. This will undoubtedly produce a similar result to the above if we don't account for NOMAP regions. However, we have no DMI/SMBIOS support yet for ARM (nor ACPI support), so this particular issue does not exist on ARM atm. But read() calls to /dev/mem may indeed provoke a similar splat when (ab)used in a similar manner. -- Ard. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region 2017-04-12 9:37 ` Ard Biesheuvel @ 2017-04-12 12:44 ` Domenico Andreoli 0 siblings, 0 replies; 8+ messages in thread From: Domenico Andreoli @ 2017-04-12 12:44 UTC (permalink / raw) To: linux-arm-kernel On Wed, Apr 12, 2017 at 10:37:46AM +0100, Ard Biesheuvel wrote: > On 12 April 2017 at 10:29, Russell King - ARM Linux > <linux@armlinux.org.uk> wrote: > > On Wed, Apr 12, 2017 at 10:33:43AM +0200, Domenico Andreoli wrote: > >> On Wed, Apr 12, 2017 at 09:26:06AM +0100, Ard Biesheuvel wrote: > >> > When running lscpu on an AArch64 system that has SMBIOS version 2.0 > >> > tables, it will segfault in the following way: > >> > > >> > Unable to handle kernel paging request at virtual address ffff8000bfff0000 > >> > pgd = ffff8000f9615000 > >> > [ffff8000bfff0000] *pgd=0000000000000000 > >> > Internal error: Oops: 96000007 [#1] PREEMPT SMP > >> > Modules linked in: > >> > CPU: 0 PID: 1284 Comm: lscpu Not tainted 4.11.0-rc3+ #103 > >> > Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 > >> > task: ffff8000fa78e800 task.stack: ffff8000f9780000 > >> > PC is at __arch_copy_to_user+0x90/0x220 > >> > LR is at read_mem+0xcc/0x140 > >> > > >> > This is caused by the fact that lspci issues a read() on /dev/mem at the > >> > offset where it expects to find the SMBIOS structure array. However, this > >> > region is classified as EFI_RUNTIME_SERVICE_DATA (as per the UEFI spec), > >> > and so it is omitted from the linear mapping. > >> > > >> > So let's restrict /dev/mem read/write access to those areas that are > >> > covered by the linear region. > >> > > >> > Reported-by: Alexander Graf <agraf@suse.de> > >> > Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") > >> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> > >> > --- > >> > arch/arm64/mm/mmap.c | 9 +++------ > >> > 1 file changed, 3 insertions(+), 6 deletions(-) > >> > > >> > diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c > >> > index 7b0d55756eb1..2956240d17d7 100644 > >> > --- a/arch/arm64/mm/mmap.c > >> > +++ b/arch/arm64/mm/mmap.c > >> > @@ -18,6 +18,7 @@ > >> > > >> > #include <linux/elf.h> > >> > #include <linux/fs.h> > >> > +#include <linux/memblock.h> > >> > #include <linux/mm.h> > >> > #include <linux/mman.h> > >> > #include <linux/export.h> > >> > @@ -103,12 +104,8 @@ void arch_pick_mmap_layout(struct mm_struct *mm) > >> > */ > >> > int valid_phys_addr_range(phys_addr_t addr, size_t size) > >> > { > >> > - if (addr < PHYS_OFFSET) > >> > - return 0; > >> > - if (addr + size > __pa(high_memory - 1) + 1) > >> > - return 0; > >> > - > >> > - return 1; > >> > + return memblock_is_map_memory(addr) && > >> > + memblock_is_map_memory(addr + size - 1); > >> > } > >> > > >> > /* > >> > >> Does arch/arm/mm/mmap.c need the same treatment? > > > > high_memory is supposed to be the virtual address of the end of the > > linearly mapped region. ARM conforms to that. > > > > Yes, but with UEFI boot, there will be holes in the linear region. > This is due to the fact that those regions may have special > significance to the firmware, and may be mapped with mismatched > attributes. > > As it happens, the UEFI spec recommends that SMBIOS tables (which only > have significance to the OS) are covered by a EFI_RUNTIME_SERVICE_DATA > region, which is one of the types we mark MEMBLOCK_NOMAP, and omit > from the linear region. > > So when lspcu goes looking for the SMBIOS tables, using the read() > interface to /dev/mem, it will dereference a physical pointer into an > unmapped region. This will undoubtedly produce a similar result to the > above if we don't account for NOMAP regions. > > However, we have no DMI/SMBIOS support yet for ARM (nor ACPI support), > so this particular issue does not exist on ARM atm. But read() calls > to /dev/mem may indeed provoke a similar splat when (ab)used in a > similar manner. I was exactly thinking at this last abuse indeed. Maybe other archs are affected. thanks, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-04-25 16:46 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-12 8:26 [PATCH] arm64: kernel: restrict /dev/mem read() calls to linear region Ard Biesheuvel 2017-04-12 8:29 ` Alexander Graf 2017-04-12 8:31 ` Ard Biesheuvel 2017-04-25 16:46 ` Will Deacon 2017-04-12 8:33 ` Domenico Andreoli 2017-04-12 9:29 ` Russell King - ARM Linux 2017-04-12 9:37 ` Ard Biesheuvel 2017-04-12 12:44 ` Domenico Andreoli
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.