[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.BSM.4.64L.2402171450360.9009@herc.mirbsd.org>
Date: Sat, 17 Feb 2024 15:01:15 +0000 (UTC)
From: Thorsten Glaser <tg@...bsd.de>
To: musl@...ts.openwall.com
cc: toybox@...ts.landley.net
Subject: Re: [Toybox] Not sure how to debug this one.
Rob Landley dixit:
>One of the private email replies that didn't go to the list (so I can't politely
>publicly reply to it and maybe get more people who know stuff chiming in)
Sorry, I should have mentioned I only replied privately because
I threw a ton of vague ideas which I wasn’t even sure were at all
relevant at you and wanted to avoid spamming the list. Feel free
to quote.
>On 2/16/24 21:23, Mouse wrote:
>> This smells to me like depending on uninitialized stack trash.
>
>A write-only function that didn't change its behavior when I memset the
>structure before calling it?
More shoots into the blue:
• run under valgrind
• see if the compiler didn’t optimise the memset away or use
explicit_bzero instead
>> The simple way to figure that out is to compile something that uses
>> printf and look at the assembly,
>
>$ ccc/sh4-linux-musl-cross/bin/sh4-linux-musl-objdump -d
>generated/unstripped/toybox | grep -A 60 '<printf>:'
>0045341c <printf>:
[…]
I think Mouse meant the call site, not the callee.
>But again, the point is to SAVE those registers, in a defined order, and there's
>no WAY to insert something that big into delicate assembly non-intrusively. This
Yeah, tricky if one does not know the architecture…
>relocated itself yet so I assembled a message into a char buffer[] on the stack
>and did a syscall(_nr_write).
That would be another idea for here, but again, complexity…
>Oh, I forgot to mention that qemu-system-blah also has a -s option to launch a
This is useful, but often not so much to debug userspace.
I tend to try and figure out where userspace is running at,
then set a breakpoint and let the kernel run until there,
but you’d most likely also get interrupts and stuff, hence
the qemu-user suggestion.
>I do not always have the relevant domain expertise, which is why I try to ask
>people who _do_:
>
>https://lkml.org/lkml/2011/12/14/324
(Yes, the reloc should totally be split; it’s also possible
to have only a HI load, for example if it’s known the lower
ten bits to be zero. I’ve seen that on BSD/sparc.)
>suggested trying it under qemu-user (which reproduced the issue! MUCH easier),
Oh, good!
>And that ALSO says it's a trap 0x180 which in qemu:
>
>sh7750_regs.h:#define SH7750_EVT_ILLEGAL_INSTR 0x180 /* General
>Illegal Instruction */
O̲U̲C̲H̲.̲
>The kernel panics immediately upon PID 1 exiting and even if the panic is
>deferred until after it's written the core dump instead of a check at the START
>of exiting, the writeable filesystem is initramfs which is transient.
Can you do something like put the stuff from the initramfs instead
onto a normal filesystem on loopback of a file on your host, then
provide that as nbd, then boot the kernel with root=/dev/nbd0… or
something, nbd needs a tool to set this up first… or NFS, is there
a kernel-side NFS that doesn’t rely on initramfs setup?
Or, hey, for on-qemu-system debugging, just plug that as -hda or so.
>A) I believe you can still pass rw on the kernel command line
probably even rdsetroot…
>B) you can run a
>dumb little statically linked shim.c as rdinit= to do stuff and then have it
>exec() the next PID 1 process, that's fairly standard procedure in this context.
Indeed, that would be the next avenue.
>But I only pull out gdb when I'm REALLY annoyed. (Cure worse than the disease.
>Can't STAND the user interface...)
Having used Borland Turbo Debugger before, I concur, but I’ve had to
pull out gdb often enough to at least find my way around enough for
these kinds of debugging necessary.
Good luck,
//mirabilos
--
<ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo │ fault (core dumped)
<ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
