Everything except the GPU (and display controller)... which is a bigger challenge than every other driver combined :) (their kernel runs only on the boot-time framebuffer so far)

Unfortunately, we've yet to hear any feedback from Corellium (they've been CCed on my upstream submissions), nor have they interacted with the Linux kernel community in any other way, so I have no idea what their plans are.

So far, after working with upstream on solving the core problems I mentioned in this article, the M1 support series we are submitting supersedes Corellium's patches for FIQ, the nGnRnE issue, SMP, AIC, UART; we settled on different solutions for all of those from how Corellium did it. I²C is also another one that will be superseded most likely (Corellium wrote their own driver instead of improving the PASemi one; it doesn't seem like there are any show-stoppers that would warrant that approach). I don't know what they're going to do moving forward; perhaps they will re-base on top of mainline and drop their conflicting patches, or perhaps they will attempt to maintain their kernel as a Linux fork...

Hmm, I see them participating on linux-arm-kernel list, nothing since January though:

https://lore.kernel.org/linux-arm-kernel/?q=corellium

Mohamed is not a Corellium employee, but rather a third party who early on volunteered to attempt to upstream some of their patches.

The only e-mail from a Corellium employee to Linux mailing lists, to date, is this one:

https://lore.kernel.org/linux-arm-kernel/ce74bb29-1237-b0e7-...

This is the most puzzling bit to me: nobody from Corellium participated in the upstreaming discussion about their own code either.

They probably just don't have the time to upstream it themselves. I think it's just a publicity stunt for them.