For Fairphone they list the kernel of FP3 (4.9), FP4 (4.19) and FP5 (5.4) in figures 11+12
We analyze devices from 2018 to 2023 using
Android versions 9 to 14 and kernels ranging from v3.10 to
v6.1. In total, we analyze 994 device firmwares and 1533
Android kernel source codes. Our results suggest that the
level of security that is actually reached is severely lacking
compared to the mainline Android kernel.
I haven’t read the research paper in detail, but by simple logic I would think, if Fairphone comes up last with the lowest score, the probability is rather high that they are amongst those companies that have not enabled all the security defenses which come at a performance cost (at least not on all models).
Or looking at it from the other way round, how would Fairphone come up last, when they have enabled all performance related defenses? By not enabling the defenses without the performance penalty. Which to me sounds rather absurd. Sure, from the outside I can’t rule this out as one possibility.
But of course you are right, we don’t know the exact loss of performance the individual configs would cause on any given device.
Just as an example: on desktop computers the mitigations in software to make the hardware bug called Spectre unexploitable resulted in 2–14 percent drops in benchmarks on then current hardware with the hint that older computers suffered more.
Always? 
I just want things to be factual. When we have to assume the results of a publication, then we might be wrong in the details.
They mention Fairphone, but they don’t expand on their results specifically.
There is a difference between kernel versions and compile and run-time flags. Having version X doesn’t mean you actually have feature Y enabled.
I get the reasoning. And it’s likely the case. As I mentioned, I didn’t read the PDF. From what I did see when they mentioned FP they don’t share details. I can also not say “this kind of research would never pass on my university”, because again, I didn’t read it 
But when we have to assume the results and conclusions of a research, it’s not great writing IMHO.
Indeed! And those features can be disabled. If the workload on a server doesn’t need those protections because of the defined use case, you can disable them with ease. No need for a new kernel build. Would be cool if people can enable these things themselves (if the protection is really needed and if Android allows that kind of control without root).
Anyway, I guess I’ll just conform and assume as well that the kernel of the FP models doesn’t have these hardening settings (maybe more than just the ones mentioned).
Not the best by any means, but since I don’t want to read it myself, ChatGPT made this summary:
That must be the future… that I don’t want to be in…
The future is already here Work smart, not hard. I don’t think anyone here read that PDF here, but did have assumptions/conclusions. ChatGPT doesn’t make it worse 
The only thing we need to discuss now is the fact that we are in last place. That is factual.
Thanks for posting the article from heise!
I read the article. It disappoints me about Fairphone and I am concerned. Although the article mentions that Fairphone took note of the investigation, I find the explanations (I can hardly write ‘explanation’) in this thread insufficient. Nevertheless, I am sure that Fairphone will take care of it and harden the kernel so that the results of the TU Graz investigation will soon become irrelevant.
fwiw here are the changes used in my DivestOS:
automated kernel hardening: DivestOS-Build/Scripts/Common/Functions.sh at master · Divested-Mobile/DivestOS-Build · GitHub
automated kernel CVE patching:
the paper is interesting in its repeated mention of CONFIG_DEBUG_LIST, the issue there is in 2019 there was a nasty zero-day that Google found and at the time only GrapheneOS and my DivestOS had DEBUG_LIST enabled which mitigated the issue.
Incomplete data leads to incomplete conclusions So I don’t really agree with that conclusion below. But I hope FP will explore solutions. Maybe they just don’t know about these kernel flags and just roll a vanilla kernel as much as possible. We only guess at this point, and that makes the discussion a bit organic 
AOSP has explicit configuration recommendations for kernels.
FP4 should line up with this config for example, which does recommend CONFIG_DEBUG_LIST: r/android-4.19/android-base.config - kernel/configs - Git at Google
That specific recommendation was added over four years ago, a whole year before FP4 was released: a3e93c95c30e9b56ed2ea3efb849092046b48ee9 - kernel/configs - Git at Google
And Fairphone did actually use those configs afaict.
But the charts and analysis in the paper was less about configs and more about patch times.
They only mention configs as ways to mitigate issues on primarily unpatched kernels.
There seems to be some mixup in this thread about that.
Finally found some time for this paper. If my reading is correct, then I think one thing is very important to understand: the analysis they performed is centered around kernel techniques that proactively prevent exploitation. On the surface it might look like they’re saying “here’s a list of CVEs, and unless the mitigations with a tick in Table 2 are enabled you’ll be vulnerable for this”, but this is not true. For example, CVE-2020-0423 was fixed upstream in kernel 4.19.160, and any kernel with that patch in won’t be vulnerable. What the paper is instead instead arguing (and IMHO they could have been clearer about this) is that if those mitigations with the tick in their respective rows were turned on, the exploit would have failed even if the bug isn’t patched. However, I’m reasonably hopeful that a lot of these bugs have been patched, so don’t panic… yet!
Two observations:
Point 1 is interesting because it kind of underscores my point that the Android kernel development model of “fork LTS to downstream, hack drivers into it until it works, never rebase” is harmful. kmalloc-cg-* sounds like a genuinely good technique for security, and for the FP4 we could have had it if not for this downstream model. There’s no HW requirements, just an upgrade to a 5.15 kernel. Which would be a (long) walk in the park if most drivers and the device tree skeleton were upstream. But Qualcomm didn’t let us have it.
Point 2 I mention because I was initially surprised that this option was mentioned as a mitigation. I’ve dabbled a bit in kernel development, and am pretty sure that this was specifically meant for debugging schedulers and drivers, but not for production systems. On the surface, the overhead of these additional checks aren’t so bad, it’s two if-statements with a few memory accesses so wouldn’t be more than 100 cycles. The problem is that these linked lists are used in so many places, including in the highly performance-critical task scheduler. You’d be executing these checks tens of thousands of times per second, and that adds up. Obviously I didn’t benchmark the difference, but I wouldn’t be surprised if it leads to a loss of battery life measured in percentages (and higher heat dissipation etc). I have some sympathy for the OEMs that say this option is just too expensive to enable by default.
On an unrelated note: when I read their methodoloy around seeing which mitigations were enabled (i.e. looking at kallsyms), I wondered whether these symbols would indeed be present in optimised kernel binaries. Especially those with underscore-prefixes would only be used internally, and therefore fair game for the compiler to inline for the sake of a faster kernel. In fact, __list_add_valid() is marked as __always_inline in the kernel source code, meaning it’s likely to not show up. Anyone has an answer to that?
Doing both seems right to me. Which is what Google seems to do as well. Harden the system and patch in time 
I’m just going to assume you’re right here, since I’ve been already a bit too much of a critic in this thread This kind of evaluation is exactly what I’m talking about which is somewhat missing in the research. What kind of mitigations does FP have that reach the same goal to a certain extend is not much explored, right?
That’s what I mean with incomplete information leads to incorrect conclusions.
That’s interesting! I’ll see if I have time today to read that part a bit. Thanks for your analysis and pointers!
Such papers never contain the raw data. But they do have table 5 that shows the percentage of models that have enabled each of the 12 defenses. As Fairphone only has 3 models, the numbers are either 0, 33, 67, 100. Of course that doesn’t end up in the AI summary
That’s indeed an informative table! You can ask ChatGPT to include tables though.
This is what table 2 is conveying. For each of the CVEs you only needed one mitigation to mitigate successfully. So for a row with multiple ticks, any of those ticked mitigations will do.
offtopic
You have to read and understand the paper to know which questions to ask ChatGPT.
I think logic looks different 
Nah, that’s not really how it works. You can ask many generic questions to get more info from AI. I don’t know if you use it, but you can gain a lot. But you’re not the first one that’s sceptical about using AI.
Still, in any context reading the original text is important, because formulations and subtext can help you understand subtle details which would literally be lost in translation: There is a reason serious scientific papers have an extensive bibliography section and mention precisely their quoted sources: It allows you as a reader to better understand where the writer is coming from.
ChatGTP (or any other LLM) is far from giving you the same understanding. It’s like having a highly specialized, difficult scientific paper resumed by some clueless undergrad. Actually worse, make it “resumed by some clueless layman”. Because LLMs don’t understand what they read, they just analyze the language.
But we’re going OT here. If you think LLMs are your sure-fire ticket to heaven, be my guest. 
Just learned that kernel 6.6 added the option CONFIG_LIST_HARDENED, which is a light-weight alternative to CONFIG_LIST_DEBUG. If only we could easily rebase to a 6.6 kernel 
(Although, in fairness, I suspect that CONFIG_LIST_HARDENED is not too difficult to back-port. Might be dragons though, who knows 
)
