Sorry, who is Luke?
Do you have an ETA on when linux49: v4.9.74-2 will be available? I’ve just updated via Octopi and I’m still on v4.9.73-1.
DLF this morning broadcasted a short announcement about this hardware bug.
There where mentioned that
Intel and ARM
are full affected by this problem.
AMD is partly affected.
If i got a bit spare time i will find the source (named was “The Register”) of this.
"“Meltdown” is the name given to a side-channel attack on memory isolation that affects most Intel chips since 2010, as well as a few Arm cores.
Meltdown – on Intel CPUs and the Arm Cortex-A75 – allows normal applications to read protected kernel memory, allowing them to steal passwords and other secrets.
There’s also another security flaw named Spectre that affects, to varying degrees, Intel, AMD, and Arm. Depending on your CPU, Spectre allows normal apps to potentially steal information from other apps, the kernel, or the underlying hypervisor. Spectre is difficult to exploit, but also difficult to fully patch – and is going to be the real stinger from all of this.
On vulnerable systems, Meltdown allows user programs to read from private and sensitive kernel address spaces, including kernel-sharing sandboxes like Docker or Xen in paravirtualization mode. And when you’ve stolen the keys to the kingdom, such as cryptographic secrets, you’ll probably find you can indeed corrupt, modify or delete data, pal.
Chipzilla doesn’t want you to know that every Intel processor since 1995 that implements out-of-order execution is potentially affected by Meltdown – except Itanium, and the Atom before 2013.
I also found another source, Google Security Blog:
Project Zero, who examinated the problem:
"So far, there are three known variants of the issue:
- Variant 1: bounds check bypass (CVE-2017-5753)
- Variant 2: branch target injection (CVE-2017-5715)
- Variant 3: rogue data cache load (CVE-2017-5754)
Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at:
- Spectre (variants 1 and 2)
- Meltdown (variant 3)"
Now back to work with Windows 10
I apologise in advance for this basic question, but i’m still struggling a bit to grasp the big picture here. I’m still on 4.14.9-2 [Stable branch], & i’ve not yet done the 2017-12-31 Update, but IIUC it “only” has 4.14.10 anyway. What is the recommended action i should take atm to get linux414: v4.14.11-1… do i simply wait for it to appear in an upcoming Update, or should i be taking some proactive steps right now? Thanks.
It is up to you, if you
- wait for the next release in Stable branch
- switch (temporarly) to Testing branch
It should be clear, what the terms “Stable” and “Testing” have in common - and what not!
Imho the danger of “Testing” is higher than the security breach within the next days, so just wait.
Maybe other peoples tell you other details with more knowledge than me…
I’m on “Testing” since i installed Manjaro back in Dec 2015 without problems.
You mileage will vary…!
Excellent - thanks for your fast helpful reply. I’ll stay with Stable & just patiently await the kernel update. I do not have sufficient skills & knowledge to deal with any adverse consequences of going to Testing.
This is bad, really bad for regular users. But can you imagine what a company like Google with their millions upon millions of CPUs getting a 30% hit in performance will cost them? Or a company like Amazon with their huge cloud storage and processing business getting attacked and having security keys reveled if they don’t want to take the performance hit. Or government servers …
I already feel tired just by thinking I will soon have to reboot my 6-nodes cluster…
And 30% penalty at running databases, sounds promising!
Soon to be an 8-node cluster to keep the same performance
If I understand this correctly, there are two issues: Meltdown and Spectre.
The first affects Intel only, the second also affects AMD and ARM.
More technical info:
Despite the promise of breakage that is implied by the word “testing” I assure you it’s nothing to lose sleep over. Even the “unstable” branch is boringly stable in my experience.
I believe it highly depends on the experience of the user, besides the hardware and the chosen WM.
As I first started with Manjaro, I broke my system several times with the stable branch before I learn the statement "Don’t fix what’s not broken" .
I will personally stick to the stable branch and wait for the update .
Linus Torvalds I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.
Full comment here. So the patching will go on …
More patches backported from v4.15-series got added to linux414 v4.14.11-2.
My feeling was correct that my netbook can still be good for sth.
And here’s another link of relevance
I’ve reviewed much of the linked material and etc relating to Meltdown and Spectre but alas, I am still not clear on whether the following might be mitigations to the problem:
- If one uses the usual best practice on security, e.g., strong passwords, firewall and perhaps a VPN - do these things provide any real protection from the two villains?
- Is it a case of almost every computer that’s connected to the internet is out-of-the blocks vulnerable? I mean again, if one uses those best practices as in point 1, wouldn’t that stop a hacker from getting control of your machine right from the start? Or as I said, is it a case that once your Intel, ARM or Linux machine is connected to the internet it means all the protections of VPN’s and firewalls and strong passwords are meaningless?
- If you own an Intel CPU you’re vulnerable to Meltdown and Spectre. Meltdown can be fixed essentially by building a stronger wall around the kernel; the technical term is “kernel page table isolation.” This solves the issue, but there’s a cost. Modern CPU architectures assume certain things about the way the kernel works and is accessed, and changing those things means that they won’t be able to operate at full capacity. We have patched linux44, linux49, linux414 and linux415 so far in our testing branch.