| 23 Nov 2024 |
 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 |
| Tristan Ross | How would we set the compiler just for the vdso? | 05:43:27 |
| Tristan Ross | Would we have to build up to the vdso, change the CC for the vdso, and then finalize the build? | 05:44:01 |
| Tristan Ross | Another option is to tune the hardening option, disable the zerocallregs hardening option when the derivation is set to build the vdso32 | 05:45:19 |
| emily | I'm not that familiar with the kernel build system, but I'd be surprised if there's no configuration knob for the compiler it uses to build 32-bit code like that | 05:46:42 |
 connor (burnt/out) (UTC-8) | After spending too long debugging runtime oddities I tracked the issue back to bad symlinks.
Having read https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/setup-hooks/make-symlinks-relative.sh, I made a setup hook which checks for broken (or reflexive) symlinks: https://github.com/ConnorBaker/cuda-packages/blob/main/upstreamable-packages/noBrokenSymlinksHook/no-broken-symlinks-hook.sh
Is there prior work for something similar?
This is also based on the assumption that broken or reflexive symlinks are symptoms of a packaging problem. Are there cases where they are intended? | 08:57:48 |
 K900 | There are definitely situations | 10:22:26 |
| K900 | But not many | 10:22:27 |
| K900 | I actually wanted that in stdenv for a while now | 10:22:37 |
| connor (burnt/out) (UTC-8) | I’d like to add the ability to detect cycles in references.
Additionally, I’d love to simplify the logging statements so I don’t have to prefix the strings with the name of the setup hook. Any ideas if that’s a thing? | 19:53:57 |
| 24 Nov 2024 |
| Tristan Ross | emily John Ericson Philip Taron (UTC-8) Randy Eckenrode & Artturin: have you guys seen this post (https://discourse.nixos.org/t/community-team-updates/56458) should we do a meeting to discuss things to add for a reply to the post or do we just want to message in here? | 02:36:45 |
| emily | p14: uh-oh.
clang-13: error: argument unused during compilation: '-nostdlibinc' [-Werror,-Wunused-command-line-argument]
| 03:28:29 |
