From: Nicolai Stange <nicstange@gmail.com>
To: Valdis.Kletnieks@vt.edu
Cc: Andy Lutomirski <luto@kernel.org>,
kernel-hardening@lists.openwall.com, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Borislav Petkov <bp@alien8.de>, Nadav Amit <nadav.amit@gmail.com>,
Kees Cook <keescook@chromium.org>,
Brian Gerst <brgerst@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Josh Poimboeuf <jpoimboe@redhat.com>, Jann Horn <jann@thejh.net>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [kernel-hardening] [PATCH v5 03/32] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated
Date: Sat, 23 Jul 2016 16:58:16 +0200 [thread overview]
Message-ID: <87mvl8tn93.fsf@gmail.com> (raw)
In-Reply-To: <8376.1469251283@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Sat, 23 Jul 2016 01:21:23 -0400")
Valdis.Kletnieks@vt.edu writes:
> On Thu, 21 Jul 2016 22:34:33 -0700, Andy Lutomirski said:
>
>> How much memory do you have and what's your config? My code is
>> obviously buggy, but I'm wondering why neither I nor the 0day bot caught
>> this.
>
> Probably because your devel box and the 0day bot both have 4-level page
> tables and the dual-core i5 in my laptop has (presumably) 3?
>
> In any case, your patch didn't fix things, nor did (as you noted in a mail
> to Ingo) does reverting the problem commit (and then the following one that
> deletes now-dead code so it will compile cleanly).
Applying the patch directly on top of 360cb4d15567 ("x86/mm/cpa: In
populate_pgd(), don't set the PGD entry until it's populated") *does*
fix things for me.
Hardware: i7-4800MQ, 8GiB RAM, Dell Latitude E6540
FYI, the kernel panic grabbed via console=uart,io,0x3f8,... is
BUG: unable to handle kernel paging request at ffffb92ac0000fc0
IP: [<ffffffff8106b8d1>] native_set_pmd+0x1/0x10
PGD 0
Oops: 0002 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-rc6+ #190
Hardware name: Dell Inc. Latitude E6540/0725FP, BIOS A10 06/26/2014
task: ffffffff81e0d580 ti: ffffffff81e00000 task.ti: ffffffff81e00000
RIP: 0010:[<ffffffff8106b8d1>] [<ffffffff8106b8d1>] native_set_pmd+0x1/0x10
RSP: 0000:ffffffff81e03c38 EFLAGS: 00010206
RAX: 00000000ff0000f3 RBX: 00000000ff000000 RCX: ffff880000000000
RDX: ffffb92ac0000fc0 RSI: 00000000ff0000f3 RDI: ffffb92ac0000fc0
RBP: ffffffff81e03c90 R08: ffff880000000fc0 R09: 0000000000000073
R10: ffff88022ede5000 R11: 0000000000000001 R12: ffffffff81e03e48
R13: 0000000001000000 R14: 0000000000000073 R15: ffff880000000018
FS: 0000000000000000(0000) GS:ffff88022ea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffb92ac0000fc0 CR3: 0000000001e06000 CR4: 00000000000406b0
Stack:
ffffffff81e03c90 ffffffff8107217f 0000000000000073 0000000100000000
0000000000000001 0000000000001000 ffff880000000018 0000000000001000
ffffffff81e03e48 0000000100000000 ffffffffff2018a8 ffffffff81e03d08
Call Trace:
[<ffffffff8107217f>] ? populate_pmd+0x11f/0x2c0
[<ffffffff81072823>] __cpa_process_fault+0x503/0x5d0
[<ffffffff81073223>] __change_page_attr_set_clr+0x563/0xe00
[<ffffffff81074e6f>] kernel_map_pages_in_pgd+0x8f/0xd0
[<ffffffff81fa5e2e>] __map_region+0x3c/0x58
[<ffffffff81fa6064>] efi_map_region+0x31/0xca
[<ffffffff81fa5af3>] efi_enter_virtual_mode+0x215/0x4bd
[<ffffffff814c6289>] ? acpi_os_signal_semaphore+0x2c/0x38
[<ffffffff814f5c4a>] ? acpi_ut_initialize_interfaces+0x62/0x67
[<ffffffff81f84f78>] start_kernel+0x3cf/0x478
[<ffffffff81f84120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81f842db>] x86_64_start_reservations+0x2f/0x31
[<ffffffff81f84429>] x86_64_start_kernel+0x14c/0x16f
Code: 89 e5 48 89 47 04 5d c3 66 90 55 48 89 e5 0f 01 f8 5d c3 0f 1f 80 00 00 00 00 55 48 89 37 48 89 e5 5d c3 0f 1f 80 00 00 00 00 55 <48> 89 37 48 89 e5 5d c3 0f 1f 80 00 00 00 00 55 48 89 37 48 89
RIP [<ffffffff8106b8d1>] native_set_pmd+0x1/0x10
RSP <ffffffff81e03c38>
CR2: ffffb92ac0000fc0
---[ end trace 2f8154f277751049 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!
The reason the patch didn't work for Valdis might be that there is
another issue in next-20150722 with the same symptoms (provided you
don't watch the serial console). Valdis, did you apply the provided
patch on top of next?
The "other issue" is:
RDX: 0000000000000010 RSI: 00000000000306c3 RDI: ffff88003bdea2fc
RBP: ffffffffb6e03a70 R08: ffff88003bdea000 R09: 0000000000000000
R10: ffffffffb713d3a0 R11: 0000000000000008 R12: 0000000000000020
R13: ffff88003bdea2fc R14: ffffffffb6e03a80 R15: ffffffffb6e03ea0
FS: 0000000000000000(0000) GS:ffff9208aea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff88003bdea300 CR3: 00000001dce06000 CR4: 00000000000406b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Stack:
ffffffffb6054cea 0000000000000000 0000000100000000 0000000000000001
0000000000000000 0000000000000000 ffffffffb705c2e0 000000003fffc000
ffffffffb6e03e90 ffffffffb6055487 ffff88003bdea2fc ffffffffb6e0d580
Call Trace:
[<ffffffffb6054cea>] ? find_microcode_patch+0x4a/0xa0
[<ffffffffb6055487>] load_microcode.isra.1.constprop.12+0x37/0xa0
[<ffffffffb6036700>] ? dump_trace+0x120/0x320
[<ffffffffb644fee8>] ? put_dec+0x18/0xa0
[<ffffffffb645025d>] ? number+0x2ed/0x300
[<ffffffffb6ff3ba1>] ? serial_putc+0x1e/0x2d
[<ffffffffb6ff3b83>] ? serial8250_early_out+0x62/0x62
[<ffffffffb654f127>] ? uart_console_write+0x57/0x70
[<ffffffffb61094ad>] ? trace_hardirqs_off+0xd/0x10
[<ffffffffb6152775>] ? __module_address+0x5/0xf0
[<ffffffffb6152872>] ? __module_text_address+0x12/0x60
[<ffffffffb61967e4>] ? is_ftrace_trampoline+0x44/0x70
[<ffffffffb60d68a6>] ? __kernel_text_address+0x56/0x70
[<ffffffffb60371bb>] ? print_context_stack+0x7b/0x100
[<ffffffffb6109695>] ? __bfs+0x25/0x280
[<ffffffffb61967e4>] ? is_ftrace_trampoline+0x44/0x70
[<ffffffffb6152775>] ? __module_address+0x5/0xf0
[<ffffffffb6152872>] ? __module_text_address+0x12/0x60
[<ffffffffb61967e4>] ? is_ftrace_trampoline+0x44/0x70
[<ffffffffb60d68a6>] ? __kernel_text_address+0x56/0x70
[<ffffffffb60371bb>] ? print_context_stack+0x7b/0x100
[<ffffffffb6036700>] ? dump_trace+0x120/0x320
[<ffffffffb644fee8>] ? put_dec+0x18/0xa0
[<ffffffffb645025d>] ? number+0x2ed/0x300
[<ffffffffb6ff3ba1>] ? serial_putc+0x1e/0x2d
[<ffffffffb6ff3b83>] ? serial8250_early_out+0x62/0x62
[<ffffffffb654f127>] ? uart_console_write+0x57/0x70
[<ffffffffb61094ad>] ? trace_hardirqs_off+0xd/0x10
[<ffffffffb61094ad>] ? trace_hardirqs_off+0xd/0x10
[<ffffffffb689de84>] ? _raw_spin_unlock_irqrestore+0x54/0x60
[<ffffffffb611f16d>] ? console_unlock+0x33d/0x670
[<ffffffffb611f7a1>] ? vprintk_emit+0x301/0x5e0
[<ffffffffb605553f>] ? collect_cpu_info_early+0x4f/0x140
[<ffffffffb61ea845>] ? __pr_info+0x5a/0x76
[<ffffffffb60557cd>] load_ucode_intel_ap+0x5d/0x80
[<ffffffffb6054924>] load_ucode_ap+0x94/0xa0
[<ffffffffb60481a8>] cpu_init+0x58/0x3e0
[<ffffffffb60709bc>] ? set_pte_vaddr+0x5c/0x90
[<ffffffffb6fac06c>] trap_init+0x2b6/0x328
[<ffffffffb6fa0dba>] start_kernel+0x224/0x47f
[<ffffffffb6fa0120>] ? early_idt_handler_array+0x120/0x120
[<ffffffffb6fa02cf>] x86_64_start_reservations+0x29/0x2b
[<ffffffffb6fa041e>] x86_64_start_kernel+0x14d/0x170
Code: c1 74 04 85 c2 74 e4 b8 01 00 00 00 5d c3 41 89 ca b8 01 00 00 00 41 09 d2 74 f1 85 d1 74 98 5d c3 31 c0 5d c3 90 e8 eb b1 84 00 <39> 4f 04 77 03 31 c0 c3 55 48 89 e5 e8 6a ff ff ff 5d c3 0f 1f
RIP [<ffffffffb6055af5>] has_newer_microcode+0x5/0x20
RSP <ffffffffb6e03a30>
CR2: ffff88003bdea300
---[ end trace b163fd3960fd46fb ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!
I bisected this one to 21ef9a5c3164 ("Merge branch 'x86/microcode'"). Both
of its parents do not exhibit that behaviour. This merge's author is
Ingo Molnar, so I added him to the CC list.
Thanks,
Nicolai
next prev parent reply other threads:[~2016-07-23 14:58 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-11 20:53 [PATCH v5 00/32] virtually mapped stacks and thread_info cleanup Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 01/32] bluetooth: Switch SMP to crypto_cipher_encrypt_one() Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-14 19:10 ` Andy Lutomirski
2016-07-14 19:10 ` Andy Lutomirski
2016-07-14 20:30 ` Marcel Holtmann
2016-07-14 20:30 ` Marcel Holtmann
2016-07-14 20:41 ` David Miller
2016-07-11 20:53 ` [PATCH v5 02/32] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable() Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 03/32] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated Andy Lutomirski
2016-07-22 4:43 ` Valdis.Kletnieks
2016-07-22 4:43 ` [kernel-hardening] " Valdis.Kletnieks
2016-07-22 5:34 ` Andy Lutomirski
2016-07-22 5:34 ` Andy Lutomirski
2016-07-22 10:18 ` Mike Krinkin
2016-07-22 10:21 ` Ingo Molnar
2016-07-22 18:21 ` Andy Lutomirski
2016-07-22 18:31 ` Andy Lutomirski
2016-07-22 20:11 ` Ingo Molnar
2016-07-22 20:11 ` [kernel-hardening] " Ingo Molnar
2016-07-23 5:21 ` Valdis.Kletnieks
2016-07-23 14:58 ` Nicolai Stange [this message]
2016-07-28 9:26 ` Valdis.Kletnieks
2016-07-28 9:26 ` [kernel-hardening] " Valdis.Kletnieks
[not found] ` <cover.1468270393.git.luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2016-07-11 20:53 ` [PATCH v5 04/32] x86/mm: Remove kernel_unmap_pages_in_pgd() and efi_cleanup_page_tables() Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 05/32] mm: Track NR_KERNEL_STACK in KiB instead of number of stacks Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 06/32] mm: Fix memcg stack accounting for sub-page stacks Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 07/32] fork: Add generic vmalloced stack support Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 08/32] dma-api: Teach the "DMA-from-stack" check about vmapped stacks Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 09/32] x86/dumpstack: When OOPSing, rewind the stack before do_exit() Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 10/32] x86/dumpstack: Honor supplied @regs arg Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 11/32] x86/dumpstack: Try harder to get a call trace on stack overflow Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 12/32] x86/dumpstack/64: Handle faults when printing the "Stack:" part of an OOPS Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 13/32] x86/mm/64: In vmalloc_fault(), use CR3 instead of current->active_mm Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-12 17:51 ` [kernel-hardening] " Dave Hansen
2016-07-12 17:51 ` Dave Hansen
2016-07-12 18:03 ` Andy Lutomirski
2016-07-12 18:03 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 14/32] x86/mm/64: Enable vmapped stacks Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-13 7:53 ` Ingo Molnar
2016-07-13 18:42 ` Andy Lutomirski
2016-07-13 18:42 ` Andy Lutomirski
2016-07-14 8:34 ` Ingo Molnar
2016-07-14 8:34 ` Ingo Molnar
2016-07-14 16:51 ` Andy Lutomirski
2016-07-14 18:45 ` Ingo Molnar
2016-07-11 20:53 ` [PATCH v5 15/32] x86/mm: Improve stack-overflow #PF handling Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 16/32] x86: Move uaccess_err and sig_on_uaccess_err to thread_struct Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 17/32] x86: Move addr_limit " Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 18/32] signal: Consolidate {TS,TLF}_RESTORE_SIGMASK code Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-12 11:57 ` Brian Gerst
2016-07-12 11:57 ` Brian Gerst
2016-07-12 23:01 ` Andy Lutomirski
2016-07-12 23:01 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 19/32] x86/smp: Remove stack_smp_processor_id() Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 20/32] x86/smp: Remove unnecessary initialization of thread_info::cpu Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 21/32] x86/asm: Move 'status' from struct thread_info to struct thread_struct Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 22/32] kdb: Use task_cpu() instead of task_thread_info()->cpu Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 23/32] printk: When dumping regs, show the stack, not thread_info Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 24/32] x86/entry: Get rid of pt_regs_to_thread_info() Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 25/32] um: Stop conflating task_struct::stack with thread_info Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:53 ` [PATCH v5 26/32] sched: Allow putting thread_info into task_struct Andy Lutomirski
2016-07-11 20:53 ` Andy Lutomirski
2016-07-11 20:54 ` [PATCH v5 27/32] x86: Move " Andy Lutomirski
2016-07-11 20:54 ` Andy Lutomirski
2016-07-11 20:54 ` [PATCH v5 28/32] sched: Add try_get_task_stack() and put_task_stack() Andy Lutomirski
2016-07-11 20:54 ` Andy Lutomirski
2016-07-11 20:54 ` [PATCH v5 29/32] kthread: to_live_kthread() needs try_get_task_stack() Andy Lutomirski
2016-07-11 20:54 ` Andy Lutomirski
2016-07-11 20:54 ` [PATCH v5 30/32] x86/dumpstack: Pin the target stack in save_stack_trace_tsk() Andy Lutomirski
2016-07-11 20:54 ` Andy Lutomirski
2016-07-11 20:54 ` [PATCH v5 31/32] sched: Free the stack early if CONFIG_THREAD_INFO_IN_TASK Andy Lutomirski
2016-07-11 20:54 ` Andy Lutomirski
2016-07-11 20:54 ` [PATCH v5 32/32] fork: Cache two thread stacks per cpu if CONFIG_VMAP_STACK is set Andy Lutomirski
2016-07-11 20:54 ` Andy Lutomirski
2016-07-12 8:56 ` [PATCH v5 00/32] virtually mapped stacks and thread_info cleanup Herbert Xu
2016-07-12 8:56 ` Herbert Xu
2016-07-13 8:54 ` Christian Borntraeger
2016-07-13 8:54 ` Christian Borntraeger
2016-07-13 18:36 ` Andy Lutomirski
2016-07-13 18:36 ` Andy Lutomirski
2016-07-13 18:53 ` Christian Borntraeger
2016-07-13 18:53 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mvl8tn93.fsf@gmail.com \
--to=nicstange@gmail.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jann@thejh.net \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=nadav.amit@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).