They have a desktop running on simplefb. That is not a usable desktop (no matter what they say), with zero acceleration and all completely software rendered. There is literally no graphics or display driver. The bootloader gives you a chunk of RAM that is the screen and you write stuff to it. No multidisplay, no resolution switching, no hotplugging, no acceleration. It's like running x86 linux on efifb with no radeon/intel/nvidia drivers at all. Think vesafb for those old enough to remember those days, but even dumber - at least on that one you could pick a resolution.
Our kernel has simplefb support too, literally all you need to do is write 5 lines of devicetree properties to get that to work - zero patches needed to the upstream simplefb driver. Here is the code in our bootloader that takes the Apple framebuffer information and stuffs it in the DT for Linux to use it:
https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59
That's literally all you need to get "graphics".
I was actually planning on doing exactly the demo that they did since December, with a simplefb "full Ubuntu desktop" and everything else running off of USB, for the clickbait, because it's flashy even though it's a minimal amount of work, but with a clear disclaimer that it's a tech demo and there is a lot of work left to do. It certainly brings in the news. However, it is not a "fully usable Linux desktop".
FWIW: WiFi is Broadcom FullMAC (existing Linux driver) with some patches. Ethernet is a Broadcom chip over PCIe (once you have PCIe up, the driver is there). USB is DWC3 (existing Linux driver) with just an Apple PHY adaptation layer. Storage is NVMe with Apple hacks and a horrible (definitely not upstreamable) hack Corellium wrote to fake a PCIe bus because the Linux NVMe driver assumes PCIe. Please don't assume they are cranking out bespoke drivers every other day; most of their work is simple drivers and patches to existing ones. There is certainly work involved in figuring out all these Apple oddities, but these aren't new drivers.
I fully intend to support the SEP in our kernel once we get that far, with Touch ID for Linux log-in/unlock and also things like storing and using SSH keys within the SEP (think built-in YubiKey). Lots of reversing to be done, but all of this is in scope for our project. Drop by our IRC if you'd like to help out :)