Kernel Memory Leaking

smart observation... that's exactly what is written in the question above. (+ jolla1 affected too as you may figure out reading the question)

Please apologize - I did not read carefully the edited question; my remark is indeed (at least) redundant

@olf arm and amd are affected too!

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html

https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html

There are three vulnerabilities: Spectre (the name for 1 and 2) and Meltdown number 3 as the most dangerous, ARM and AMD is not " too much" affected by number thee because off architecture differences.

@misc11, the Linux (kernel) code changes (I read yesterday), called KPTI (aka KAISER aka FUCKWIT), address what the Google Project Zero paper (published today) calls "meltdown" (attack #3: Rogue Data Cache Load), which is a broad flaw and seems to be practically usable for exploits.
AMD x86 CPUs are not affected by this, see https://www.amd.com/en/corporate/speculative-execution, and this still looks very Intel x86 specific (while I still wonder why ARM employs similar countermeasures).

The Branch Target Injection (attack #2) is not really new and has not shown to be practically exploitable in non-academic setups. OTOH it leverages a much more obvious optimisation for microprocessor designs, which supposedly many implemented in a similar general fashion (but presumably still different exploit code will be needed per CPU design).

AFAIR attack #1 (Bounds Check Bypass) is also not new, but AFAIU research on it has now been extended to a point, where it becomes easy to use for an exploit.

Please differentiate between an attack / vulnerability and practical exploits. Also mind that this is an academic research paper: Hype is always included in them and attacks shown in controlled environments / special setups do not directly translate into real security risks, although in this case #3 and #1 obviously do for Intel x86 CPUs.
While the Google Project Zero paper is impressively written, it does not clearly differentiate between those three attacks throughout the paper, initially states that Intel, AMD and ARM are affected, but lateron only cites Intel Haswell CPUs, and leaves out much of the specific circumstances needed for these attacks.

This is why I rather read Linux (kernel) commits, because these code changes make quite obvious what they are protecting against (when one has a background in modern microprocessor design).

@olf i dont have enough knowledge to have a deeper word about this. i just found it a bit..... daring to say so early in that thing that really only intel is affected..... i think until everything is absolutely clear everything should be counted as affected... from then on we can whiteliste the architectures

edit: also i remember reading somewhere that amd was included in those linux fixes at first

@misc11, for me it was not "daring" to write that answer, after having read the KPTI code changes for x86 and quickly looked over its variant for ARM.

But it turned out to be "daring", as I did not expect the Google paper to intermingle this attack with two other, known ones (while extending research on those).

But I completely disagree with your last statement, as nobody seems to be affected yet, because no exploits are out in the wild right now (but sure will in a couple of days). As with all academic research papers on IT security, this should alert everyone being potentially affected, but there is no reason to panic until you know that you really are.

WRT your edit: Yes, this seems to have been a precaution, until it became clear that AMD CPUs are not affected by the Rogue Data Cache Load attack.

It's called a "burner phone" ._.

A middle solution: https://www.qubes-os.org/

qubes is also vulnerable to speculative execution cache sidechannel attacks

@juiceme yes, but only inside their hypervisor, i.e. if in one qubes compartment with Inet connection you don't have confidential stuff, than you have an equivalent solution from the above.

Just better to move version 4.4 that's best compromise..

jolla1 (sbj) is on 3.4 (armv7-32bit) and will stay there (due to qualcomm modem driver). jollac is on 3.10 (32bit) and will stay there. For a company as small as jolla it makes sense to stay at 3.10 for xperiaX, too for maintenance reasons!

Yeah I understand these old devices will stay thanks qualshit, but xperia should be upgrading to 4.4 due many benefits. It can't be so large task..

Also kernel 4.4 brings security benefits. That's it.

Kernel is important that's the whole operating system base, so it's not good idea to stay old base and build Operating system on it. Even when limited resources avaiable.

For a company as small as jolla it makes sense to stay at 3.10 for xperiaX, too for maintenance reasons!

Luckily they can leverage the ground work that Sony does for the XperiaX :

Sony Mobile have published an upgraded kernel 4.4 for Loire platform (for Xperia X F51xx smartphones) that is available on Android 7 Marshmallow and 8 Oreo.

Jolla has stated publicly that it's they're non-urgent semi-longterm goal to move to a more recent Android 7 base for Sailfish X' libhybris adaptation layer, because that fixes tons of problem (I think a couple of camera issue are fixed among other).

So eventually, we're going to end up kernel 4.4 there.

Now that the whole Meltdown/Spectre debacle is happening, maybe Jolla would be pushing the move to Sony's latest 4.4 kernel a little bit harder.