Pretty much (and the usual good practices; keeping your system updated, not running random email attachments etc.). The real nasty side of Meltdown was on shared hosting (AWS, Azure, etc), where as a guest you don't know who else might be hosted on the same physical hardware able to run the exploit.
Well I feel a lot better having all those laptops now. I felt a little foolish at first for having so many potentially vulnerable machines TBH, when it sounded like the sky was falling, but if blocking scripting is all it takes it's business as usual for me.
The Intel Management Engine is a bigger deal than this IMO.
More often than not it doesn't take enabling every script that it will list for a site to work. It's being able to recognize which ones and enabling them one by one till you get full functionality. After a while you can tell which are more likely.
Today looks like is mine 2.8 GHz Quad Core Intel "Core i7" I7-860 (Lynnfield/Nehalem) (iMac 11,1, 2009) microcode updated. I am using sysutils/cpupdate and it works without problems.
Now I have "hw.ibrs_active: 1"
I'm guessing the class action law-suits that will occur will force Intel to fix more CPUs than they want to, and/or force to issue deeply discounted new CPUs to allow users to replace their not-so-old-not-yet-end-of-life-still-works-fine-for-me-machines at some sort of fair market price where price includes some sort of fair market value of the old machines. So like either a vehicle recall and/or a buyout vehicle offer.
Just so it doesn't seem like I am, I'm not discounting the severity or the enormity of the problem. It's that I see it as another in a long list of computer vulnerabilities I already have to deal with, just like everybody else. One that for me as a user falls into a category of threats I'm already addressing.
The aspect of shared hosting applies to me, too, but I have to trust somebody else knows what they're doing on that end of things.
This seems like if I try to heal a mental illness using psychology.
I don't know if it's ridiculous, if even it's possible, or if is real. It doesn't seems like from another world, but seems like from another level of this reality. A level hard to access.
I mean: we only can access the software through the hardware. Why we can't use the same medium for try to protect ourselves?
2: Apart of the medium of access, we must think.
As I know, the machines can abstract the information received. The users can do the same, but in a level much more complex.
Depending of the level of knowing, a programmer can fix a bug (for example). But what happens if the trouble is in hardware level?
Thanks, but that wasn't what I intended to mean.
I was talking about the fail in Intel/AMD.
I read that only RHEL has a level of security of 5 (which means a lot). I remember it vaguely, so let me try to search the link and translate the article.
Do you really believe this?
If you were using cpupdate's -f or -d options to show the information hidden in the microcode update file header, you could easily find out the actual update date (not the file timestamp!).
For the T2060:
File /home/stefan/Downloads/microcode-20180425/intel-ucode/06-0e-0c is single-blobbed
Blob 1 of 1 headers info:
-> Family: 06 Model: 0E Stepping: 0C
ExtFamily: 00 ExtModel: 00
IntFamily: 06 IntModel: 0E
ucode rev 0x00000054
Header ver 0x00000001
Loader rev 0x00000001
Data size 4048 (0xfd0)
Flags 32 (0x00000020)
Has no extended header.
In case somebody is interested in learning what is actually in the April 25 microcode update files without using cpupdate, I have pastebinned the output of cpupdate -Ivvd <ucode-dir>.
Expect some more very soon revelations of things Intel probably hopes not to become too public. Stay tuned.