From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 0F0FF2A33E for ; Sat, 17 Feb 2024 16:06:12 +0100 (CET) Received: (qmail 23710 invoked by uid 550); 17 Feb 2024 15:03:00 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23678 invoked from network); 17 Feb 2024 15:03:00 -0000 Date: Sat, 17 Feb 2024 15:01:15 +0000 (UTC) From: Thorsten Glaser X-X-Sender: tg@herc.mirbsd.org To: musl@lists.openwall.com cc: toybox@lists.landley.net In-Reply-To: <05774f03-57b5-f524-7a5b-c436237b5d4b@landley.net> Message-ID: References: <349f4e17-8027-c521-eeb3-aa69e8f2b5a4@landley.net> <202402170323.WAA04412@Stone.Rodents-Montreal.ORG> <05774f03-57b5-f524-7a5b-c436237b5d4b@landley.net> Content-Language: de-Zsym-DE-1901-u-em-text-rg-denw-tz-utc, en-Zsym-GB-u-cu-eur-em-text-fw-mon-hc-h23-ms-metric-mu-celsius-rg-denw-tz-utc-va-posix MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Re: [musl] [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 po= litely >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=E2=80=99t 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: =E2=80=A2 run under valgrind =E2=80=A2 see if the compiler didn=E2=80=99t optimise the memset away or us= e 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 ':' >0045341c : [=E2=80=A6] I think Mouse meant the call site, not the callee. >But again, the point is to SAVE those registers, in a defined order, and t= here's >no WAY to insert something that big into delicate assembly non-intrusively= =2E This Yeah, tricky if one does not know the architecture=E2=80=A6 >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=E2=80=A6 >Oh, I forgot to mention that qemu-system-blah also has a -s option to laun= ch 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=E2=80=99d 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=E2=80=99s also possible to have only a HI load, for example if it=E2=80=99s known the lower ten bits to be zero. I=E2=80=99ve seen that on BSD/sparc.) >suggested trying it under qemu-user (which reproduced the issue! MUCH easi= er), 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=CC=B2U=CC=B2C=CC=B2H=CC=B2.=CC=B2 >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=3D/dev/nbd0=E2=80=A6 or something, nbd needs a tool to set this up first=E2=80=A6 or NFS, is there a kernel-side NFS that doesn=E2=80=99t 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=E2=80=A6 >B) you can run a >dumb little statically linked shim.c as rdinit=3D to do stuff and then hav= e it >exec() the next PID 1 process, that's fairly standard procedure in this co= ntext. Indeed, that would be the next avenue. >But I only pull out gdb when I'm REALLY annoyed. (Cure worse than the dise= ase. >Can't STAND the user interface...) Having used Borland Turbo Debugger before, I concur, but I=E2=80=99ve had t= o pull out gdb often enough to at least find my way around enough for these kinds of debugging necessary. Good luck, //mirabilos --=20 you introduced a merge commit =E2=94=82 % g rebase -i HEA= D^^ sorry, no idea and rebasing just fscked =E2=94=82 Segmentation should have cloned into a clean repo =E2=94=82 fault (core dumpe= d) if I rebase that now, it's really ugh =E2=94=82 wuahhh= hhh