!eWOErHSaiddIbsUNsJ:nixos.org

NixOS CUDA

289 Members
CUDA packages maintenance and support in nixpkgs | https://github.com/orgs/NixOS/projects/27/ | https://nixos.org/manual/nixpkgs/unstable/#cuda57 Servers

You have reached the beginning of time (for this room).


SenderMessageTime
8 Feb 2025
@adam:robins.wtf@adam:robins.wtf left the room.21:22:28
9 Feb 2025
@ss:someonex.netSomeoneSerge (back on matrix) Yes. The only "blocker" is refactoring release-cuda.nix to support specifying jetson platforms instead of sbsa 04:21:13
@ss:someonex.netSomeoneSerge (back on matrix) * Yes. The only "blocker" is refactoring release-cuda.nix to support specifying jetson platforms instead of (or in addition to? does anyone use) sbsa 04:21:29
@stick:matrix.orgstickYes, GH200 is SBSA iirc19:44:53
@ruroruro:matrix.orgruro

I am currently working on fixing cuda-samples. I wanted to bikeshed a bit more about its dependency on the insecure freeimage package. I still think that in general having eval errors for insecure package dependencies is useful. Afaik, the official hydra builders don't build insecure packages, so I am kind of against setting allowInsecure/allowInsecurePredicate/permittedInsecurePackages in release-cuda.nix.

On the other hand, it's kind of silly to treat cuda-samples as insecure just because it depends on freeimage. Most of the code in cuda-samples is for demonstration/validation purposes only, a lot of it doesn't even have proper error checking and shouldn't be used in production anyway. So it is extremely weird to refuse building cuda-samples just because there are some potential buffer overflow exploits or whatever in the library it uses for image reading.

I still think that we should just change freeimage to

freeimage.overrideAttrs (prev: {
  meta = prev.meta // {
    knownVulnerabilities = [ ];
  };
})

specifically only in the cuda-samples derivation.

However, if not shipping "vulnerable" binaries is so important, then we could keep cuda-samples broken, but introduce a separate cuda-samples.passthru.buildCheckOnly derivation that ignores the freeimage "vulnerabilities", but then replaces its installPhase with something along the lines of touch $out. That way, we keep cuda-samples.buildCheckOnly as a useful smoke test, but don't distribute any "potentially vulnerable" binaries. Though, TBH, this sounds like over-engineering and we should just override freeimage.knownVulnerabilities in cuda-samples specifically.

Any thoughts?

20:24:30
@stick:matrix.orgstickwhat exactly is the purpose to have samples packaged in nixpkgs? my first intuition tells me this does not belong to nixpkgs at all22:13:09
@stick:matrix.orgstickmaybe just like a sanity check whether things compile22:17:59
@ruroruro:matrix.orgruroAlthough they are called "samples", in reality I'd say that some of them are closer to debugging utilities, tests or benchmarks. And by "tests" I mean both for verifying that they successfully compile (although currently not all of them do) and for running them on the target machine to verify that the nvidia card works as expected.22:18:12
@ruroruro:matrix.orgruro A lot of these binaries run some computation on the GPU, verify the results, print some information and then report Result = PASS or something. Unfortunately, the output format of these binaries differs too much and running them requires access to the GPU, so it's basically impossible to create a "proper" nixpkgs test from them. But checking that they compile successfully and providing the resulting binaries to the users is still useful. 22:21:34
@ruroruro:matrix.orgruro * A lot of these binaries run some computation on the GPU, verify the results, print some information and then report Result = PASS or something. Unfortunately, the output format of these binaries differs too much and running them requires access to the GPU, so it's basically impossible to create a "proper" nixpkgs test from them. But checking that they compile successfully and providing the resulting binaries to the users is still useful (IMHO). 22:22:10
@connorbaker:matrix.orgconnor (burnt/out) (UTC-8)Does a patched version of freeimage exist, or is it abandoned? If there is a newer version, I’d be interested in whether, as a longer term goal, it’d be possible to update the samples to use it.23:21:11
10 Feb 2025
@stick:matrix.orgstickRedacted or Malformed Event00:11:29
@stick:matrix.orgstick
In reply to @connorbaker:matrix.org
Does a patched version of freeimage exist, or is it abandoned? If there is a newer version, I’d be interested in whether, as a longer term goal, it’d be possible to update the samples to use it.

It seems there is a fork

https://github.com/danoli3/FreeImage

00:11:48
@stick:matrix.orgstick

Readme says:

This GitHub Fork/Patch of FreeImage

  • Numerous Sub-Dependancy patches (Security/Bugs/Latest)
  • With patches applied from nVidia Devs and OpenSource additions
  • CMake Build ability allowing compiling easily for all targets and platforms
00:12:38
@stick:matrix.orgstickI think we should use this instead (not only for cuda-samples but for all nixpkgs)00:13:19
@me:caem.dev@me:caem.dev joined the room.00:48:53
@ruroruro:matrix.orgruroAFAIC, FreeImage is "undead". I think I read that the original devs insist that it is still being maintained, but they are stubbornly stuck on SourceForge and the last official release was in 2018. :sigh:02:59:55
@ruroruro:matrix.orgruro

I guess, the relevant questions would be:

  1. Is it backwards compatible with the older official versions of FreeImage?
  2. Is there some sort of consensus around this fork being a good replacement?
  3. Which CVEs does this fork fix?
  4. Are these fixes verified / documented by whatever authorities published the original CVEs?
03:04:46
@ruroruro:matrix.orgruroTaking a cursory look at that repository, it seems that the original author just commited the whole SVN repo instead of importing the history from SVN, which is kind of annoying/problematic.03:08:43
@ruroruro:matrix.orgruro* Taking a cursory look at that repository, it seems that the original author just commited the whole SVN repo in the initial commit instead of importing the history from SVN, which is kind of annoying/problematic.03:09:06
@stick:matrix.orgstick another option would be to just remove freeImageInteropNPP from the cuda-samples build 08:19:23

Show newer messages


Back to Room ListRoom Version: 9