I think this, or a similar implementation at any rate, was previously posted on HN. It's certainly a good idea, and I think that the more popular crypto libraries (I'm looking at you, OpenSSL) would do well to consider implementing something similar.
The key point being that (and this was my biggest concern), it is fully compatible with AES-NI, the Intel's hardware-accelerated AES instruction set. According to TFA, with AES-NI there is no performance penalty for keeping the AES keys stored in registers and out of the RAM. What's not to like?
Linux takes CPU-specific patches all the time, and has numerous modules to take advantage of CPU features. As long as the patch gives it a clean interface and meets the Linux kernel's standards, I don't see any major roadblock.
I don't, however, think that the magic early-boot changes to prompt for a passphrase almost immediately after boot would have much chance. And I don't really see the point of that compared to the usual mechanism of prompting for a passphrase from the initramfs before mounting encrypted partitions. Either way means that you have key material very briefly in memory before ending up in CPU registers, and thus that you must very carefully wipe that key material from memory before proceeding.
Looking at their patch, it would need a major overhaul to become suitable for acceptance into the Linux kernel. They've also re-implemented sha256 themselves rather than using the kernel's existing implementation, and they've used that sha256 implementation for a very simplistic key derivation function (2000 iterations of sha256 directly on the passphrase itself).
The key point being that (and this was my biggest concern), it is fully compatible with AES-NI, the Intel's hardware-accelerated AES instruction set. According to TFA, with AES-NI there is no performance penalty for keeping the AES keys stored in registers and out of the RAM. What's not to like?