I wonder if this can be fixed at firmware level. (I frankly have no idea how deeply configurable Intel cores are.)
Keep in mind, this is more-or-less just the 4GB/4GB patch set that floated around awhile back for 32-bit systems, and that patch was never merged precisely because of the big performance impact it imposed - and that change actually had some merit, this one has none besides security. I don't think Linus would be letting this go through (And especially be on by default) without a fuss unless there is really no other way to mitigate a fairly big security hole. That's just my opinion, but it seems pretty clear to me. It's possible he has not spoken to anybody at Intel about this, but I would personally think he has some connections to get some info on it.
With a future os-specific microcode patch a config option would make more sense. They just need to find a 2nd C3 register to seperate user from kernel space or do the permission check before prefetches. Like AMD does. On Linux this check would be cheap, on Windows NT not.
Or maybe it could be that Intel privately disclosed already that no backport will be done to firmware of older CPUs, in which case the kernel update is the stopgap for newer generation and the solution for older generations.