IRC channel logs
2022-11-24.log
back to list of logs
<oriansj>muurkha: well we certainly have seen this class of security problems even on Linux (Looking at you RISC-V for not zeroing registers) and the correct course of action is to either provide the fiwix developers a patch or inform them of the security issue; then put in a bit of code to deal with that issue for our side so that when we get ported to the next platform which possibly has the same issue that we don't get slowed down by it. <muurkha>yeah, it's important to not accidentally leak possibly confidential information into userspace <muurkha>nothing we've seen so far seems like strong evidence that Fiwix is doing the wrong thing, does it? <muurkha>there was an on-stack buffer that wasn't zeroed before use, and this uncovered a bug in wstrcpy (in M2libc?), but we don't really know if the dirty stack resulted from Fiwix supplying an unclean stack page or from a previously called function or signal handler? <rickmasters>muurkha: right, we don't know for sure that fiwix provided uninitialized memory <rickmasters>tcc-musl fails because musl initialization invokes syscall set_thread_area which fiwix does not implement. <rickmasters>I *think* the assembly code falls back to syscall modify_ldt in case of failure, but that is also unimplemented. <rickmasters>Offhand I'm not sure what to do. I'll be doing holiday stuff for a while so I'll check in later... <oriansj>rickmasters: yeah, enjoy the holidays and have a great time <stikonas>hmm, some UEFI structs are a bit annoying to implement in M2 (as they use things like 16-bit or 32-bit integers)... <stikonas>we probably don't need all of that to be easily accessible but at the very least need to get correct size of the struct <stikonas>I guess I'll just use char and add a few entries...