create-klp-module: Properly align merged .parainstructions sections #853
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jpoimboe
force-pushed
the
paravirt-alignment-panic
branch
from
aa9f5af to
83529e7
Compare
joe-lawrence
approved these changes
May 18, 2018
kpatch-build/create-klp-module.c
Outdated
| if (!str) | ||
| ERROR("PARA_STRUCT_SIZE not set"); | ||
| align_mask = atoi(str) - 1; | ||
|
|
There was a problem hiding this comment.
Up to you, but you could theoretically cache the align_mask value once you've calculated it to save extra getenv() + atoi() lookups. The surrounding code and the math below looks good to me.
When a patch is composed of multiple .o files which have .parainstructions sections, loading the patch causes a panic: general protection fault: 0000 [#1] SMP Modules linked in: livepatch_4_9_88_1_20180518_1(OK+) livepatch_4_9_88_1_20180510_1(OK) ... CPU: 1 PID: 17257 Comm: insmod Tainted: G O K 4.9.0-6-amd64 #1 Debian 4.9.88-1 Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 11/02/2015 task: ffff9ff3411a4480 task.stack: ffffac8f8271c000 RIP: 0010:[<ffffffff8ae2e1d0>] [<ffffffff8ae2e1d0>] apply_paravirt+0xc0/0x140 RSP: 0018:ffffac8f8271f9a0 EFLAGS: 00010216 RAX: 00010749ffffffff RBX: ffffffffc0940658 RCX: 0000000000000085 RDX: 00000000bfebfbff RSI: ffffac8f8271f9a2 RDI: 0000000000000246 RBP: ffffac8f8271f9a2 R08: 0000000000000085 R09: ffffffff8ae5acb0 R10: 0000000000000001 R11: ffff9ff3544b4400 R12: ffffffffc0940660 R13: 0000000000000000 R14: ffff9ff3544b49c0 R15: ffff9ff3b43f0800 FS: 00007f04c1cea700(0000) GS:ffff9ff3ca640000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000560cfd63e460 CR3: 00000001455c6000 CR4: 0000000000160670 Stack: 401f0ff889486973 6172007172006b00 746c00650031312e 007265746e655f69 74006e6f69007870 ffffac8f006e6f69 00ffac8f8271fa28 ffffffff8b13ae86 ffffac8f8271fa68 ffffffffc09471ec ffffffff8b7da9eb 0000000affffffff Call Trace: [<ffffffff8b13ae86>] ? vsscanf+0x4c6/0x800 [<ffffffff8b13b20e>] ? sscanf+0x4e/0x70 [<ffffffff8ae52be5>] ? arch_klp_init_object_loaded+0x105/0x130 [<ffffffff8b13b0be>] ? vsscanf+0x6fe/0x800 [<ffffffff8b13b20e>] ? sscanf+0x4e/0x70 [<ffffffff8aee29e8>] ? klp_init_object_loaded+0xf8/0x210 [<ffffffff8aee2d85>] ? klp_register_patch+0x285/0x390 [<ffffffffc09491fa>] ? patch_init+0x1fa/0x1000 [livepatch_4_9_88_1_20180518_1] [<ffffffffc0949000>] ? 0xffffffffc0949000 [<ffffffff8ae0218e>] ? do_one_initcall+0x4e/0x180 [<ffffffff8afc87dd>] ? __vunmap+0x6d/0xc0 [<ffffffff8afc87dd>] ? __vunmap+0x6d/0xc0 [<ffffffff8af7eaa1>] ? do_init_module+0x5b/0x1ed [<ffffffff8af025a6>] ? load_module+0x2596/0x2ab0 [<ffffffff8aefed50>] ? __symbol_put+0x60/0x60 [<ffffffff8af02d06>] ? SYSC_finit_module+0xc6/0xf0 [<ffffffff8ae03b7d>] ? do_syscall_64+0x8d/0xf0 [<ffffffff8b41244e>] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6 Code: 8d 7c 05 00 e8 62 f7 ff ff 0f b6 53 f9 48 8b 7b f0 48 89 ee e8 f2 f8 ff ff 49 39 dc 76 57 44 0f b6 43 09 41 80 f8 ff 75 84 0f 0b <48> 8b 10 48 8d 7d 08 48 83 e7 f8 48 89 55 00 89 ca 48 8b 74 10 RIP [<ffffffff8ae2e1d0>] apply_paravirt+0xc0/0x140 RSP <ffffac8f8271f9a0> ---[ end trace 128c0fa6efe85d9e ]--- The panic is caused by a corrupt .klp.arch.vmlinux..parainstructions section: Relocation section [208] '.rela.klp.arch.vmlinux..parainstructions' for section [207] '.klp.arch.vmlinux..parainstructions' at offset 0x29dc78 contains 10 entries: Offset Type Value Addend Name 000000000000000000 X86_64_64 000000000000000000 +750 __get_user_pages 0x0000000000000010 X86_64_64 000000000000000000 +823 __get_user_pages 0x0000000000000020 X86_64_64 000000000000000000 +890 __get_user_pages 0x0000000000000030 X86_64_64 000000000000000000 +941 __get_user_pages 0x0000000000000040 X86_64_64 000000000000000000 +1631 __get_user_pages 0x0000000000000050 X86_64_64 000000000000000000 +1671 __get_user_pages 0x000000000000005c X86_64_64 000000000000000000 +1245 handle_userfault 0x000000000000006c X86_64_64 000000000000000000 +1340 handle_userfault 0x000000000000007c X86_64_64 000000000000000000 +1417 handle_userfault 0x000000000000008c X86_64_64 000000000000000000 +1717 handle_userfault The entries are supposed to be 16 bytes each, but notice they become misaligned starting with the 'handle_userfault' entry. This happens because the kernel linking process lies about the .parainstructions section size, underreporting it by four bytes. So when two .parainstructions sections are merged together, it results in a corrupted .klp.arch.vmlinux..parainstructions section. Fix it by properly aligning the section before merging it with another one. Fixes dynup#852. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
jpoimboe
force-pushed
the
paravirt-alignment-panic
branch
from
83529e7 to
3d04265
Compare
|
v2: put the align_mask in a static variable |
sm00th
approved these changes
May 21, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a patch is composed of multiple .o files which have
.parainstructions sections, loading the patch causes a panic:
general protection fault: 0000 [#1] SMP
Modules linked in: livepatch_4_9_88_1_20180518_1(OK+) livepatch_4_9_88_1_20180510_1(OK) ...
CPU: 1 PID: 17257 Comm: insmod Tainted: G O K 4.9.0-6-amd64 #1 Debian 4.9.88-1
Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 11/02/2015
task: ffff9ff3411a4480 task.stack: ffffac8f8271c000
RIP: 0010:[] [] apply_paravirt+0xc0/0x140
RSP: 0018:ffffac8f8271f9a0 EFLAGS: 00010216
RAX: 00010749ffffffff RBX: ffffffffc0940658 RCX: 0000000000000085
RDX: 00000000bfebfbff RSI: ffffac8f8271f9a2 RDI: 0000000000000246
RBP: ffffac8f8271f9a2 R08: 0000000000000085 R09: ffffffff8ae5acb0
R10: 0000000000000001 R11: ffff9ff3544b4400 R12: ffffffffc0940660
R13: 0000000000000000 R14: ffff9ff3544b49c0 R15: ffff9ff3b43f0800
FS: 00007f04c1cea700(0000) GS:ffff9ff3ca640000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000560cfd63e460 CR3: 00000001455c6000 CR4: 0000000000160670
Stack:
401f0ff889486973 6172007172006b00 746c00650031312e 007265746e655f69
74006e6f69007870 ffffac8f006e6f69 00ffac8f8271fa28 ffffffff8b13ae86
ffffac8f8271fa68 ffffffffc09471ec ffffffff8b7da9eb 0000000affffffff
Call Trace:
[] ? vsscanf+0x4c6/0x800
[] ? sscanf+0x4e/0x70
[] ? arch_klp_init_object_loaded+0x105/0x130
[] ? vsscanf+0x6fe/0x800
[] ? sscanf+0x4e/0x70
[] ? klp_init_object_loaded+0xf8/0x210
[] ? klp_register_patch+0x285/0x390
[] ? patch_init+0x1fa/0x1000 [livepatch_4_9_88_1_20180518_1]
[] ? 0xffffffffc0949000
[] ? do_one_initcall+0x4e/0x180
[] ? __vunmap+0x6d/0xc0
[] ? __vunmap+0x6d/0xc0
[] ? do_init_module+0x5b/0x1ed
[] ? load_module+0x2596/0x2ab0
[] ? __symbol_put+0x60/0x60
[] ? SYSC_finit_module+0xc6/0xf0
[] ? do_syscall_64+0x8d/0xf0
[] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
Code: 8d 7c 05 00 e8 62 f7 ff ff 0f b6 53 f9 48 8b 7b f0 48 89 ee e8 f2 f8 ff ff 49 39 dc 76 57 44 0f b6 43 09 41 80 f8 ff 75 84 0f 0b <48> 8b 10 48 8d 7d 08 48 83 e7 f8 48 89 55 00 89 ca 48 8b 74 10
RIP [] apply_paravirt+0xc0/0x140
RSP
---[ end trace 128c0fa6efe85d9e ]---
The panic is caused by a corrupt .klp.arch.vmlinux..parainstructions
seciton:
Relocation section [208] '.rela.klp.arch.vmlinux..parainstructions' for section [207] '.klp.arch.vmlinux..parainstructions' at offset 0x29dc78 contains 10 entries:
Offset Type Value Addend Name
000000000000000000 X86_64_64 000000000000000000 +750 __get_user_pages
0x0000000000000010 X86_64_64 000000000000000000 +823 __get_user_pages
0x0000000000000020 X86_64_64 000000000000000000 +890 __get_user_pages
0x0000000000000030 X86_64_64 000000000000000000 +941 __get_user_pages
0x0000000000000040 X86_64_64 000000000000000000 +1631 __get_user_pages
0x0000000000000050 X86_64_64 000000000000000000 +1671 __get_user_pages
0x000000000000005c X86_64_64 000000000000000000 +1245 handle_userfault
0x000000000000006c X86_64_64 000000000000000000 +1340 handle_userfault
0x000000000000007c X86_64_64 000000000000000000 +1417 handle_userfault
0x000000000000008c X86_64_64 000000000000000000 +1717 handle_userfault
The entries are supposed to be 16 bytes each, but notice they become
misaligned starting with the 'handle_userfault' entry.
This happens because the kernel linking process lies about the
.parainstructions section size, underreporting it by four bytes. So
when two .parainstructions sections are merged together, it results in a
corrupted .klp.arch.vmlinux..parainstructions section.
Fix it by properly aligning the section before merging it with another
one.
Fixes #852.
Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com