Fixed
Status Update
Comments
da...@gmail.com <da...@gmail.com> #2
```
$ clang --version
Ubuntu clang version 17.0.6 (++20231209124227+6009708b4367-1~exp1~20231209124336.77)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
```
$ clang --version
Ubuntu clang version 17.0.6 (++20231209124227+6009708b4367-1~exp1~20231209124336.77)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
```
kr...@arm.com <kr...@arm.com> #3
Thank you for the report. We are investigating the details on this issue before making a decision on how to proceed.
pi...@google.com <pi...@google.com> #5
There are kernel patches under review to disable LTO for the source file with -mbranch-protection=none. We'd prefer to keep this issue under embargo until the kernel fixes are accepted, backported, and a patched kernel is released to users.
pi...@google.com <pi...@google.com> #6
(Please add/cc samitolvanen@google.com from Android Kernel side. I am unable to do it myself).
ma...@google.com <ma...@google.com> #7
[Empty comment from Monorail migration]
pe...@arm.com <pe...@arm.com> #8
Adding daniel.kiss@arm.com whom is working on a fix.
da...@arm.com <da...@arm.com> #9
I have patches to upstream to LLVM that fixes this issue in the LTO linker..
I'll not mention the security relevance of the change, it just correct the LTO linker's behaviour.
Please let me know if I should hold the patch back.
I'll not mention the security relevance of the change, it just correct the LTO linker's behaviour.
Please let me know if I should hold the patch back.
pi...@google.com <pi...@google.com> #10
Thanks for the fixes Daniel! From the Android team, it's ok to merge the fixes without mentioning the security relevance or affected projects.
pi...@google.com <pi...@google.com> #12
Android side remediations have been merged. It's ok from our side to make this public once the LLVM patches are merged.
Another request was to backport the fixes to llvm-18.
Another request was to backport the fixes to llvm-18.
da...@arm.com <da...@arm.com> #15
update: All patches for this landed in main and stick for a week now.
reproducer no longer work (6b98ab95f0d36705b5a1fc1e755c992ba2329c89 - as of today).
reproducer no longer work (6b98ab95f0d36705b5a1fc1e755c992ba2329c89 - as of today).
kr...@arm.com <kr...@arm.com> #16
[Empty comment from Monorail migration]
Description
Let's say there are 2 modules and we want to build them using LTO, one with PAC (Pointer Authentication Code) and the other without PAC.
```
echo "int f(int x, int y) {return x+y;}" > f.c
echo "int g(int x, int y) {return x*y;}" > g.c
clang -O2 --target=aarch64-unknown-linux-gnu -march=armv8.5-a -arch arm64e -mbranch-protection=pac-ret+leaf -flto f.c -c -o f.pac.lto.o
clang -O2 --target=aarch64-unknown-linux-gnu -march=armv8.5-a -arch arm64e -mbranch-protection=none -flto g.c -c -o g.nopac.lto.o
ld.lld -r f.pac.lto.o g.nopac.lto.o -o bug
```
As a result, both modules will be built without PAC:
```
$ llvm-objdump -d bug
bug: file format elf64-littleaarch64
Disassembly of section .text.f:
0000000000000000 <f>:
0: 0b000020 add w0, w1, w0
4: d65f03c0 ret
Disassembly of section .text.g:
0000000000000000 <g>:
0: 1b007c20 mul w0, w1, w0
4: d65f03c0 ret
```
This behavior can lead to a significant expansion of the attack surface in the case of code reuse attacks.
As a workaround, you can compile modules where you need to disable PAC, without LTO. Or selectively set the branch-protection=none attribute for certain functions, it seems that this works as expected with LTO enabled.