AMD Radeon Graphics Driver "AMDGPU" Ported To DragonFlyBSD

[Developer12]

Ain't much better on Linux, its just partially covered against Spectre V1.

Linux is a lot better than "partially" covered. User pointers are sanitized. Gadgets are scanned for and removed. Memory barriers are inserted and various calculated pointers are masked.

Upgrade your hardware if it bothers you so much. It's the only effective fix against Spectre V1 anyway.

There isn't a hardware mitigation for Spectre v1. It's not currently possible for hardware to control speculation into dereferences (eg accessing arrays) and enforce bounds checks. It can't know the bounds that should be applied to a dereference. It's also not possible for hardware to know what conditionals represent a bounds check in the first place (and thus shouldn't be speculated on).

Thus, the series of software mitigations above, from sanitization, to removal, to masking and memory barriers.

If you are whining about it just to show how OpenBSD is insecure, sucks etc yada-yada.. kindly take a look at Linux and systemd's CVE's over the past three years and shut up.

I'm not running systemd. People find CVEs in linux because they actually bother to look. It's a sad fact but the reason BSD was late to being notified about spectre is because nobody cares to check.

If BSD can't be bothered to patch known vulnerabilities long after they've been told, then I have to stick with the kernel that's *actually* proactive instead of claiming to be.

[aht0]

"proactiveness" - HT was disabled year+ before Spectre/Meltdown..
memory barriers/masking exists (since OpenBSD 5.5)
sanitizers - ubsan, libFuzz, XRay Instr.

Also OpenBSD kernel is compiled as a whole (no modules any more) and it's exposure to user space (Spectre V1 attack vector) is as minimal as could be. Which could additionally restricted by pledge restricting syscalls/ioctl/sysctl.

So, still can't see what you are foaming your mouth about.


Doesn't matter whether you are using even systemdless linux. Fix your own backyard before going to comment on others. Or worse, don't expect it to be similar mess as your own.

[Developer12]

[QUOTE=aht0;n1291101]"proactiveness" - HT was disabled year+ before Spectre/Meltdown..
memory barriers/masking exists (since OpenBSD 5.5)
sanitizers - ubsan, libFuzz, XRay Instr.]/QUOTE]

You're not paying attention *at all.* None of that applies to spectre v1.

If it did, then the mitigation statuses for that vulnerability would probably show something, now wouldn't they?

I'm talking about specific mitigations to spectre v1. Memory barriers inserted before a userspace pointer dereference. Pointers unconditionally masked to limit where a speculative thread may read from. Sanitizers to check for spectre v1 dereference gadgets, which they're clearly not running considering they've removed exactly *zero* of them.

Also OpenBSD kernel is compiled as a whole (no modules any more) and it's exposure to user space (Spectre V1 attack vector) is as minimal as could be. Which could additionally restricted by pledge restricting syscalls/ioctl/sysctl.

Wrong spectre variant. Spectre v1 can be triggered on any userspace-provided pointer, or any pointer calculated using a value controlled by userspace. That leaves a LOT of potential attack surface and is the reason mitigations in linux take so many different forms to provide good coverage.