Meltdown and Spectre

[bobx001]

My F26 x86 4.14.11 system also hangs during boot after starting the window manager -- the screen remains in ascii mode with the usual boot log. Fortunately, I am able to boot into 4.14.8 .

in my same case, i had to redownload nvidias new proprietary driver and fully reinstall it.
nouveau had crawled back in from the hole, to ruin my day again.
in my case, the rpmfusion solution does not seem to work since FC26.

[normvcr]

I have put "nopti" at the end of the boot line, to no avail. Have filed bug
https://bugzilla.redhat.com/show_bug.cgi?id=1534031

[Kobuck]

@Kobuck and normvcr, have you tried the steps in the "how to turn it off" thread in this forum?

"nopti" had no effect. I'm guessing the changes to allow the Intel fix are somehow tipping my machine over. I'm now running "4.14.13-300.fc27.x86_64" and I seem to be back in business.

I don't want to say it too loud and wake a sleeping dog.

[antikythera]

try pti=no which is the other version of the same command.

[Kobuck]

Just did 4 reboots switching between "4.14.11-300.fc27.x86_64" and "4.14.13-300.fc27.x86_64" at each boot.
Using the kernel updates as supplied (no use of kernel line options like "nopti" or "pti=no" )

4.14.11-300.fc27.x86_64 = 2 boot hangs
4.14.13-300.fc27.x86_64 = 2 successful boots

Just FYI.

[normvcr]

try pti=no which is the other version of the same command.

Same problem using "pti=no"

[Obsolesce]

So when is Fedora going to patch Spectre varient 1 at least? It looks like CentOS has already, why not Fedora?

See chart:

http://i.imgur.com/hZjrZYz.png

[marko]

Same problem using "pti=no"

what occurs if you do the "runtime disable" shown here:

https://access.redhat.com/articles/3311301

# echo 0 > /sys/kernel/debug/x86/pti_enabled
# echo 0 > /sys/kernel/debug/x86/ibpb_enabled
# echo 0 > /sys/kernel/debug/x86/ibrs_enabled

[normvcr]

I put noibrs noibqb nopti at the end of the boot. Same problem persists.

[normvcr]

Installed F26 4.14.13.200 . Default boot hangs (did not add noibrs noibqb nopti ) to boot line. I may be installing F27 sooner than I had planned. F28 is not scheduled until May.

[ocratato]

Linus isn't very happy with Intel:
https://lkml.org/lkml/2018/1/21/192

[antikythera]

Linus isn't very happy with Intel:
https://lkml.org/lkml/2018/1/21/192

a quick summary of the above linked mailing list post for people who can't be bothered reading through it all

[lsatenstein]

ZDNET

http://www.zdnet.com/article/why-intel-x86-must-die-our-cloud-centric-future-depends-on-open-source-chips-meltdown/

Why Intel x86 must die: Our cloud-centric future depends on open source chips

Perhaps the Meltdown and Spectre bugs are the impetus for making long-overdue changes to the core DNA of the semiconductor industry and how chip architectures are designed.

By Jason Perlow for Tech Broiler | January 18, 2018 -- 17:38 GMT (09:38 PST) | Topic: Cybersecurity in an IoT and Mobile World

[lsatenstein]

Steps are being taken by the US government to create a new non-intel architecture.

[ocratato]

As I read it the article is proposing something like the ARM model, but where the intellectual property is open and free to use by any chip fabricator.

I am not sure that can work. There must be a fair amount prototyping work to get a design that is reliable, and that costs real money.

It would not solve this sort of problem either. It would be just as prone to bugs as any other development model, and the bugs would be equally impossible to resolve - you cannot fix something that is baked into the silicon.

Perhaps what is needed is a chip design where there is some scope for making repairs. Modern chips already use microcode, but perhaps a layer using a reprogrammable FPGA might enable some design flaws to be fixed. Of course no one is going to do that without some sort of financial incentive, so some class actions against Intel might prompt them to do something along those lines.