On 11/26/24 6:14 PM, Ivan Velickovic via Devel wrote:
> 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
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)
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
