When the latest Intel vulnerabilities were in the spot light, a week ago - post #1790, I provided a link to an article @ Phoronix where an additional bug was mentioned.
https://www.phoronix.com/scan.php?pa...AA-Kernel-Code

I kinda forgot about that and now while writing my own changelogs (keeping them on some core systems) I checked again what was all about and discovered:
https://cve.mitre.org/cgi-bin/cvenam...CVE-2018-12207

https://git.kernel.org/pub/scm/linux...05d4ad0002a7d4

https://software.intel.com/security-...-size-change-0

The Slackware provided kernels look to contain something about this:
https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.202
- the -current kernel has some more records on ITLB :
https://cdn.kernel.org/pub/linux/ker...ngeLog-4.19.84
According to this RedHat article, the mitigations come in different forms, microcode fix by Intel and kernel use of the "kvm.nx_huge_pages" boot parameter for patched kernels:
https://access.redhat.com/security/v...s/ifu-page-mce
- click on Resolve tab

And yet again my ancient Intel Atom N270 (Bonell) proves to be the most secure Intel CPU I own ATM. Soon I'll start an auction for it and buy a Learjet

P.S. From the RedHat article above I learned that you can check the state of the vulnerability&mitigation (given the kernel is ready/patched):
-Not affected
-KVM Mitigation: Split huge pages
-KVM Vulnerable: no mitigation enabled

It looks like 4.4.202 is patched, the output on the Atom N270 running Slackware 14.2:

3 members found this post helpful.

Kernel 5.4.0-rc8 is patched but mitigation requires activation of Intel Virtualization Technology (Vanderpool Technology) in BIOS/UEFI.
The message will be "KVM Mitigation: Split huge pages".

2 members found this post helpful.

Another round of kernel updates has been scheduled for release on Thursday morning, 21 November 2019, at approximately 05:00, GMT.

If no problems are found while testing the release candidates, they might be available sometime on Wednesday (depending on your time zone).

There will be 48 patches in the 5.3.12 kernel update, 422 in 4.19.85, and 239 in the 4.14.155 kernel update.

The details:

5.3.12, http://lkml.iu.edu/hypermail/linux/k...1.2/02329.html

4.19.85, http://lkml.iu.edu/hypermail/linux/k...1.2/03021.html

4.14.155, http://lkml.iu.edu/hypermail/linux/k...1.2/02702.html

A major release Kernel update is a lot of work. I'm also considering dropping the uBoot "uImage" from the packages, as they're only required by the Trimslice; but to drop it I'd need to get a newer version of U-Boot working on that device.
Or, I drop support for the Trimslice instead.

It's low priority - I don't fancy being an early adopter. I'll probably look at it some time in Q1 2020.

3 members found this post helpful.

Silly as I am i have high hopes on ARM and HDMI maybe even 64bit?

I already use HDMI with My Orange Pi with the current Kernel and it works both for the console and within Xorg.

I have no need for 64bit ARM hardware- someone else in the community is working on that and posts to the ARM sub forum.

2 members found this post helpful.

Hi. Anybody knows where I can download VirtualBox 6.0.15 ?
I am not able to found this version at http://download.virtualbox.org/virtualbox/
Thanks.

1 members found this post helpful.

[off topic, deleted]

here:
https://www.virtualbox.org/wiki/Testbuilds

4 members found this post helpful.

An update for the 3.16.y kernel series has been scheduled for release Friday afternoon, 22 November 2019, at approximately 15:30, GMT.

The 3.16.78 update will have 83 patches.

Mr. Hutchings' announcement, http://lkml.iu.edu/hypermail/linux/k...1.2/04899.html

1 members found this post helpful.

Kernel updates 5.3.12 and 4.14.155 is now available at,

https://www.kernel.org/

The change logs,

https://cdn.kernel.org/pub/linux/ker...angeLog-5.3.12

https://cdn.kernel.org/pub/linux/ker...geLog-4.14.155

The 4.19.85 kernel update is now available at,

https://www.kernel.org/

The change log, https://cdn.kernel.org/pub/linux/ker...ngeLog-4.19.85

This "late in the game," 422 patches makes me question the process, but, then, perhaps, I just don't understand how the whole long term kernel maintenance system works.

1 members found this post helpful.

(keeping you company)

2 members found this post helpful.

In what regard do you question the process? Do you mean that it's sad that bugs be discovered long after the release? I don't know how this could be avoided. Bear in mind that most bugs are triggered in specific contexts or through a specific (and possibly unusual) sequence of events. Listing all contexts or possible sequences of events to test them is hardly feasible.

Me, I am happy that bugs be fixed in point releases, regardless of the status (LTS or not) of the major release. For server expected to run 24/7 365d/y it's up to the admin to decide if upgrading the kernel is worth the down time (but there are cases where they could instead do a kernel livepatching despite its limitations).

Just tried 5.3.12 and I'm still seeing the raised thermal levels at idle and under minor load that I was seeing with 5.3.11.

Looks like I'll be stuck with 5.3.10 for the time being.

1 members found this post helpful.