~~Blacklisted kernel modules~~ hardened kernel causes mouse to not function

RobbieGM commented 2 years ago

Describe the bug

When using the hardened profile, my Rosewill neon M60 mouse no longer works.

Steps To Reproduce

Unfortunately reproducing this may or may not require having my exact mouse. But using the hardened profile caused it to no longer work.

Expected behavior

The mouse should function. Obviously I don't expect you to make a substitute kernel module for the qnx ones (which were suggested to be potentially insecure), but maybe a warning in the configuration file is in order.

Additional context

After comment-bisecting a copy of hardened.nix, I found that blacklisting the "qnx4" and/or "qnx6" module caused the issue (I didn't bother doing the last bisection.)

Notify maintainers

@joachifm @emily

Metadata


 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.43-hardened1, NixOS, 22.05 (Quokka), 22.05.518.7a20c208aac`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.8.1`
 - channels(root): `"nixos-22.05"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos```

RobbieGM commented 2 years ago

I take it back; those kernel module blacklists weren't actually the culprit. It was the hardened kernel causing the mouse to not function, but only sometimes. Also the hardened kernel causes VS code to not launch, and instead generate a "core.2837" (or some other 4 numbers afterwards) file in the directory you tried to launch it from. This file looks like an executable (starts with ^@ELF), but it's not actually executable.

joachifm commented 2 years ago

@RobbieGM this sounds similar to issues discussed at https://github.com/NixOS/nixpkgs/issues/161964.

RE: the modules you mention initially, they are filesystem related so I wouldn't expect them to affect peripherals.

RE: the VS code crash, it may be related to allocator hardening. The hardened allocators tend to be stricter than the libc allocator and turn memory allocation "bugs" into application crashes, on the theory that it's better to crash immediately than to risk bugs being used as part of an exploit. You may use gdb or similar to inspect the coredump, it should tell you what's going on at the time of the crash. If the underlying cause is a "bug" in vscode your only short-term recourse is to disable allocator hardening.

NixOS / nixpkgs