It's true that I haven't dealt with +H. Peter Anvin
's patch series to improve the entropy counter calculations because I've been too busy, but also because most applications don't use it. They use /dev/urandom instead. So for the time I have to work on /dev/random (I don't get paid by Google to work on the random driver, and I'm also organizing things like the kernel summit), I'm more interested in worrying why get_cycle() is a no-op on the MIPS architecture, when it apparnetly has a cycle counter register --- since there are lots of home routers out there which use /dev/urandom, and use MIPS processors, and so this will make a much more immediate, practical difference.
The reality is that trying to estimate entropy given the timing sources available to the kernel is extremely difficult. So in the absence of real hardware support (and that's what rngd is for), entropy estimation is always going to be problematic, and probably hugely subject to error. So that's always going to be an issue with /dev/random.
Sure, I could imagine an option where the user specifies random.i_trust_the_intel_RDAND_hasnt_been_teampered_by_the_nsa=1 on the boot command line which routes RDRAND directly into /dev/random, where we blindly trust that RDRAND has full, completely trusted entropy. That might be good for users who require SP 800-90 compliance, and those users will typically trust the NSA anyway (or have no choice but to trust the NSA). But those users can also just use RDRAND directly. I suppose if those users really want to use open source software, like OpenSSL, and still be SP 800-90 certified, maybe it might be nice if /dev/random and /dev/urandom could have a SP 800-90 compliant mode. But if that's the case, let's have people state that officially, as opposed to these half-baked patches where the claim is "performance". I'm not even sure if his patch would have been sufficient for SP 800-90 certification, since the rules are a kind of strict about what is required by that.
One thing that we might do is to have the kernel periodically generate a random AES key from its random pool, and then encrypt the RDRAND output by that AES key before it is exported to user space. If that's allowed by the SP 800-90 specification (and I haven't read it closely enough to determine whether that would be considered an acceptible post-processing operation), then maybe that would be a solution that would satisfy everyone. I will say though, that, allowing federal contractors to make $$$ selling certified FIPS 140-2 implementations to the US government is not something that is a high priority claim on my volunteer time. I'm much more interested in making https web serving, ssh connections, GPG to be practically secure against all enemies, including both foreign and domestic intelligence agencies.