jbk: Right, it's kind of the model, for better or worse. I just put a 64KB buffer on the stack to pass to the handler routine, and to give to door return on the way out: github.com/oxidecomputer/doorjamb/blob/main/src/server.rs#L82-L109

yeah, i think i did something similar.. though I think I used a pthread key + destructor to at least clean things up whenever the door thread was terminated...

(in C)

when passing around data in packed nvlists

(I figured that was probably less error-prone esp. if the caller is untrusted)

since IIRC libnvpair has gone through a fair amount of fuzzing (by Alex I think)

jbk: if people have afl setups for that, it'd be great to get them into usr/src/test

danmcd: you know how to reach arekinath, I guess

speaking of that.. does anyone know if our gcc is built so it can work with afl?

the pkgsrc gcc is not (it hardcodes absolute paths into the driver IIRC)

so afl can't 'interpose' (for lack of a better term) on the compilation

can it not use specs to avoid that?

(which is basically what I do to make things depend on the smaller -libs packages instead of the full gcc)

it's been a while, but my recollection is that it uses -B

which doesn't work if gcc hardcodes an absolute path

or something like that

-B should work regardless, but perhaps do too much

spec override should work regardless

I don't know about about it's build configuration based

perhaps, but then we'd need to fork afl

is afl assuming cc1 is in $PATH or something?

I don't understand what mis(?)-configuration is happening.

when I was fuzzing the C++ demangler, I had to use clang to build the fuzzed bin as I recall

sounds like questions for arekinath if Dan can rouse

but yeah, I'd really like fuzz setup in test/ (but _not_ in the main test suites)

the only "hardcoding" I'm aware of is that we set local prefix so that users can compile stuff out of the box, I don't think that's unusual

the header namespace tests have taught me that long-running low-churn things in the main suites sure do suck someimes

i think it was the path for the assembler something like instead of it being specified relative to some sort of 'gcc root', pkgsrc was doing /opt/local/....../gas

ok, yeah, --with-* for those take absolute paths

and I think we tend to give them

it's been several years now so details have faded :)

but I still don't understand how that bubbles up to afl I guess

happy to take a look if you can give me something to test

jbk: yeah, no, I'm not complaining about your explanation. I'm just really confused

and I'm _really_ eager to have fuzzing of untrusted data consumers right there in usr/src/test

I haven't in a while richlowe.

hi all, trying to get OpenIndiana on a AMD FX8350, ASUS Sabertooth 990FX motherboard; FreeBSD installs and runs cleanly on it but I have the machine shutting itself down during the boot process of the installer

any ideas as to how to get further with it

is the AMD IOMMU involved perhaps, there are different settings in the BIOS for it; booting off a CD I burned, to avoid any USB/EHCI issues

shmorg83: if you get to boot menu, press esc and on ok prompt enter: boot -kdv -B prom_debug=true,kbm_debug=true

that will, if it works, drop you into the debugger eventually, btw.

best to warn people about -d tsoome :)

yep:)

once on mdb prompt, just type ::cont

so it initialized all the CPUs, cpu0 to cpu7, after the line "cpu7 initialization complete - online" I get

WARNING: xhci2: abort command timed out: resetting device

panic[cpu1]/thread=fffffe003d0c4c20: XHCI runtime reset required

Warning - stack not written to the dump buffer

fffffe003d0c4b50: xhci:xhci_taskq+33b8498f ()

fffffe003d0c4c00: genunix:taskq_thread+2a6 ()

fffffe003d0c4c10: unix:thread_start+b ()

then panic entering debugger etc.

so is it something to do with XHCI, is that USB2 and USB3 ?