Set CONFIG_VMSPLIT_3G=y in kernel configuration will make the initramfs data lose #1641
Comments
|
The firmware is expecting the kernel to be configured with a 2+2 split so that it can address all available RAM without using HIGHMEM (which we couldn't get to work). Even with HIGHMEM enabled I'm not sure it will work early enough in the boot for initramfs. Try using the |
|
Yes, Without using HIGHMEM, it does work when set ramfsaddr=0x2f000000 or ramfsaddr=0x10000000, or using initramfs ramdisk7.img 0x2f000000. I think it's a little dangerous since I don't known the kernel loading address(loading rule: the default loading address) and the reserved video memory address(the RAM layout seems not document yet). |
|
The kernel is always loaded to 0x8000, so setting the address as you have done is safe. However, it is a bit hacky. As it turns out, we've already restricted the load address for the device tree blob to below 0x30000000 (unless hard coded by the user or the loader stub), and I don't see any reason why we can't do that for the initramfs blob as well - it's just that nobody's asked before. |
|
Can you try this test start.elf for me? It is hard-coded to have gpu_mem set to 128K, but that should be OK for testing. To use it, make a copy of your existing /boot/start.elf then copy this one in its place and reboot, having first ensured that you haven't set Assuming there are no problems I'll get the relevant patch into the next firmware release. |
|
Just let you known, configure kernel with VMSPLIT_3G and without HIGHMEM, and set initramfs to ramdisk7.img followkernel, the initramfs still locate above 0x30000000(with followkernel, the initramfs address should locate at the end of kernel?), here is the kernel message: I will test the new start.elf later. |
|
After using the new start.elf with VMSPLIT_3G and without HIGHMEM, the kernel seems can not boot(there is not kernel message from the serial port), with follow configurations:
NOTE: I always do not use the mkknlimg script just copy the arch/arm/boot/zImage. |
|
All related files can download from https://github.com/brobwind/rpi2b-kernel-issue |
|
Thanks - that was helpful. It seems that loading just below 0x30000000 causes problems, so I've updated the test start.elf to load below 0x2f000000 instead. With that I get serial port output, but I think it then stalls because the rest of my SD card isn't correct. Try the updated start.elf yourself - I hope it will work for you. |
|
It seems these two test start.elf are the same(with the same link address). And have the same sha1sum after downloaded, please help to check again. |
|
The original file had the sha1sum of 90a57a705bdd99f14d859d9f94d1a424e948862f. The new one has a sha1sum of 0a2b6b08bf2ad95e1bb3d81fb8178d0b86a9d800. The link didn't change because I'm using the Google Drive versioning system. |
|
Sorry, my mistake. But the new start.elf(0a2b6b0) still can not boot the kernel, no serial port output. After replace with the old one (firmware @ 8979042), it has the serial port output.
|
|
I started with a clean Raspbian installation, scratched the boot partition and copied your files in then overwrote the start.elf. For some reason it wasn't booting, except when started from our debugger. I've done a clean build, copied it to the card and it boots (to a point, with serial output) from cold, followkernel and an explit 0x2f000000. That version I've now uploaded (direct from the SD card) to the same URL. If that doesn't at least get you some serial output then I'm stumped. |
|
Great job, it can boot now with following configurations:
I also test with Raspberry Pi 3 Model B v1.2, it seems I still need add Thanks |
|
One of the first things the kernel does is to read and internalise the Device Tree blob, after which it no longer needs the memory it occupied. The same happens with initramfs a short while later: So I don't think it matters where we load the DTB and initramfs to, provided it isn't too high (as we've seen) or so low that it collides with the end of the kernel. With a Pi3 you will need Now that the automatic DTB+initramfs placement is limited to the first 768MB you can run with any |
|
You are right. Thank you very much |
kernel: Add Adafruit pitft35 touchscreen support See: raspberrypi/linux#1657 firmware: resize: Add a queue of input images to avoid dropped frames with opaque input firmware: resize: Set the direct_input flag when using mmal opaque mode firmware: arm_loader: Restrict automatic loading to LOWMEM See: raspberrypi/linux#1641 firmware: RaspiVid: Make open_filename() unified for all outputs (video, imv, pts) See: raspberrypi/userland#338
kernel: Add Adafruit pitft35 touchscreen support See: raspberrypi/linux#1657 firmware: resize: Add a queue of input images to avoid dropped frames with opaque input firmware: resize: Set the direct_input flag when using mmal opaque mode firmware: arm_loader: Restrict automatic loading to LOWMEM See: raspberrypi/linux#1641 firmware: RaspiVid: Make open_filename() unified for all outputs (video, imv, pts) See: raspberrypi/userland#338
kernel: Add Adafruit pitft35 touchscreen support See: raspberrypi/linux#1657 firmware: resize: Add a queue of input images to avoid dropped frames with opaque input firmware: resize: Set the direct_input flag when using mmal opaque mode firmware: arm_loader: Restrict automatic loading to LOWMEM See: raspberrypi/linux#1641 firmware: RaspiVid: Make open_filename() unified for all outputs (video, imv, pts) See: raspberrypi/userland#338
- vcimage: Fix detection of coherent addresses after IS_ALIAS_L1L2_NONALLOCATING change See: http://forum.kodi.tv/showthread.php?tid=269814&pid=2435907#pid2435907 - firmware: platform: Remove max_usb_current and default to enabled - firmware: arm_dt: Only mask interrupts for enabled DT nodes See: raspberrypi/linux#1664 - firmware: ISP tuner: Lower rate at fast fps - firmware: resize: Fix for no padding giving incorrect pitch See: https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=162349 - firmware: arm_dt: Populate the /serial-number property See: raspberrypi/linux#1670 - firmware: deinterlace: Provide a mode where frame flags are exclusively used - firmware: arm_loader: do not allow qpu usage when arm owns the 3d See: #669 - firmware: vcinclude: Fix macro for IS_ALIAS_L1L2_NONALLOCATING - firmware: platform: Don't set kernel name explicitly for recovery.elf - firmware: resize: Add a queue of input images to avoid dropped frames with opaque input - firmware: resize: Set the direct_input flag when using mmal opaque mode - firmware: arm_loader: Restrict automatic loading to LOWMEM See: raspberrypi/linux#1641 - firmware: RaspiVid: Make open_filename() unified for all outputs (video, imv, pts) See: raspberrypi/userland#338
kernel: Add Adafruit pitft35 touchscreen support See: raspberrypi/linux#1657 firmware: resize: Add a queue of input images to avoid dropped frames with opaque input firmware: resize: Set the direct_input flag when using mmal opaque mode firmware: arm_loader: Restrict automatic loading to LOWMEM See: raspberrypi/linux#1641 firmware: RaspiVid: Make open_filename() unified for all outputs (video, imv, pts) See: raspberrypi/userland#338
|
Closing due to lack of activity. Reopen if you feel this issue is still relevant. |
If net_assign_generic() fails, the current error path in ops_init() tries to clear the gen pointer slot. Anyway, in such error path, the gen pointer itself has not been modified yet, and the existing and accessed one is smaller than the accessed index, causing an out-of-bounds error: BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320 Write of size 8 at addr ffff888109124978 by task modprobe/1018 CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9f print_address_description.constprop.0+0x86/0x2b5 print_report+0x11b/0x1fb kasan_report+0x87/0xc0 ops_init+0x2de/0x320 register_pernet_operations+0x2e4/0x750 register_pernet_subsys+0x24/0x40 tcf_register_action+0x9f/0x560 do_one_initcall+0xf9/0x570 do_init_module+0x190/0x650 load_module+0x1fa5/0x23c0 __do_sys_finit_module+0x10d/0x1b0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f42518f778d Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cb 56 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007fff96869688 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 00005568ef7f7c90 RCX: 00007f42518f778d RDX: 0000000000000000 RSI: 00005568ef41d796 RDI: 0000000000000003 RBP: 00005568ef41d796 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000 R13: 00005568ef7f7d30 R14: 0000000000040000 R15: 0000000000000000 </TASK> This change addresses the issue by skipping the gen pointer de-reference in the mentioned error-path. Found by code inspection and verified with explicit error injection on a kasan-enabled kernel. Fixes: d266935 ("net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failed") Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/cec4e0f3bb2c77ac03a6154a8508d3930beb5f0f.1674154348.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <[email protected]>
[ Upstream commit 71ab9c3 ] If net_assign_generic() fails, the current error path in ops_init() tries to clear the gen pointer slot. Anyway, in such error path, the gen pointer itself has not been modified yet, and the existing and accessed one is smaller than the accessed index, causing an out-of-bounds error: BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320 Write of size 8 at addr ffff888109124978 by task modprobe/1018 CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9f print_address_description.constprop.0+0x86/0x2b5 print_report+0x11b/0x1fb kasan_report+0x87/0xc0 ops_init+0x2de/0x320 register_pernet_operations+0x2e4/0x750 register_pernet_subsys+0x24/0x40 tcf_register_action+0x9f/0x560 do_one_initcall+0xf9/0x570 do_init_module+0x190/0x650 load_module+0x1fa5/0x23c0 __do_sys_finit_module+0x10d/0x1b0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f42518f778d Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cb 56 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007fff96869688 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 00005568ef7f7c90 RCX: 00007f42518f778d RDX: 0000000000000000 RSI: 00005568ef41d796 RDI: 0000000000000003 RBP: 00005568ef41d796 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000 R13: 00005568ef7f7d30 R14: 0000000000040000 R15: 0000000000000000 </TASK> This change addresses the issue by skipping the gen pointer de-reference in the mentioned error-path. Found by code inspection and verified with explicit error injection on a kasan-enabled kernel. Fixes: d266935 ("net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failed") Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/cec4e0f3bb2c77ac03a6154a8508d3930beb5f0f.1674154348.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 71ab9c3 ] If net_assign_generic() fails, the current error path in ops_init() tries to clear the gen pointer slot. Anyway, in such error path, the gen pointer itself has not been modified yet, and the existing and accessed one is smaller than the accessed index, causing an out-of-bounds error: BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320 Write of size 8 at addr ffff888109124978 by task modprobe/1018 CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9f print_address_description.constprop.0+0x86/0x2b5 print_report+0x11b/0x1fb kasan_report+0x87/0xc0 ops_init+0x2de/0x320 register_pernet_operations+0x2e4/0x750 register_pernet_subsys+0x24/0x40 tcf_register_action+0x9f/0x560 do_one_initcall+0xf9/0x570 do_init_module+0x190/0x650 load_module+0x1fa5/0x23c0 __do_sys_finit_module+0x10d/0x1b0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f42518f778d Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cb 56 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007fff96869688 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 00005568ef7f7c90 RCX: 00007f42518f778d RDX: 0000000000000000 RSI: 00005568ef41d796 RDI: 0000000000000003 RBP: 00005568ef41d796 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000 R13: 00005568ef7f7d30 R14: 0000000000040000 R15: 0000000000000000 </TASK> This change addresses the issue by skipping the gen pointer de-reference in the mentioned error-path. Found by code inspection and verified with explicit error injection on a kasan-enabled kernel. Fixes: d266935 ("net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failed") Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/cec4e0f3bb2c77ac03a6154a8508d3930beb5f0f.1674154348.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Uh oh!
There was an error while loading. Please reload this page.
Hi, I am trying to make the newest Brillo system run on the Raspberry Pi 2 Model B, In the Brillo source code master branch, it suggests add CONFIG_VMSPLIT_3G=y in the kernel configuration(https://android.googlesource.com/device/generic/brillo/+/5b23ce3ee5fecc9f40dad82b03990499237ba686%5E%21/#F0), but while I am trying to do this, the initramfs data in the main memory will lose(I need a initramfs file to boot):
The kernel have such messages:
From these logs, I known:
But while I trying to enable CONFIG_HIGHMEM in kernel, it will cause another kernel crash:
NOTE:
Thanks!
The text was updated successfully, but these errors were encountered: