Ask / Submit

Kernel Memory Leaking

Tracked by Jolla

asked 2018-01-03 14:36:06 +0300

lakutalo gravatar image

updated 2018-01-04 18:37:11 +0300

lpr gravatar image

New security flaw discovered in Intel CPU architecture:

ARM64 and ARM-v7 seems to be affected, too.

edit 20180104 by lpr: Meltdown CVE-2017-5754 Spectre CVE-2017-5753 and CVE-2017-5715
JollaTablet affected by all three vulnerabilities...
Jolla1 and Xperia/Sailfish X: most likely affected by Spectre (Jolla1-Krait core related to Cortex-A15 with out-of-order Execution
JollaC / aquafish most likely not affected (Cortex-A7 in-order Execution only)
"it is unclear whether ARM and AMD processors are also affected by Meltdown" (Variant3), but Jolla1 and XperiaX affected by a related Variant3a

edit retag flag offensive close delete



In my understanding, ARM systems may be patched to prevent any risk of leakage. No explicit bug detected so far.

objectifnul ( 2018-01-03 14:58:59 +0300 )edit

So far. All affected systems have to be patched at OS level. Some of them will suffer performance drawdown.

lakutalo ( 2018-01-03 15:07:11 +0300 )edit

Well... it's broken on AMD, ARM and Intel CPUs. I hope Jolla will release this alongside 2.1.4

pisarz1958 ( 2018-01-04 01:52:35 +0300 )edit

Thanks for your ancillary detailedness @lpr, much appreciated!

lakutalo ( 2018-01-04 18:34:48 +0300 )edit

Among my readings on the subject, I understand that corrections of these faults are going to impact on the performances of the processor between 5 and 30 % to see 50 % of calculation time :-(

For my Jolla 1 what is going to be the impact of the patch in term of performances?

mips_tux ( 2018-01-04 18:42:40 +0300 )edit

5 Answers

Sort by » oldest newest most voted

answered 2018-03-20 00:11:06 +0300

lpr gravatar image

Spectre mitigations happened now with LTS Kernel updates to 3.2.101 (|1| |2|) and 3.16.56 (|1| |2|) (and x86-asm for Tablet) and now Jolla should be able to port them to kernel-3.4 (jolla1) and kernel-3.10 (xperia, etc.)

edit flag offensive delete publish link more

Thanks for keeping track of this!

lakutalo ( 2018-03-20 09:17:25 +0300 )edit

answered 2018-01-05 20:11:21 +0300

AkiBerlin gravatar image

updated 2018-01-06 19:03:56 +0300

If I understand correctly, Jolla C (Snapdragon 212, 4 Cortex A7 units) is not affected but Xperia X (Snapdragon 650, 4 Cortex A53 and 2 Cortex A72 units) is, see ARMs publication

EDIT: lpr is right: my answer is at least redundant because it doesn't add anything. I didn't read the updated question before posting my answer. Please apologize.

edit flag offensive delete publish link more



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

lpr ( 2018-01-06 00:01:12 +0300 )edit

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

AkiBerlin ( 2018-01-06 18:50:27 +0300 )edit

answered 2018-01-04 02:00:13 +0300

olf gravatar image

updated 2018-01-04 02:23:10 +0300

Only Intel x86 CPUs have this design bug (but for at least 10 years!), which KPTI (aka KAISER aka FUCKWIT) addresses by vigorously separating Kernel and User address spaces (specifically by separating the MMU's translation tables and TLBs as much as possible by software / the kernel; something which was assumed to be granted by the hardware, before this surfaced).
There is no reason to assume that AMDs x86 CPUs (AMD's Tom Lendacky already stated that their designs are not affected) and other CPU designs (e.g. ARM, MIPS) have this hardware bug, as it is the side effect of an incorrectly implemented optimisation designed by Intel engineers (i.e. it is extremely unlikely that another CPU design team implemented the same optimisation in exactly the same, faulty way). As this optimisation was developed by Intel, supposedly it is patented or was a company secret before this revelation (haven't done a tedious patent research yet, as most likely others will).

But as KASLR (Kernel Address Space Layout Randomization) has been shown to be circumvented a few times (and thus enhanced thereafter a couple of times already, even though most of these "attacks" were impractical to use, i.e. rather academic), a better separation of Kernel and User address spaces is a good hardening measure: That is why the changes for Intel x86 CPUs are considered to be adapted by others as well.

Well, to be honest, while glancing over the ARM64 changes, I am a little bit surprised to see ARM (the company) reacting quickly with such a large and intrusive set of changes. Maybe they really have some reason to be afraid, too, as this would have been a chance to calmly state "Not our business", as AMD did. Still, as ARM64 is an completely independent design and architecture compared to x86, at most it is some similar, but not the same hardware design flaw they are trying to cover up.
More likely it is just a hardening measure, roughly following the KPTI design (now that the Kernel infrastructure for this is already there), which is also easier to implement for ARM64 (and presumably with far less of a performance hit, i.e. negligible in contrast to x86).

For Intel this is a doomsday scenario, far worse than the much hyped Pentium FDIV bug 20 (or was it 25) years ago. It will be interesting to see how they handle this politically.

edit flag offensive delete publish link more



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.

emva ( 2018-01-04 14:27:19 +0300 )edit

@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, 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 ( 2018-01-04 23:19:02 +0300 )edit

@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 ( 2018-01-04 23:28:05 +0300 )edit

@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.

olf ( 2018-01-04 23:55:17 +0300 )edit

answered 2018-01-04 12:21:00 +0300

objectifnul gravatar image

updated 2018-01-04 12:24:14 +0300

As from now we need two PC's and two smartphones, 'p' for 'private' and 'c' for 'connected'. 'p' devices will never be connected (no network, no SIM card), will host all our encryption/decryption tools and all our private stuff. 'c' devices will never see any confidential content in plain. Data transfers between 'p' and 'c' devices will be done offline only. Am I good?

edit flag offensive delete publish link more



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

pisarz1958 ( 2018-01-04 12:22:54 +0300 )edit

A middle solution:

HeinrichJolla ( 2018-01-04 15:44:09 +0300 )edit

qubes is also vulnerable to speculative execution cache sidechannel attacks

juiceme ( 2018-01-04 17:30:13 +0300 )edit

@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.

HeinrichJolla ( 2018-01-05 16:44:42 +0300 )edit

answered 2018-01-17 15:06:36 +0300

Leon gravatar image

updated 2018-01-17 15:08:38 +0300

Right now the ARM64 set of patches for the Meltdown issue are not merged into Linus’s tree. They are staged and ready to be merged into 4.16-rc1 once 4.15 is released in a few weeks. Because these patches are not in a released kernel from Linus yet, I can not backport them into the stable kernel releases (hey, we have rules for a reason…) Due to them not being in a released kernel, if you rely on ARM64 for your systems (i.e. Android), I point you at the Android Common Kernel tree [1] All of the ARM64 fixes have been merged into the 3.18, 4.4, and 4.9 branches as of this point in time.I would strongly recommend just tracking those branches as more fixes get added over time due to testing and things catch up with what gets merged into the upstream kernel releases over time, especially as I do not know when these patches will land in the stable and LTS kernel releases at this point in time. [2]

SFOS is on kernel 3.4 and SFOSX is on 3.10 - how feasable is it to move up to kernel 3.18?



edit flag offensive delete publish link more


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

Jk ( 2018-01-17 16:36:52 +0300 )edit

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!

lpr ( 2018-01-17 17:26:45 +0300 )edit

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.

Jk ( 2018-01-17 22:10:56 +0300 )edit

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.

DrYak ( 2018-01-29 17:41:45 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2018-01-03 14:36:06 +0300

Seen: 2,885 times

Last updated: Mar 20 '18