Meltdown and Spectre Linux kernel status
41–50 of 186 posts
Re: Meltdown and Spectre Linux kernel status
#42Earlier quoted context omitted.
No, he shouldn’t be seeing that regardless as it doesn’t match the grep regex. I don’t know what, though. Edit: facepalm. Or should that be foot-in-mouth?
It does match the regex. "pti" is a substring in "exception"
Re: Meltdown and Spectre Linux kernel status
#43Earlier quoted context omitted.
A number of ways are listed here [1] 1. With dmesg dmesg -wH | grep 'page tables isolation' 2. With /proc/cpuinfo grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!" [1] https://askubuntu.com/questions/992137/how-to-check-that-kpt...
Thanks. So apparently, my system: Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-104-generic x86_64) is unpatched! Is it because of LTS version? Most servers run this including mine.
Re: Meltdown and Spectre Linux kernel status
#44Earlier quoted context omitted.
A number of ways are listed here [1] 1. With dmesg dmesg -wH | grep 'page tables isolation' 2. With /proc/cpuinfo grep cpu_insecure /proc/cpuinfo && echo "Patched" || echo "Unpatched!" [1] https://askubuntu.com/questions/992137/how-to-check-that-kpt...
Thanks. So apparently, my system: Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-104-generic x86_64) is unpatched! Is it because of LTS version? Most servers run this including mine.
Re: Meltdown and Spectre Linux kernel status
#45Someone please correct me if I'm wrong, but both spectre and meltdown seem to me to be local root exploits, not remote vulns. They can be used to break out of (say) a VM into the host hypervisor, and thence into other VMs running on the same hardware, but cannot be used to break into a machine from outside its hardware perimeter. Is that right?
Re: Meltdown and Spectre Linux kernel status
#46Someone please correct me if I'm wrong, but both spectre and meltdown seem to me to be local root exploits, not remote vulns. They can be used to break out of (say) a VM into the host hypervisor, and thence into other VMs running on the same hardware, but cannot be used to break into a machine from outside its hardware perimeter. Is that right?
Re: Meltdown and Spectre Linux kernel status
#47This just reminded me: when will Ubuntu (and Debian?) fix apt’s broken kernel update process? I have never seen a kernel update - security or otherwise - installed via a normal “apt update; apt upgrade” on any of our machines, it’s always “the following updates have been held back” and then it’s time to manually use dpkg to install the relevant updates.
Re: Meltdown and Spectre Linux kernel status
#48Someone please correct me if I'm wrong, but both spectre and meltdown seem to me to be local root exploits, not remote vulns. They can be used to break out of (say) a VM into the host hypervisor, and thence into other VMs running on the same hardware, but cannot be used to break into a machine from outside its hardware perimeter. Is that right?
Essentially yes, the exploits require code running on the machine that’s attacked. However, for example JavaScript runs on the local machine and is a demonstrated attack vector. It’s also strictly speaking not a privilege escalation, it’s “see things you’re not supposed to.”, such as all sorts of secrets. The attacker does not gain any write or execution privileges, though.
OMG, I didn't know that. Thanks.
Re: Meltdown and Spectre Linux kernel status
#49What I'd like to know is how effective are these OS updates (both Linux and Windows) without the associated firmware updates through microcode or BIOS/UEFI flashing. My system is a few years old and I don't expect the OEM to release BIOS/UEFI updates for this model. Will the OS/microcode update still at least partially protect me or will I have to be super-paranoid about apps and javascript for the remainder of this…
So that's a bit alarming for me since at least one of my several workstations is using a 5+ year old desktop board (an Intel board, ironically) that has been end-of-lifed according to its BIOS downloads support page. Meanwhile, some of the bigger server motherboard vendors (e.g., SuperMicro) are not yet prepared to supply firmware updates for recent motherboards.
Recognizing that the operating system vendors/maintainers are not responsible for our systems' BIOS and hardware, the flippant advice to "talk with your device's vendor" gives me a sinking feeling. (E.g., Microsoft: "Consult with the device manufacturer about the firmware version that has the appropriate update for your CPU.") As a technical person, I am going to find it difficult to bring all of my hardware—especially the older hardware—up to snuff for coping with these vulnerabilities. I fear for people who are less technically inclined.