Improving the handling of embargoed hardware-security bugs

Adding to my other comment, note that "exploit is already in the wild" is a spectrum. There's "widely known and available in 'download it and run it' exploits", and there's "being hoarded by a few people as a zero-day to be deployed on one or two high-value targets".

Making a bug public is probably going to put it into the first of those categories in reasonably short order.

Meanwhile, if the exploit becomes widely known and being actively used at the script kiddie level while it's under embargo, it's likely that someone in the anti-attacker community is going to find out about it fairly quickly due to poor opsec on the part of some script kiddie, at which point the embargo is basically irrelevant.

So, effectively the tradeoff you get is something more like: Would you rather be aware of a known risk that every hack-script builder also knows about and you don't have a good fix for, or gamble that you're not going to be the target of this particular hack when it's used as a tightly-targeted zero-day?

Personally, I think if the latter is a serious concern to you, the precautions that you would have taken had you known about Meltdown before the embargo was lifted are pretty much precautions you should be taking regardless: Don't trust software you haven't completely vetted to run on your machine, don't trust any interface to be an impenetrable barrier unless you can (and do) audit the traffic, and assume timing data on that traffic is an exploitable side channel that you need to secure.