Closed ttg-public closed 3 years ago
With kernel4 for DSM6 i already have the crash with early_setup. Only the kernel3 loaders are working while they dont do a reinit. When i disable reinit for DS918 in platform.h all is working.
[ 3.584374] <redpill/runtime_config.c:159> Runtime config populated
[ 3.587588] <redpill/call_protected.c:81> Got addr ffffffff818ba4e0 for early_serial_setup
[ 3.588433] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[ 3.589185] BUG: unable to handle kernel paging request at ffffffff818ba4e0
[ 3.589422] IP: [<ffffffff818ba4e0>] early_serial_setup+0x0/0x13e
[ 3.589422] PGD 180d067 PUD 180e063 PMD 7d05c063 PTE 80000000018ba163
[ 3.589422] Oops: 0011 [#1] PREEMPT SMP
[ 3.589422] Modules linked in: redpill(OE+)
[ 3.589422] CPU: 1 PID: 3406 Comm: insmod Tainted: G OE 4.4.59+ #25556
[ 3.589422] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 3.589422] task: ffff88007c8cf3c0 ti: ffff880035178000 task.ti: ffff880035178000
[ 3.589422] RIP: 0010:[<ffffffff818ba4e0>] [<ffffffff818ba4e0>] early_serial_setup+0x0/0x13e
[ 3.589422] RSP: 0018:ffff88003517bb28 EFLAGS: 00010286
[ 3.589422] RAX: ffffffff818ba4e0 RBX: ffff88003517bb48 RCX: 0000000000000000
[ 3.589422] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff88003517bb48
[ 3.589422] RBP: ffff88003517bb38 R08: 6c6c69706465723c R09: 5f6c6c61632f6c6c
[ 3.589422] R10: ffffffff817154ee R11: 65746365746f7270 R12: ffffffffa0007dd0
[ 3.589422] R13: 0000000000000000 R14: ffffffffa0012000 R15: ffff88007d218340
[ 3.589422] FS: 00007ff05f0b0700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
[ 3.589422] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.589422] CR2: ffffffff818ba4e0 CR3: 000000003608b000 CR4: 00000000000006f0
[ 3.589422] Stack:
[ 3.589422] ffffffffa00010e9 0000000000000000 ffff88003517bcc0 ffffffffa0007473
[ 3.589422] 0000000000000000 00000000000003f8 0000000000000000 0000000000000000
[ 3.589422] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 3.589422] Call Trace:
[ 3.589422] [<ffffffffa00010e9>] ? _early_serial_setup+0x19/0xa0 [redpill]
[ 3.589422] [<ffffffffa0007473>] fix_muted_ttyS0+0x53/0xd0 [redpill]
[ 3.589422] [<ffffffffa000753e>] register_uart_fixer+0x1e/0xa0 [redpill]
[ 3.589422] [<ffffffffa001207f>] init_redpill+0x7f/0x151 [redpill]
[ 3.589422] [<ffffffff810003b6>] do_one_initcall+0x86/0x1b0
[ 3.589422] [<ffffffff810e32f4>] do_init_module+0x56/0x1c2
[ 3.589422] [<ffffffff810b9129>] load_module+0x1b29/0x2020
[ 3.589422] [<ffffffff810b6860>] ? __symbol_put+0x50/0x50
[ 3.589422] [<ffffffff810b971f>] SYSC_init_module+0xff/0x110
[ 3.589422] [<ffffffff810b97b9>] SyS_init_module+0x9/0x10
[ 3.589422] [<ffffffff81578b8a>] entry_SYSCALL_64_fastpath+0x1e/0x92
[ 3.589422] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc <cc> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[ 3.589422] RIP [<ffffffff818ba4e0>] early_serial_setup+0x0/0x13e
[ 3.589422] RSP <ffff88003517bb28>
[ 3.589422] CR2: ffffffff818ba4e0
[ 3.589422] ---[ end trace 140e8d9d14363746 ]---
Killed
Hm, so it seems to be even worse - it's install dependent as to when early_serial_setup()
is removed. Technically we can expect that because kernel has all the rights to remove it after boot but it somehow worked for years (and in fact Jun's loader used the same method as there aren't many options).
Juns loader 1.04 works fine with the same virtual Machine. Strange.
The thing is the early_serial_setip()
CAN be removed but doesn't HAVE TO be removed. It's a combination of decision based on compiler and machine characteristics and sometimes even on the pseudo-random factors during boot.
In the newer compilation of the kernel (starting with 6.2.4) they modified the init process by adding some of their own flags to it (the boot_header
chain of trust). This shifted the code just enough to mess up Jun's ELF patching for ramdisk and also cause early_serial_setup()
to be removed. The one trick which we will try is to load as a fake I/O scheduler which loads quite much earlier, which drastically increases the chance of early_serial_setup()
still being available in memory ;)
Aug 14 20:13:21 kernel: [ 3.197447] <redpill/runtime_config.c:172> Config validation resulted in OK
Aug 14 20:13:21 kernel: [ 3.198476] <redpill/runtime_config.c:189> Runtime config populated
Aug 14 20:13:21 kernel: [ 3.201491] <redpill/call_protected.c:85> Got addr ffffffff81928292 for early_serial_setup
Aug 14 20:13:21 kernel: [ 3.202721] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
Aug 14 20:13:21 kernel: [ 3.203712] BUG: unable to handle kernel paging request at ffffffff81928292
Aug 14 20:13:21 kernel: [ 3.203712] IP: [
We disabled it for now - https://github.com/RedPill-TTG/redpill-lkm/commit/afe20e47011d260921ca1cd2202a4df0210628df
The least invasive solution we can cobble together would be to try loading RP as I/O scheduler as - if we're reading the kernel code correctly - should ensure it executes just milliseconds before early_serial_setup
is removed from memory.
This is no longer an issue due to the following commits:
See discussion in https://github.com/RedPill-TTG/redpill-lkm/commit/c390f74e48bbe87ecc7ff898402cd87dc4d62f38#comments
cc @semool @jumkey