#4 [Coreboot] memstick.img not booting

Closed
opened 5 months ago by bob12 · 7 comments
bob12 commented 5 months ago

Hi,

I tried to install HardenedBSD on a Corebooted machine (using SeaBIOS payload) and it seems that the installer just won’t boot at all. With the 12.x version of the installer hangs just after ‘/boot/entropy size=0x1000’, and with the 11.x version it hangs after ‘Booting...'.

I tried to disable ACPI and enable Verbose in boot options, with similar result.
Windows, Linux, and OpenBSD boot just fine on this machine.

Does someone have an idea on how to fix this ?

Thank you

Hi, I tried to install HardenedBSD on a Corebooted machine (using SeaBIOS payload) and it seems that the installer just won't boot at all. With the 12.x version of the installer hangs just after '/boot/entropy size=0x1000', and with the 11.x version it hangs after 'Booting...'. I tried to disable ACPI and enable Verbose in boot options, with similar result. Windows, Linux, and OpenBSD boot just fine on this machine. Does someone have an idea on how to fix this ? Thank you
shawn.webb commented 5 months ago
Owner

I’ll take a look soon. What make/model of system are you attempting to boot from?

I'll take a look soon. What make/model of system are you attempting to boot from?
shawn.webb self-assigned this 5 months ago
shawn.webb added the
bug
label 5 months ago
shawn.webb added the
question
label 5 months ago
bob12 commented 5 months ago
Poster

Hello, I’m using a T440p with Coreboot 4.11

Hello, I'm using a T440p with Coreboot 4.11
bob12 commented 5 months ago
Poster

It seems that it’s a graphic issue, I tried various combinations of Coreboot settings and here are the results :

GENERIC_LINEAR_FRAMEBUFFER (Linear “high-resolution” framebuffer) : no display at all

VGA_TEXT_FRAMEBUFFER (Legacy VGA text mode) : display, but with altered colors

It seems that it's a graphic issue, I tried various combinations of Coreboot settings and here are the results : GENERIC_LINEAR_FRAMEBUFFER (Linear "high-resolution" framebuffer) : no display at all VGA_TEXT_FRAMEBUFFER (Legacy VGA text mode) : display, but with altered colors
1.9 MiB
shawn.webb commented 5 months ago
Owner

Can you try with the most recent FreeBSD 12-STABLE snapshot? https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-March/000678.html

Can you try with the most recent FreeBSD 12-STABLE snapshot? https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-March/000678.html
bob12 commented 5 months ago
Poster

Sure, the exact same issue exists with the FreeBSD 12 snapshot

Sure, the exact same issue exists with the FreeBSD 12 snapshot
shawn.webb commented 5 months ago
Owner

Cool. That means that the issue is with upstream FreeBSD. Can you file a bug report there?

Cool. That means that the issue is with upstream FreeBSD. Can you file a bug report there?
bob12 commented 5 months ago
Poster

No problem :)

No problem :)
bob12 closed this issue 5 months ago
shawn.webb referenced this issue from a commit 2 months ago
HBSD: Pull in libarchive/libarchive@65a23f5dbee4497064e9bb467f81138a62b0dae1 From the commit in libarchive: ``` Fuzzing with CRCs disabled revealed that a call to get_uncompressed_data() would sometimes fail to return at least 'minimum' bytes. This can cause the crc32() invocation in header_bytes to read off into invalid memory. A specially crafted archive can use this to cause a crash. An ASAN trace is below, but ASAN is not required - an uninstrumented binary will also crash. ==7719==ERROR: AddressSanitizer: SEGV on unknown address 0x631000040000 (pc 0x7fbdb3b3ec1d bp 0x7ffe77a51310 sp 0x7ffe77a51150 T0) ==7719==The signal is caused by a READ memory access. #0 0x7fbdb3b3ec1c in crc32_z (/lib/x86_64-linux-gnu/libz.so.1+0x2c1c) #1 0x84f5eb in header_bytes (/tmp/libarchive/bsdtar+0x84f5eb) #2 0x856156 in read_Header (/tmp/libarchive/bsdtar+0x856156) #3 0x84e134 in slurp_central_directory (/tmp/libarchive/bsdtar+0x84e134) #4 0x849690 in archive_read_format_7zip_read_header (/tmp/libarchive/bsdtar+0x849690) #5 0x5713b7 in _archive_read_next_header2 (/tmp/libarchive/bsdtar+0x5713b7) #6 0x570e63 in _archive_read_next_header (/tmp/libarchive/bsdtar+0x570e63) #7 0x6f08bd in archive_read_next_header (/tmp/libarchive/bsdtar+0x6f08bd) #8 0x52373f in read_archive (/tmp/libarchive/bsdtar+0x52373f) #9 0x5257be in tar_mode_x (/tmp/libarchive/bsdtar+0x5257be) #10 0x51daeb in main (/tmp/libarchive/bsdtar+0x51daeb) #11 0x7fbdb27cab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #12 0x41dd09 in _start (/tmp/libarchive/bsdtar+0x41dd09) This was primarly done with afl and FairFuzz. Some early corpus entries may have been generated by qsym. ``` Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org> Sponsored-by: SoldierX
shawn.webb referenced this issue from a commit 1 month ago
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.