On Tue, 30 Jun 2020 21:25:01 +0530 Sreyan Chakravarty <sreyan32@xxxxxxxxx> wrote: > Except that this does not work. The meltdown ovh script still reports > that my system is vulnerable. > > I did a rebuild of my initramfs using: > > dracut -f > > Then rebooted and checked once again. No change. The vulnerability > still exists. Too bad, that would have been an easy win. > > Thus, even if the mitigation is loaded, the system is still > > vulnerable at some level. > > Would be great if I could be absolutely certain about this. > > For now, saying that it works without verification, is just like > wishful thinking for me. Agreed. > > There is nothing you can do beyond what you have done, > > though. > So is it confirmed this is a bug in the microcode ? I don't think the original problem is a bug in the microcode, it is a flaw in the design of the CPU architecture. The microcode is supposed to fix that by mandating certain actions. Jonathon gave you some useful advice to see if the CPU you are using is included in the fix. I think I read that Intel is targeting later CPUs before earlier CPUs, so it might not have been released for your CPU model yet, but *you* should search and confirm if that is true. And Roger's suggestion that updating the firmware before applying the fix worked also deserves consideration, because it might be looking for specific markers before it will apply, and they might only be there in the latest update. > > I don't know how the tool you are using to check functions, > > but it could be that it is seeing these additional vulnerabilities > > and reporting that your system is still vulnerable even though the > > mitigation is in place, and the worst vulnerabilities are > > protected. > > Yeah, this all sounds great. But again, I have to be sure. > > I don't want security to be a crystal ball. Then you need to go to the source of the tool you are using to validate that the fix is working, and directly ask them if it can yield false negatives after the fix is applied. If it can't, you are still vulnerable. If it can, you don't know if the fix is applied or not. > > An extreme measure you could take might be to buy a system with a > > CPU that is not vulnerable. The article mentions that they do > > exist, even some from Intel. > That's not very sensible when a fix already exists and is not > working. Why should I pay extra for things that are suppose to be > fixed in the code that actually advertises it fixes them ? If you are using a commercially provided machine, you should be able to search for that specific machine to see if there are other people in your boat of looking for a fix, and if they have found one. And, you should be able to go to the website of the manufacturer of the machine and ask them as well. They have a monetary interest in having a fix available for their machines (it will be hard for them to sell machines that don't have a fix available). _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
