5 ms·

Does it make sense to compile the linux kernel with -Fhardened?

by tutfbhuf 3y ago

nicce 3y ago
Performance impact would be too much likely. Control-flow integrity protections alone usually apply 5% overhead.
- _a_a_a_ 3y ago
  can you explain what these integrity protections are and why they're needed, or give a link? TIA
  - nicce 3y ago
    Wikipedia summarises it quite well. In short, they attempt to prevent code-reuse attacks (ROP/JOP) https://en.wikipedia.org/wiki/Control-flow_integrity https://en.wikipedia.org/wiki/Control-flow_integrity
- nerpderp82 3y ago
  This line of reasoning will lead to always using insecure systems over secure ones. We lost much larger percentages due sidechannel mitigations. Layout has more effect than -O1 to -03 (Berger et al). Machines have never been faster than they are now, when will they be fast enough to also safe by default?
  - nicce 3y ago
    It is not that simple. Especially in kernel, is the likelihood of bugs so big that we increase the electricity consumption of everyone using Linux by default? Sidechannel mitigations are not valid comparison, since it is protection against known, reproducible issues, not against "maybe there is a serious bug". We should utilize the gains we get in increased computational power instead of wasting everything to inefficient software. Machines are still not efficient enough to use garbage collected languages alone, which do not have the issues these compiler options mitigate. With efficient software, we can reduce the electricity bill and other resources.
    - RetroTechie 3y ago
      "We should utilize the gains we get in increased computational power instead of wasting everything to inefficient software." And yet, horribly inefficient scripting languages are a thing. To save time of 1 or 2 developers ONCE, at the cost of countless users' compute capacity, again & again for as long as that software is used. As long as that is considered acceptable, your argument holds no water. Current hardware is way, way, waaayy fast enough for 99.999% of uses. Hardened software or not.
      - nicce 3y ago
        > As long as that is considered acceptable, your argument holds no water. It is true that it costs more to hire more skilled developers, and for that reason we suffer. (e.g. Electron). But even if that happens all the time, it does not mean that my point is invalid. If we want to reduce the energy waste, it starts from software as well. > Current hardware is way, way, waaayy fast enough for 99.999% of uses. Hardened software or not. For end-users yes, but not for any cloud computing, servers, et. all where the real computing happens. You can make significant saving in terms of required processors, memory and electricity simply by writing more efficient software. Just one method more to make world greener place.
    - MiguelX413 3y ago
      Safety is not the same as inefficiency. What's the point of being fast but wrong?
      - nicce 3y ago
        The point is to focus on making correct code instead of relying into fallback mechanisms. E.g. compare to increased popularity of Rust and what it means in this context.
- chc4 3y ago
  Android already supports enabling kCFI[0], and says they saw negligable performance and code size impact. Even if it was 5%, security mitigations with a large security impact probably make sense to enable for a lot of usecases. 0: https://source.android.com/docs/security/test/kcfi https://source.android.com/docs/security/test/kcfi
  - nicce 3y ago
    There is actually study which notes both Anrdoid and Linux Kernel. On Linux kernel the performance impact was from 2% to up to 25% and size increased around 30%. On Android there was too much variance, but they note that Google got around 2-3% overhead, which sounds reasonable. Without hardware acceleration (e.g. Intel CET), it will likely come with great cost. But we are yet to see those benchmarks. But I would argue that you can take bigger impact for performance on Android or consumer phones anyway, since they are not performing high computation 24/7 usually, and they already have more computation power than most users require. https://www.duo.uio.no/bitstream/handle/10852/79829/master.pdf?sequence=8&isAllowed=y https://www.duo.uio.no/bitstream/handle/10852/79829/master.p...
rwmj 3y ago
I don't think it would work. Linux uses internal string functions while _FORTIFY_SOURCE works with help from glibc, plus PIE is just not an appropriate memory model for kernel code.
josefx 3y ago
Hardening flags can be problematic depending on which assumptions they make. Some years ago Golang ran into problems with kernels proactively checking for the stack guard page, since Go doesn't use any that safety feature just ended up corrupting random memory on every system call.
- dmix 3y ago
  Did Go address these issues or is it more fundamental?
  - josefx 3y ago
    They switched to using a C shim for system calls like they where already using for other operating systems without a stable/public system call interface. I think the affected distros also ended up removing the check over other issues.

Does it make sense to compile the linux kernel with -Fhardened?

nicce 3y ago

Performance impact would be too much likely. Control-flow integrity protections alone usually apply 5% overhead.

_a_a_a_ 3y ago
can you explain what these integrity protections are and why they're needed, or give a link? TIA
- nicce 3y ago
  Wikipedia summarises it quite well. In short, they attempt to prevent code-reuse attacks (ROP/JOP) https://en.wikipedia.org/wiki/Control-flow_integrity https://en.wikipedia.org/wiki/Control-flow_integrity
nerpderp82 3y ago
This line of reasoning will lead to always using insecure systems over secure ones. We lost much larger percentages due sidechannel mitigations. Layout has more effect than -O1 to -03 (Berger et al). Machines have never been faster than they are now, when will they be fast enough to also safe by default?
- nicce 3y ago
  It is not that simple. Especially in kernel, is the likelihood of bugs so big that we increase the electricity consumption of everyone using Linux by default? Sidechannel mitigations are not valid comparison, since it is protection against known, reproducible issues, not against "maybe there is a serious bug". We should utilize the gains we get in increased computational power instead of wasting everything to inefficient software. Machines are still not efficient enough to use garbage collected languages alone, which do not have the issues these compiler options mitigate. With efficient software, we can reduce the electricity bill and other resources.
  - RetroTechie 3y ago
    "We should utilize the gains we get in increased computational power instead of wasting everything to inefficient software." And yet, horribly inefficient scripting languages are a thing. To save time of 1 or 2 developers ONCE, at the cost of countless users' compute capacity, again & again for as long as that software is used. As long as that is considered acceptable, your argument holds no water. Current hardware is way, way, waaayy fast enough for 99.999% of uses. Hardened software or not.
    - nicce 3y ago
      > As long as that is considered acceptable, your argument holds no water. It is true that it costs more to hire more skilled developers, and for that reason we suffer. (e.g. Electron). But even if that happens all the time, it does not mean that my point is invalid. If we want to reduce the energy waste, it starts from software as well. > Current hardware is way, way, waaayy fast enough for 99.999% of uses. Hardened software or not. For end-users yes, but not for any cloud computing, servers, et. all where the real computing happens. You can make significant saving in terms of required processors, memory and electricity simply by writing more efficient software. Just one method more to make world greener place.
  - MiguelX413 3y ago
    Safety is not the same as inefficiency. What's the point of being fast but wrong?
    - nicce 3y ago
      The point is to focus on making correct code instead of relying into fallback mechanisms. E.g. compare to increased popularity of Rust and what it means in this context.
chc4 3y ago
Android already supports enabling kCFI[0], and says they saw negligable performance and code size impact. Even if it was 5%, security mitigations with a large security impact probably make sense to enable for a lot of usecases. 0: https://source.android.com/docs/security/test/kcfi https://source.android.com/docs/security/test/kcfi
- nicce 3y ago
  There is actually study which notes both Anrdoid and Linux Kernel. On Linux kernel the performance impact was from 2% to up to 25% and size increased around 30%. On Android there was too much variance, but they note that Google got around 2-3% overhead, which sounds reasonable. Without hardware acceleration (e.g. Intel CET), it will likely come with great cost. But we are yet to see those benchmarks. But I would argue that you can take bigger impact for performance on Android or consumer phones anyway, since they are not performing high computation 24/7 usually, and they already have more computation power than most users require. https://www.duo.uio.no/bitstream/handle/10852/79829/master.pdf?sequence=8&isAllowed=y https://www.duo.uio.no/bitstream/handle/10852/79829/master.p...

rwmj 3y ago

I don't think it would work. Linux uses internal string functions while _FORTIFY_SOURCE works with help from glibc, plus PIE is just not an appropriate memory model for kernel code.

josefx 3y ago

Hardening flags can be problematic depending on which assumptions they make. Some years ago Golang ran into problems with kernels proactively checking for the stack guard page, since Go doesn't use any that safety feature just ended up corrupting random memory on every system call.

dmix 3y ago
Did Go address these issues or is it more fundamental?
- josefx 3y ago
  They switched to using a C shim for system calls like they where already using for other operating systems without a stable/public system call interface. I think the affected distros also ended up removing the check over other issues.