I do wonder how much stuff would break if you patched Linux to return error numbers with high bits set to autogenerated values. Obviously libc (and go if used) would need patching, but how many places call syscalls directly and are checking error codes carefully. Probably surprisingly long tail, but still could be fun experiment.
A richer error system could be as simple as giving some more information about why a syscall returned -EINVAL (because checking all possible flag bits to see which one is not supported is really not a fun exercise).
Funnily enough, EPERM is awful for another reason -- the vast majority of EPERM returns for kernel APIs should really be EACCES. The problem is that EPERM reads as though it means "Permission denied" when in reality it means "Operation not permitted".
Besides especially on 64 bit systems I don't think we are going to run out of negative numbers any time soon. Of course there are the few outliers that need the whole space (mmap), but those should be fairly rare?
The original kernel patch had a facility to disable programming lockdown lifting, but this apparently did not make it into the kernel he is using. Hopefully this was intentional, to make this less annoying for users during the testing period.
I hope that by the time things begin to hit mainline, Cloudflare's engineers will chime in with ideas that allow (e)BPF to continue to run, as they seem to use it widely internally.
