OpenBSD 7.1 Released With Apple Silicon Support "Ready", AMD RDNA2 Graphics

[Developer12]

And pray tell me, what is the most obvious & and highest-risk attack vector? Web browser.
System sources come from FreeBSD's project repositories, same with optional programs.

There is no "Linux (or especially Windows) problem" of downloading random binaries from semi-unknown 3rd party repos and running those..

Anything you try to install through FreeBSD Ports gets first pulled as it's original upstream source tar (whatever software it happens to be), unpacked, patched by automatic system to make it workable on FreeBSD and compiled/registered in package database.

You don't understand how variant 1 works. A patched program (eg a browser) is protected from attacks, but a patched program can still be used to launch attacks.

So long as the kernel remains unpatched, it can be attacked from a patched browser using spectre variant 1.

[aht0]

Congratulations, your test means nothing because you don't understand what spectre variant 1 is.
Variant one must be patched per-program. The browsers are patched, the kernel is not.

And pray tell me, what is the most obvious & and highest-risk attack vector? Web browser.
System sources come from FreeBSD's project repositories, same with optional programs.

There is no "Linux (or especially Windows) problem" of downloading random binaries from semi-unknown 3rd party repos and running those..

Anything you try to install through FreeBSD Ports gets first pulled as it's original upstream source tar (whatever software it happens to be), unpacked, patched by automatic system to make it workable on FreeBSD and compiled/registered in package database.

[Developer12]

I took trouble to actually TEST your claim out on FreeBSD.
Used leaky.page site for that. Not a shit leaked through. Messed with it quite a bit on that site.

Congratulations, your test means nothing because you don't understand what spectre variant 1 is.

Variant one must be patched per-program. The browsers are patched, the kernel is not.

[aht0]

Or spectre variant 1 mitigations. None of the BSDs do.
And before anyone asks, no, disabling hyperthreading does nothing about spectre v1.

I took trouble to actually TEST your claim out on FreeBSD.
Used leaky.page site for that. Not a shit leaked through. Messed with it quite a bit on that site.

[ayumu]

Was a smooth upgrade; sysupgrade and done.

[Developer12]

Given that definition, removal of the hyperthreading does fix it. When hyperthreading isn't there, v1 cannot be exploited.
If you had Zombieload in mind (which isn't Spectre v1 but different can of worms), that got patched ASAP.

That's where you're mistaken. That definition only covers *some* variants of spectre, *not including* variant 1.

Variant 1 is specifically where memory protection is implemented in software, but the bounds check is speculated on. For example, what if I asked the kernel for information on process 1267 when there are only 511 processes on the system? It would (speculatively) read past the end of the process table and into kernel memory before eventually returning a "process doesn't exist error." Then I fetch what I want from the cache.

That attack has been publicly known since jan 2nd of 2018, over four years ago. And they've done *nothing* about it. The scanning tools exist now to look for spectre v1 gadgets, and even without them they could have at least hardened the call interfaces.

Instead, they disabled hyperthreading, gave a big announcement of "look how much more we care than linux, we're disabling hyperthreading!" and then went basically back to bed. Their list of mitigated variants is spotty at best, where as linux at least has something for everything.

[aht0]

Or spectre variant 1 mitigations. None of the BSDs do.
And before anyone asks, no, disabling hyperthreading does nothing about spectre v1.

Spectre works due to speculative execution leaking memory data through a side channel exposed by hyperthreading

Given that definition, removal of the hyperthreading does fix it. When hyperthreading isn't there, v1 cannot be exploited.
If you had Zombieload in mind (which isn't Spectre v1 but different can of worms), that got patched ASAP.

[hotaru]

So is trim safe to use on encrypted SSDs or not? Does it risk leaking the keys or information about the disk or are the OpenBSD devs just blowing hot air by not implementing TRIM?

https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html

[kylew77]

So, sadly, in this case both of you are partially correct:

Radtraveller is correct that there are drives out there with active garbage collection. Drives originally implemented this ~15 years ago before TRIM and UNMAP were standardized. They do it by scanning the volume in that background, looking for things like free volume bitmaps, and trimming out blocks based on parsing those. One can imagine a slightly more clever version where the drive figures out the LBA's of data structure backing things like bitmaps and tracking updates in real time instead of background scanning, but I am not sure if anyone ever did it that way. Either way around it is strictly less efficient than having the OS tell the drives which blocks to collect, and can cause data loss if the OS ever revs the volume format or uses an access pattern that the drive does not expect:

So it exists, and it is terrible. There are a whole of other problems:

1. It only ever worked with specific filesystems: generally NTFS, HFS+, and the various FAT based filesystems. Maybe some supported of ext2/3/4
2. It completely depended on the filesystem being used in a normal access pattern. Various LVM operations (like an offline repartition) might break those assumption in ways that can lead to data loss if the drive GCes while it is happening.
3. It is completely incompatible with any sort of full disk encryption like BitLocker or FileVault. This is an inherent limitation of the design since to perform active garbage collection the drive needs to read the filesystem structures, but with encrypted filesystems they keys and decryption are handled by the OS and the drive never sees the encrypted blocks. Sit there and wait in your boot loader as long as you want, it won't figure out and blocks to GC.

In practice it is just sitting there dormant and unused on any modern drives these (or hopefully everyone removed it from their controller firmwares after TRIM became prevalent). There are a few reasons for that:

1. Many more people use encrypted filesystems
2. Even people who don't tend use newer OSes which may have newer filesystems (or versions of filesystems) the drives don't understand. Most of these firmwares have to be super paranoid about volume format changes. And since the whole thing was a legacy hack that means that any OS with a new enough volume format change will also be new enough to support TRIM, which means vendors have little incentive to keep revving and incredibly complex piece of code that performs worse).
3. Some of the drives that did support AGC used explicit TRIM commands as a single to disable it, and all modern OSes issue TRIMs.

Back when TRIM was being standardized I had a 50+ page argument on an SSD vendors website where I was asking about the status TRIM in their chipsets. A whole bunch of enthusiasts essentially thought TRIM was unnecessary, and kept asking. It was super depressing because several people who had worked on filesystems, HDD firmwares, and storage controllers chimed in and tried to explain how there was simply no way for the drive to know what blocks were to safe to GC for arbitrary FSes and their implementations, and that TRIM was a necessary interfaces to channel the info from the drive to the OS. Unfortunately we were drowned out. by people who essentially kept asking "But how do you *KNOW* they have not designed a magic algorithm that knows about every volume format and the access pattern of every implementation of those formats and can magically decrypt everything to do GC correctly?" Clearly I found it scarring since I felt motivated to create an account here to post this ;-)

So is trim safe to use on encrypted SSDs or not? Does it risk leaking the keys or information about the disk or are the OpenBSD devs just blowing hot air by not implementing TRIM?

https://www.reddit.com/r/openbsd/comments/qlva1s/openbsd_trim_support/

https://www.reddit.com/r/openbsd/comments/9h231o/will_there_be_trim_support_any_time_soon_if_not/e6bw9ig/

[intelfx]

So, sadly, in this case both of you are partially correct:

Radtraveller is correct that there are drives out there with active garbage collection. Drives originally implemented this ~15 years ago before TRIM and UNMAP were standardized. They do it by scanning the volume in that background, looking for things like free volume bitmaps, and trimming out blocks based on parsing those. One can imagine a slightly more clever version where the drive figures out the LBA's of data structure backing things like bitmaps and tracking updates in real time instead of background scanning, but I am not sure if anyone ever did it that way. Either way around it is strictly less efficient than having the OS tell the drives which blocks to collect, and can cause data loss if the OS ever revs the volume format or uses an access pattern that the drive does not expect:

So it exists, and it is terrible. There are a whole of other problems:

1. It only ever worked with specific filesystems: generally NTFS, HFS+, and the various FAT based filesystems. Maybe some supported of ext2/3/4
2. It completely depended on the filesystem being used in a normal access pattern. Various LVM operations (like an offline repartition) might break those assumption in ways that can lead to data loss if the drive GCes while it is happening.
3. It is completely incompatible with any sort of full disk encryption like BitLocker or FileVault. This is an inherent limitation of the design since to perform active garbage collection the drive needs to read the filesystem structures, but with encrypted filesystems they keys and decryption are handled by the OS and the drive never sees the encrypted blocks. Sit there and wait in your boot loader as long as you want, it won't figure out and blocks to GC.

In practice it is just sitting there dormant and unused on any modern drives these (or hopefully everyone removed it from their controller firmwares after TRIM became prevalent). There are a few reasons for that:

1. Many more people use encrypted filesystems
2. Even people who don't tend use newer OSes which may have newer filesystems (or versions of filesystems) the drives don't understand. Most of these firmwares have to be super paranoid about volume format changes. And since the whole thing was a legacy hack that means that any OS with a new enough volume format change will also be new enough to support TRIM, which means vendors have little incentive to keep revving and incredibly complex piece of code that performs worse).
3. Some of the drives that did support AGC used explicit TRIM commands as a single to disable it, and all modern OSes issue TRIMs.

Back when TRIM was being standardized I had a 50+ page argument on an SSD vendors website where I was asking about the status TRIM in their chipsets. A whole bunch of enthusiasts essentially thought TRIM was unnecessary, and kept asking. It was super depressing because several people who had worked on filesystems, HDD firmwares, and storage controllers chimed in and tried to explain how there was simply no way for the drive to know what blocks were to safe to GC for arbitrary FSes and their implementations, and that TRIM was a necessary interfaces to channel the info from the drive to the OS. Unfortunately we were drowned out. by people who essentially kept asking "But how do you *KNOW* they have not designed a magic algorithm that knows about every volume format and the access pattern of every implementation of those formats and can magically decrypt everything to do GC correctly?" Clearly I found it scarring since I felt motivated to create an account here to post this ;-)

Interesting, and thanks for correcting me. Well, I do not presume to know every horrible legacy hack in existence But it's definitely not relevant to "newer ssds" as claimed by the OP.

Anyway, I can't even begin to name all the things that can go wrong with a feature like this. And I sure as hell hope that my own SSD does not screw around with what it thinks to be free space on my partitions on its own!