Before renovating an old PC for a friend (and asking advice on that), I would be grateful for explanations about CPU speed info. For example, here are the data for my laptop:
keith@T500:~$ sudo lshw -c cpu
[sudo] password for keith: *-cpu
description: CPU
product: Intel(R) Core™2 Duo CPU P8400 @ 2.26GHz
vendor: Intel Corp.
physical id: 6
bus info: cpu@0
version: Intel(R) Core™2 Duo CPU P8400 @ 2.26GHz
slot: None size: 1600MHz
capacity: 2267MHz
width: 64 bits clock: 266MHz
capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx x86-64 constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm kaiser tpr_shadow vnmi flexpriority dtherm ida cpufreq
keith@T500:~$
What is the significance of “CPU” speed, “size” speed, “capacity” speed (I’m guessing max = cpu speed) and “clock speed”?
size = what clock frequency the CPU is CURRENTLY running at (remembering modern CPU’s don’t run flat out all the time, they automagically throttle themselves when noyt under load
capacity = the maximum clock frequency the CPU can handle
clock = ABSOLUTELY no idea here, I was going to guess the bus speed before multiplying, but my i7 says 100Mhz and I’d find it difficult to believe it was on a slower bus (though not impossible) :-\
In any case, for info about your CPU you’d be better served by
@Rich: Remember the first instruction of The Hitchiker’s Guide to the Galaxy - “Don’t Panic”. The command gives the same on my PC (and probably everyone else’s), so I guess it tells the PC what to do in an emergency.
@Mark:
Thank you, Mark. It makes me feel good to know that I am up there with the experts who don’t know either! But your guesses seem very reasonable.
The cpuinfo command does indeed provide much more info, although I’m not sure I can make use of it all.
I guess “capacity” is the thing that matters.
Although it should be mentioned that as this is a HARDWARE issue (and there’s no way software can change hardware) there is NO complete software fix for Spectre and never will be … it will ALWAYS just be ongoing mitigations against newly discovered Spectre variants, so keep on top of updates.
There’s little point in panicking because there’s nothing you can do … it affects pretty much all CPU’s and all OS’s that run on those CPU’s.
Until the chip manufacturers redesign their CPU’s you can’t even replace the hardware (because their current lines are also vulnerable).
Okay you could switch to some ARM CPU’s that aren’t vulnerable, or very early CPU’s that don’t utilise speculative execution, but then you’d be computing on a snail.
You are right - and my comment was tongue-in-cheek (there’s no emoticon for that).
I ran your code and, to my untutored eye, my laptop doesn’t appear to be very vulnerable.
Many thanks for referencing the code.
I’m assuming from these results that the 1st round of vulnerabilities was patched but others have been discovered later that aren’t?
I vaguely remember a test that I could perform to check if a kernel was patched so I’ll try and root it out and re-post as and when. Also, I need to perform a sweep of redundant kernels (Mint keeps all of the updates) so maybe now is a good time to install the latest (working) kernel too?
Thanks again from a (so far) non-panicking Rich…
EDIT: If I have this right - is a vulnerability exploited by a rogue script on a webpage? If so, would using an up-to-date browser (Firefox, in my case) and enabling UFW (I have) prevent any such script from deploying? Or am I way off beam here?
You’re right and wrong at the same time … most exploits would require local access, and YES some could theoretically be leveraged via a rogue website.
(and NO, UFW or an up-to-date web browser on their own would not stop a remote exploit via a website, because you’d likely give permission for it to run)
An up-to-date browser is certainly ONE of the mitigations (or put better ‘an integral PART of a mitigation strategy’) but it is NOT a fix (or protection) in it’s own right.
Current mitigations seem to revolve around making the clock too course grained to allow for the very precise timings required by an exploit … but new ways to work around these mitigations continue to be discovered, so new road-blocks (mitigations) put in their way … as I said, there is NO fix for this in software, only hardware. Until the hardware is fixed it’ll be a continuously running battle.
All you can do is stay on top of updates … but you should be doing that anyway right
I do apply regular updates but only up to level 3 lately. I stopped the automatic installation of kernels due to a spate of ‘kernel panics’ I was getting. For some reason, updating the kernel was upsetting my bootloader and I couldn’t boot into any of them for a while resulting in a re-install back to Mint 18.1. I did install the present kernel - 4.4.0-116-generic - as it was patched at the time but do accept that other patches are needed as time goes by.
I’ll try to update to the latest workable kernel but may be back regarding the ‘panics’!!
But your guesses seem very reasonable.