The musllibc version is quite old yes and so I believe the patch that you link would not be included in the version we pin to. For context, we’ve initially used the musllibc that other seL4 projects used which has not been updated in a long time. That will likely change in the future [1].
The libc has been used for porting off-the-shelf libraries/components such as libnfs and MicroPython which are already considered untrusted. I believe our trusted components such as sDDF virtualisers do not depend on musllibc at all, which is good because we want to be able to verify *all* their code.
Given that muslibc is unverified I’m sure that there are many more vulnerabilities to come! In practice I expect many real-world deployments to rely on
On 11/26/24 6:14 PM, Ivan Velickovic via Devel wrote: libc in trusted parts of the system. The only exception would be safety-certified embedded systems. People really do expect that DNS resolution is safe, even if they do not expect the same for e.g. parsing untrusted images. Also, a remote code execution exploit could be chained with e.g. a Spectre exploit to steal confidential information from trusted parts of the system. -- Sincerely, Demi Marie Obenour (she/her/hers)