neversaynever wrote:I don’t understand why I’m vulnerable by Meltdown, with PTI not enabled, even if I updated without problems to kernel v. 4.4.0.109-132.

You are running 32-bit Linux Mint 18; KPTI is indeed not enabled for 32-bit kernels. This isn't to say a 32-bit x86 CPU or 64-bit x86 CPU in 32-bit mode necessarily isn't affected by the problem; is to say they are low priority.

You're on a second generation Core i7 which is to say that you very likely should not be running a 32-bit OS; unlikely you'd be coupling that CPU with 1G of RAM or less. If you did not elect to run a 32-bit OS explicitly: you'll need to first of all install a 64-bit version of Mint.

Ubuntu users of the 64-bit x86 architecture (aka, amd64) can expect updated kernels by the original January 9, 2018 coordinated release date

It's likely that updated kernels 4.4.109, 4.13.25 and 3.13.139 also patch the Spectre1 bug(CVE-2017-5753) for 32bit Ubuntu systems, but not for the Meltdown bug.
... Similarly, M$ only patched 32bit Windows for Spectre1 and 2 but not for Meltdown.
.
Common Intel microcode updates for Linux systems are sent to nearly all Intel processors but may apply to only a subset of processors. It is up to Linux users to verify this = to install or not to install the microcode update. During installation of the microcode update, applicable processors will be updated while non-applicable processors remain unchanged.
... The 20180108 Intel microcode update to patch Spectre2 only applies to Intel processors that are 3rd-gen IvyTown(Xeon), and 4th-gen Haswell (Core i3, i5 and i7) or newer. So, it does not apply to 3rg-gen IvyBridge or older. You have a 2nd-gen Intel SandyBridge processor.

buffest_overflow wrote:...
Are you sure you have updated the kernel as well as the intel-microcode?

I followed all guidelines to the best of my ability given the confusion present in all parties involved. Per above post, the KAISER (meltdown relevant) part of the patch was addressed in the 4.4 update manager release notes; though I read about KAISER on ycombinator, meltdown was not mentioned in the release notes. I can't say I understand what any of this actually means. I'm a doctor Jim, not a computer scientist.

cat /proc/cpuinfo still tells me bugs:cpu_insecure. Do I need to revert to a different kernel, or is this just something not updating correctly? I did in fact turn my computer off, then I turned it on again. Newer users are indoctrinated with the belief that hopping around different kernels is not the best idea. I do make daily backups in lucky and in timeshift.

edit: I notice I now have the "pti" flag in cpuinfo; I am going to assume that for some reason cpuinfo isn't saying the right thing in the bugs field?

Newer users are indoctrinated with the belief that hopping around different kernels is not the best idea.

...they aren't indoctrinated, they are frequently suggested though to not do such...exactly because it isn't the best idea - if it breaks, how are newer users supposed to gather the pieces afterwards?...

buffest_overflow wrote:
cat /proc/cpuinfo still tells me bugs:cpu_insecure. Do I need to revert to a different kernel, or is this just something not updating correctly? I did in fact turn my computer off, then I turned it on again.

buffest_overflow, you were probably looking at the...'wrong' comments in the askubuntu link that i sent. It explains it pretty clear, and so did michael here as well:

michael louwe wrote:@ buffest_overflow, .......

Seems, the newer Linux kernels now flag all Intel CPUs as cpu_insecure = already patched for the Meltdown bug.

I have a LM 17.3 box running kernel 3.13.107(not yet patched for Meltdown) and Intel Core2Duo CPU which is not flagged as 'bug: cpu_insecure'.

It is meant to say cpu_insecure and that is what it will say so from now on in patched kernels when running under affected processors. It won't say such on: 1) unpatched kernels & 2) corrected processors if / when they appear in the market...

neversaynever wrote:I don’t understand why I’m vulnerable by Meltdown, with PTI not enabled, even if I updated without problems to kernel v. 4.4.0.109-132.

You are running 32-bit Linux Mint 18; KPTI is indeed not enabled for 32-bit kernels. This isn't to say a 32-bit x86 CPU or 64-bit x86 CPU in 32-bit mode necessarily isn't affected by the problem; is to say they are low priority.
You're on a second generation Core i7 which is to say that you very likely should not be running a 32-bit OS; unlikely you'd be coupling that CPU with 1G of RAM or less. If you did not elect to run a 32-bit OS explicitly: you'll need to first of all install a 64-bit version of Mint.

Ubuntu users of the 64-bit x86 architecture (aka, amd64) can expect updated kernels by the original January 9, 2018 coordinated release date

It's likely that updated kernels 4.4.109, 4.13.25 and 3.13.139 also patch the Spectre1 bug(CVE-2017-5753) for 32bit Ubuntu systems, but not for the Meltdown bug.
... Similarly, M$ only patched 32bit Windows for Spectre1 and 2 but not for Meltdown.
.
Common Intel microcode updates for Linux systems are sent to nearly all Intel processors but may apply to only a subset of processors. It is up to Linux users to verify this = to install or not to install the microcode update. During installation of the microcode update, applicable processors will be updated while non-applicable processors remain unchanged.
... The 20180108 Intel microcode update to patch Spectre2 only applies to Intel processors that are 3rd-gen IvyTown(Xeon), and 4th-gen Haswell (Core i3, i5 and i7) or newer. So, it does not apply to 3rg-gen IvyBridge or older. You have a 2nd-gen Intel SandyBridge processor.

Thanks 'rene' and 'michael louwe' for your explanations.
Unfortunately I had to install Mint 18.0 32-bit because it was impossible to boot my PC with the live-version 64-bit (and nobody helped me in finding a solution). Maybe I could test the last live-version 64-bit of 18.3, but I think that the problem was (and is) on my BIOS (sigh!).
If I understood well, me too I'll receive a kernel pactch and intel microcode for 32-bit, but nobody knows when, because my situation is "low priority". So I have to wait and control Update Manager and Driver Manager in next weeks.
Is this correct?
Thanks a lot for your attention. I appreciated very much.

.
Users of 32bit systems are made to wait for the Meltdown & Spectre patches because they have minority desktop OS world market share. ["Majority rules".] This was because most new OEM Win 8.x/10 computers since 2012 came with UEFI technology which requires 64bit OS. Hence, Google have stopped supporting 32bit Chrome for Linux since March 2016. Likely, Ubuntu will also stop support for 32bit Ubuntu 18.04 LTS in April 2018.

Thank you ‘Michael’.
Yes it’s very odd. I could install LM 64-bit on an older machine (Acer Travelmate 6592 dated 2008) with the almost same BIOS (and same settings) of my actual PC (Acer Travelmate 8573TG dated 2012).
On it I use Windows 7 SP1 64-bit (I’m trying to switch from Windows and I don’t want Windows 8 or 10) and Linux Mint 18.0 “32-bit” (unfortunately).
With the live CD 64-bit, after reading for some seconds the CD at boot, the screen remained total black … “forever”; no beeps, no Grub, nothing. Nobody was able to advise me how to solve the problem.
Now if Ubuntu will stop support for 32-bit in 2018 I have to face the problem again or I’ll have to change my PC with a newer one …
If you can advise me a forum of experts on which I can try again to subject my problem, I will be happy.
In two days I leave for two weeks without smart-phone or computer devices to detoxify: but when I’ll come back I could ask for help once more.
Thanks for your attention.

neversaynever wrote:
Unfortunately I had to install Mint 18.0 32-bit because it was impossible to boot my PC with the live-version 64-bit (and nobody helped me in finding a solution).

I can't find the forum thread where you asked for help with this... am I missing something?

Hi Moem. I asked here: https://forum.ubuntu-it.org/viewtopic.php?f=38&t=613881
I had only one answer, but not very usefull. After testing for a few days, after contacting two 'apparently experts' by phone without usefull solutions, I found that the live 32-bit version was OK. So I installed 32-bit instead of 64: I thought it was almost the same ... but evidently I made a mistake.
Thanks for your attention.

Okay, so if you're still interested: give us a go, we may be able to help.

Thank you very much Moem, i’m still interested.
As I told, in two days I leave for two weeks without smart-phone or computer devices to detoxify: but when I’ll come back, if you tell me where I can post my problem, I will be happy to ask for help again.
Thanks a lot (and sorry for my poor English)

Thanks Michael. I apologize and I realized I'm Off Thread: maybe I should post in another Thread, but I don't know where.
I checked out the link, but is too "difficult" for a newbie like me. Maybe is not the same problem because their PC booted, badly (without mouse) but booted. In my case it doesn't boot: it seems blocked with black screen.

neversaynever wrote:If I understood well, me too I'll receive a kernel pactch and intel microcode for 32-bit, but nobody knows when, because my situation is "low priority". So I have to wait and control Update Manager and Driver Manager in next weeks. Is this correct?

The 32-bit Linux kernel will indeed also be patched for both Meltdown and Spectre, and microcode updates will on a 64-bit capable CPU such as yours in fact likely not discriminate between 64-bit and 32-bit code. Can not at this time find definitive confirmation of that latter statement but something else would seem to technically make limited sense. Microcode updates for your CPU haven't been released yet by Intel, nor are Linux kernel-side changes to make use of them even if they had present in a current "enduser kernel". I do believe that most of that which is coming in that sense is currently present in the still to be released upstream 4.15 kernel...

As to microcode updates for non 64-bit capable x86 CPU's: anything Core 2 and up is 64-bit capable so we're at that point talking about more than 10 year old CPU's; Pentium 4 or Core Duo/Solo at best. Intel might provide a microcode update and an OEM like HP might release new BIOS versions incorporating it for a few select 32-bit business models if they happen to have an important customer still using them, but yes, certainly the least that can be said is that this would be low-priority.

More so in fact because it's unclear if the Pentium 4 architecture even suffers from the problem beyond the generic speculation one; beyond how AMD does. It was at that exact point in time that AMD was kicking major Intel butt per megahertz and it wouldn't surprise me if Intel had introduced their specific additional exposure to the issue as part of the reason why Core 2 then kicked AMD square in the mouth just a bit later. For the lawyer types: that bit's interesting in a class-action lawsuit sense since if the Pentium 4 did the right thing wrt. enforcing memory protection also for speculative code in the manner that AMD has said they have always done, then it can be argued that Intel apparently knew what they were doing when they stopped doing said right thing.

In any case...

What seems to not be making 4.15 is 32-bit versions/equivalents of what is currently already present in the released Ubuntu updates; the Meltdown-mitigating KPTI patches. It's currently being worked on, e.g. https://www.mail-archive.com/linux-kern ... 85332.html, but I would not expect any of that before 4.16. At the earliest, but if the same KPTI principles as on 64-bit can be extended to 32-bit, then probably also at the latest. Regression-testing might take a few folks digging through their basements for 32-bit systems though...

But directly as to your "is that correct?" query then: well, yes, but no in the sense that you should first and foremost try and get a 64-bit system up and running on your 2nd gen. Core i7. The issue is probably that you have a 32-bit UEFI implementation; if you're not dual-booting with Windows or can re-install that as well, certainly booting in legacy mode would be a workaround. Other and/or better workarounds may be available: this forum's "Installation & Boot" section is likely useful in that sense; I don't myself have extensive UEFI experience.

And other than any of the above: please note that while this may all be very entertaining to the technically minded and/or the mindlessly paranoid, none of it will affect you in an actual sense. Exploiting either issue requires on your system executing code, requires "malware". On Linux you are now and were always to a high degree immune to malware even in the general sense; are if you are using a recent patched browser fully immune to dynamic web-content exploits in the meltdown/spectre-specific sense. If you're not in the habit of installing unverified stuff from the internet feel free to just not worry about any of it.

release announcement says
Please use the Update Manager to upgrade intel-microcode to version 3.20180108.0.
Note: If intel-microcode isn’t installed on your computer, run the Driver Manager to see if it’s needed

I turned on level 4 and 5 updates and updated kernel, but did not see any microcode update - driver manager showed the update but did not say it was needed - took a chance and applied it anyway and it now shows up in my package manager, but, if i run

1) you have to reboot first...and then run dmesg | grep microcode to verify it's date.
2) even then, it might just be that the latest microcode update doesn't yet provide support for your processor; theoritically, it should report a date later then 2017-06-01...