| 23 Nov 2024 |
 Tristan Ross | https://github.com/NixOS/nixpkgs/pull/335023 anyone around to look at this? I kinda want to use an LLVM kernel but this PR is blocking that. | 05:30:46 |
 emily | while I like the end result, I'm also sceptical of the as32bit/as64bit thing. like is there any AArch64 hardware that implements ARMv5? some of these don't make sense to couple to me | 05:33:29 |
| emily | like why does it condition on just cross-bit size when presumably the same problems would apply to other cross scenarios? | 05:33:47 |
| emily | AFAICT cross shouldn't care if the build and host architectures are "similar" ISAs | 05:34:31 |
| Tristan Ross | In reply to @emilazy:matrix.org
while I like the end result, I'm also sceptical of the as32bit/as64bit thing. like is there any AArch64 hardware that implements ARMv5? some of these don't make sense to couple to me I'm not sure. | 05:34:35 |
| emily | they should be independent | 05:34:36 |
| emily | I think what you really want is https://github.com/NixOS/nixpkgs/pull/354622. | 05:34:54 |
| Tristan Ross | The problem is I needed a way to figure out it was compiling for 32-bit or 64-bit | 05:35:22 |
| Tristan Ross | And then apply the specific hardening options which are applicable | 05:35:34 |
| Tristan Ross | In reply to @emilazy:matrix.org
I think what you really want is https://github.com/NixOS/nixpkgs/pull/354622. I'm kinda skeptical if that does fix the problem, would it remove incompatible hardening options when cc-wrapper is compiling a 32-bit object with a 64-bit stdenv? | 05:36:48 |
| emily | it would completely separate host and build hardening flags | 05:37:03 |
| emily | why would incompatible hardening flags be getting set at all? | 05:37:11 |
| emily | only due to build–host–target confusion | 05:37:18 |
| emily | separating them out fully is the solution, not hacking around it by trying to filter things out after the fact | 05:37:28 |
| Tristan Ross |
As the title says, this disables incompatible hardening options when cross compiling between the same ISA but different bit size. This prevents the issue of the zerocallregs hardening option from being used when using clang to build Linux and Linux is building for aarch64 but builds vdso32.
From my PR
| 05:37:35 |
| Tristan Ross | zerocallregs isn't supported in 32-bit but it is in 64-bit | 05:37:58 |
| Tristan Ross | vdso32 is compiled as 32-bit | 05:38:07 |
| emily | yes but we only set hardening flags that are meant to be supported by the platform | 05:38:16 |
| emily | it's just that we don't mangle them properly | 05:38:20 |
| emily | if the issue is invoking wrappers designed for AArch64 but feeding them 32-bit ARM code that's just a general problem of wrappers assuming one specific architecture | 05:38:53 |
| emily | using an unwrapped compiler probably makes more sense for that | 05:39:01 |
| emily | especially with LLVM | 05:39:17 |
| Tristan Ross | Using an unwrapped compiler doesn't feel optimal, what if something needed to output 32-bit code on a 64-bit system but required libc or other stuff which the cc-wrapper needs. | 05:40:40 |
| emily | that won't work anyway because it'll be the 64-bit libc… | 05:40:57 |
| emily | so in that case you need another wrapper | 05:41:07 |
| emily | and rewrapping compilers is more of a pain than it ought to be right now, but that's a separate issue | 05:41:18 |
| Tristan Ross | The other option is we just don't do any kernel hardening lol | 05:42:21 |
| Tristan Ross | * The other option is we just don't do any kernel hardening via the stdenv lol | 05:42:36 |
| Tristan Ross | I think the kernel has stuff for enabling hardening inside the config | 05:42:52 |
| emily | the simple option is just to use an unwrapped compiler for the VDSO build, since it should not be depending on libraries anyway given what the VDSO is | 05:43:00 |
