Good morning,
Le 24/10/2016 à 16:54, Louis Bouchard a écrit :
Hello,
Le 29/09/2016 à 15:34, Louis Bouchard a écrit :
Hello,
Le 23/09/2016 14:04, Atsushi Kumagai a écrit :
Does someone have an idea of where this could come from ?
Thanks for your report, but I'm afraid that I'm going on
vacation till Oct 2.
I hope someone helps you until I'm back.
Regards,
Atsushi Kumagai
As a follow up to my question, I've been investigating the issue. The source of
the problem seems to come from readpage_elf() which tries to read to an
inexistant page :
readpage_elf: Attempt to read non-existent page at 0x1a7b7fff5000.
The error happens when readpage_elf() is called from section_mem_map_addr with
pgaddr, which is derived from paddr. This one comes from :
paddr = vaddr_to_paddr(addr)
When tracing vaddr_to_paddr, I see a difference in the calculation. on a 4.4
kernel :
info->phys_base = 0
On 4.8 :
info->phys_base = 0xffffffffe3800000
So the paddr values used to define pgaddr are :
for 4.4 kernels : 0x3fff4000
for 4.8 kernels : 0x1a7b7fff5000
Running makedumpfile --dump-dmesg in debug mode leads to :
4.4 kernel :
sadump: does not have partition header
sadump: read dump device as unknown format
sadump: unknown format
LOAD (0)
phys_start : 1000000
phys_end : 2224000
virt_start : ffffffff81000000
virt_end : ffffffff82224000
LOAD (1)
phys_start : 1000
phys_end : 9fc00
virt_start : ffff880000001000
virt_end : ffff88000009fc00
LOAD (2)
phys_start : 100000
phys_end : 2b000000
virt_start : ffff880000100000
virt_end : ffff88002b000000
LOAD (3)
phys_start : 33000000
phys_end : 3fffe000
virt_start : ffff880033000000
virt_end : ffff88003fffe000
Linux kdump
page_size : 4096
max_mapnr : 3fffe
Buffer size for the cyclic mode: 65535
num of NODEs : 1
Memory type : SPARSEMEM_EX
mem_map (0)
mem_map : ffffea0000000000
pfn_start : 0
pfn_end : 8000
mem_map (1)
mem_map : ffffea0000200000
pfn_start : 8000
pfn_end : 10000
mem_map (2)
mem_map : ffffea0000400000
pfn_start : 10000
pfn_end : 18000
mem_map (3)
mem_map : ffffea0000600000
pfn_start : 18000
pfn_end : 20000
mem_map (4)
mem_map : ffffea0000800000
pfn_start : 20000
pfn_end : 28000
mem_map (5)
mem_map : ffffea0000a00000
pfn_start : 28000
pfn_end : 30000
mem_map (6)
mem_map : ffffea0000c00000
pfn_start : 30000
pfn_end : 38000
mem_map (7)
mem_map : ffffea0000e00000
pfn_start : 38000
pfn_end : 3fffe
mmap() is available on the kernel.
log_buf : ffffffff8210521c
log_end : 0
log_buf_len : 262144
log_first_idx : 0
log_next_idx : 141176
The dmesg log is saved to /tmp/titi.
makedumpfile Completed.
For 4.8 kernels :
sadump: does not have partition header
sadump: read dump device as unknown format
sadump: unknown format
LOAD (0)
phys_start : 7200000
phys_end : 847d000
virt_start : ffffffffa3a00000
virt_end : ffffffffa4c7d000
LOAD (1)
phys_start : 1000
phys_end : 9fc00
virt_start : ffff880000001000
virt_end : ffff88000009fc00
LOAD (2)
phys_start : 100000
phys_end : 2b000000
virt_start : ffff880000100000
virt_end : ffff88002b000000
LOAD (3)
phys_start : 33000000
phys_end : 3fffe000
virt_start : ffff880033000000
virt_end : ffff88003fffe000
Linux kdump
page_size : 4096
max_mapnr : 3fffe
Buffer size for the cyclic mode: 65535
The kernel version is not supported.
The makedumpfile operation may be incomplete.
num of NODEs : 1
Memory type : SPARSEMEM_EX
mem_map (0)
mem_map : 0
pfn_start : 0
pfn_end : 8000
mem_map (1)
mem_map : 0
pfn_start : 8000
pfn_end : 10000
mem_map (2)
mem_map : 0
pfn_start : 10000
pfn_end : 18000
mem_map (3)
mem_map : 0
pfn_start : 18000
pfn_end : 20000
mem_map (4)
mem_map : 0
pfn_start : 20000
pfn_end : 28000
mem_map (5)
mem_map : 0
pfn_start : 28000
pfn_end : 30000
mem_map (6)
mem_map : 0
pfn_start : 30000
pfn_end : 38000
mem_map (7)
mem_map : 0
pfn_start : 38000
pfn_end : 3fffe
mmap() is available on the kernel.
log_buf : ffffffffa4b3c19c
log_end : 0
log_buf_len : 262144
log_first_idx : 0
log_next_idx : 43160
The dmesg log is saved to /tmp/toto.
makedumpfile Completed.
I don't know if it is to be expected with kernels 4.8 to have all mem_map
addresses set to 0, unlike with k4.4 :
mem_map (0)
mem_map : 0
pfn_start : 0
pfn_end : 8000
Any comment appreciated while I continue to investigate.
Kind regards,
...Louis
I have now completed the kernel bisection between 4.7.8 and 4.8-rc1 and
identified the kernel modification that triggers the errors cited above :
commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
Author: Thomas Garnier <thgar...@google.com>
Date: Tue Jun 21 17:47:03 2016 -0700
x86/mm: Enable KASLR for physical mapping memory regions
Add the physical mapping in the list of randomized memory regions.
The physical memory mapping holds most allocations from boot and heap
allocators. Knowing the base address and physical memory size, an attacker
can deduce the PDE virtual address for the vDSO memory page. This attack
was demonstrated at CanSecWest 2016, in the following presentation:
"Getting Physical: Extreme Abuse of Intel Based Paged Systems":
https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/blob/master/Presentation/CanSec2016_Presentation.pdf
(See second part of the presentation).
The exploits used against Linux worked successfully against 4.6+ but
fail with KASLR memory enabled:
https://github.com/n3k/CansecWest2016_Getting_Physical_Extreme_Abuse_of_Intel_Based_Paging_Systems/tree/master/Demos/Linux/exploits
Similar research was done at Google leading to this patch proposal.
Variants exists to overwrite /proc or /sys objects ACLs leading to
elevation of privileges. These variants were tested against 4.6+.
The page offset used by the compressed kernel retains the static value
since it is not yet randomized during this boot stage.
Signed-off-by: Thomas Garnier <thgar...@google.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
Cc: Alexander Kuleshov <kuleshovm...@gmail.com>
<truncated>
The interesting change seems to be :
-#define __PAGE_OFFSET _AC(0xffff880000000000, UL)
+#define __PAGE_OFFSET_BASE _AC(0xffff880000000000, UL)
+#ifdef CONFIG_RANDOMIZE_MEMORY
+#define __PAGE_OFFSET page_offset_base
+#else
+#define __PAGE_OFFSET __PAGE_OFFSET_BASE
+#endif /* CONFIG_RANDOMIZE_MEMORY */
I'll try to see if I can fix that.
Kind regards,
...Louis
Some more *important* information in this mostly monologue thread : Pratyush
Anand has pushed a patch to the list earlier today that apparently fixes this
issue :
[PATCH Makedumpfile 1/4] x86_64: Calculate page_offset from pt_load[1]
HTH,
Kind regards,
...Louis
[1] https://www.mail-archive.com/kexec@lists.infradead.org/msg16628.html
--
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63 B9C4 8B3D 867C 823E 7A61
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
