9 ms·

FreeBSD – A Lesson in Poor Defaults

139 points by josephg 4y ago

suprjami 4y ago
I got as far as "HyperThreading is insecure so disable it". There are some absurd recommendations on here (disable TCP SACK, use TCP BBR) and the weirdest of all is why anyone who hates FreeBSD security this much would still use the OS?
- acoppora 4y ago
  Unfortunately Intel sold us all a very dangerous technology that we got used to. Hyperthreading has been disabled in more security-conscious OSes like OpenBSD and HardenedBSD. Greg KH praised OpenBSD for making this decision, even if he couldn't for Linux.
  - Sunspark 4y ago
    Ironically, imo for servers it would make sense to leave hyperthreading turned on because a server has full control over what is installed and what is running.
- mananaysiempre 4y ago
  I mean, Greg Kroah-Hartman of Linux agrees[1,2] as far as Spectre etc. go; more generally there seems to be almost no microarchitectural isolation between HT threads on x86 implementations, so the leaks probably won’t ever really cease there. The performance benefits of HT are also not at all universal. I mean, they do exist in some cases—if you’re running closely related scalar-compute- (or, better, dependency-) bound tasks that bang on the same small piece of memory, or if you run several things that are just bad at loading the CPU so HT-induced contention doesn’t matter. (The latter scenario was obviously much more important at the time HT was introduced, when neither people nor compilers were particularly good at optimizing for superscalars.) Or, though it’s not a performance benefit, it can help if you have few cores and the OS scheduler is bad at letting interactive tasks run in the presence of long-running batch ones or heavy swapping. But properly optimized multithreaded data crunching like video coding or compression doesn’t really run faster when given extra threads to run on HT “cores” rather than just leaving them disabled or idle. [1] https://www.youtube.com/watch?v=jI3YE3Jlgw8 https://www.youtube.com/watch?v=jI3YE3Jlgw8 [2] https://news.ycombinator.com/item?id=20865492 https://news.ycombinator.com/item?id=20865492
  - sph 4y ago
    Would it make sense to mitigations and hyperthreading on a workstation? Perhaps we're getting to a point that both disabled is faster than both enabled (and suffering from the mitigations penalties)
    - sillystuff 4y ago
      This is interesting. The mitigations have had a major impact. Especially with the recent loss of reptoline[1] on older AMD/Intel. Maybe enough that there isn't an advantage anymore to enable SMT on some processor families? At an old job, we disabled SMT on our hypervisor hosts in an effort to mitigate some of the security issues before patches were available. We had to roll back. Without SMT, the hosts struggled to keep up with load. If I had to quantify it, I'd estimate that we lost, at least, 30% performance by disabling SMT (probably more). Those servers were replaced before I left, but I'd be interested to compare disabled SMT to enabled SMT with all the current mitigations in place. [1] https://www.makeuseof.com/new-spectre-vulnerabilities-amd-intel-chips/ https://www.makeuseof.com/new-spectre-vulnerabilities-amd-in...
- rsync 4y ago
  I have been using fbsd almost exclusively, professionally, for 25 years - and built somewhat high profile projects (Johncompanies, rsync.net) on top of it and … there is plenty of hate in my love/hate relationship with it. It doesn’t seem odd to me at all that this individual would continue to use freebsd while maintaining such strongly held critiques of it.
  - suprjami 4y ago
    If I hated something that badly or had such security concerns about it, I'd drop it like a hot potato for a superior alternative. I just don't have time for that level of irritation or worry in my life.
    - nix23 4y ago
      Ahhh another OpenVMS user!! Hello buddy!!
bell-cot 4y ago
Submitted to HN ~10 times in the past 6 1/2 years. Some of the older submissions have a fair amount of discussion: https://news.ycombinator.com/from?site=mrsk.me https://news.ycombinator.com/from?site=mrsk.me
mnd999 4y ago
This reads like a rant from somebody with an axe to grind. Rightly or wrongly, I’m gonna ignore it for that reason.
- werid 4y ago
  That's because it is. Author is an OpenBSD fan/user, and have updated this article many times as the years pass. Maybe time for them to write an article on OpenBSD's pros directly instead of indirectly by attacking FreeBSD.
  - crest 4y ago
    Even as a FreeBSD "fan" I have to admit that there are some valid points in his rant e.g. the threaded AES-CTR did introduce a slightly larger attack surface to bugs hidden by OpenSSH opting to use only processes. I still preferred filling my multi-Gb/s pipes with backups for an hour or two every night instead of having replication take most of the day at ~300Mb/s. I need backups to be replicated nightly off-site before the start of business. The largest single backup job alone would have been too slow to finish in time after a busy day over unpatched SSH. I needed a tool that's fast enough to finish transfers in the available time window. Had FreeBSD shipped an unpatched SSH I would've had to implement most of its core features in something else instead of running a multi-threaded implementation of the same symmetric ciphers.
    - cma 4y ago
      Maybe the process method in place and added a --less-secure-turbo-threaded-mode option.
  - GekkePrutser 4y ago
    It sounds like they're also still using FreeBSD. I wonder why if they consider it so bad.
    - ctrlmeta 4y ago
      The most active users of a technology make the best critic too. Being an active user of something and being a critic of it are not mutually exclusive.
phoe-krk 4y ago
Is/are there any sort of FreeBSD distributions which change these defaults as a part of their distribution process?
- crest 4y ago
  The FreeBSD release building tools [1] support customisation. You can either patch the defaults in the code or include different default configuration files. Don't take this rant too seriously. [1]: https://www.freebsd.org/cgi/man.cgi?query=release&apropos=0&sektion=7&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=release&apropos=0&...
- GekkePrutser 4y ago
  No, FreeBSD is really only one distribution which is a big plus IMO. The GNU/Linux world is very fragmented because of this. Now, there are some spinoffs like DesktopBSD, GhostBSD and HelloSystem but they're very small compared to the situation with Linux where there are several major distros. But if your focus is security, OpenBSD would be a good alternative for sure.
  - kastagg 4y ago
    If everyone using Linux should use one distribution, which one should it be? Who gets to run it?
    - GekkePrutser 4y ago
      I'm not saying Linux should change. Just that this is a plus for FreeBSD for me.
    - deleted 4y ago
      [deleted]
- yjftsjthsd-h 4y ago
  HardenedBSD?
RedShift1 4y ago
> FreeBSD also re-enabled insecure encryption ciphers in their build after they were disabled upstream, with backward compatibility apparently being more important to them than the security of their users. You know what? I appreciate that. The security people want to break stuff all the time and it is terribly annoying to have to go and fix stuff. Sometimes you even can't, there is software out there that only supports older TLS ciphers and you have to keep an old browser around to access it. And inevitably that old browser is going stop working at some point too... If you are so anal about security, the knobs are there to make adjustments. For the rest of us, stop breaking shit!
- GekkePrutser 4y ago
  Indeed. And it's not like those ciphers are completely broken to the point of being easily exploitable. I have some old servers with older iLO that suffer from this, and I'm only using them on a local network. Similarly, I have used the "None" cipher on a local network to sync a lot of data from my old NAS which definitely did speed things up (that box didn't have AES-NI, ancient processor). They don't have to enable it out of the box but having it in there when needed is definitely helpful. On another point, that 'huge diverging patch' from OpenBSD PF was all about multithreading and dramatically improving performance on modern systems, it's not like it was done for the sake of it... But it should have been kept more up to date, yes.
- crest 4y ago
  IIRC FreeBSD changed the default value to keep the old crypto enabled by default in a minor release after they imported a newer OpenSSH version. They imported the new OpenSSH release because the old one was uncomfortable close to end of life to include in a new release and they changed the default cipher selection to a less secure one to maintain compatibility within a major release. If minor releases locked people out in the name of "you shouldn't be using this anyway" fewer people would install them in production. You would end up with more end of life systems in production, because nobody dared to touch them. Oh and if you do it often enough most users will migrate to a saner platform.
  - rovr138 4y ago
alberth 4y ago
From a HN thread 6-years ago where @cperciva wrote: > Some things fall into the category of "we can't change this overnight because we have users, but it will be changing in the future". I get and appreciate what’s said above. But, 6-years also seems like a long time for FreeBSD to not address some of these things. https://news.ycombinator.com/item?id=11318788 https://news.ycombinator.com/item?id=11318788
- Joker_vD 4y ago
  Well, you see, there are still some users even 6 years later that are using FreeBSD, so they can't change it yet. Maybe in another 6 years nobody will use it so they finally will be able to change it? Only time can tell!
- emaste 4y ago
  The linked blog post gives the impression that little has changed, but it is very much not the case. Taking a look at the first section, "OpenSSH Modifications" - rather little of it is current. With respect to ciphers disabled by default in upstream we may follow along in main but leave them enabled in a stable/release branch, in an attempt to avoid breaking existing users while deprecating increasingly insecure options over time. We do indeed add support for tcp_wrappers back in. With respect to the base system I think the rest of the section is not applicable.
  - acoppora 4y ago
    Why is tcp wrappers still there? The overlying theme of the SSH section is about going against upstream in the name of backwards compatibility, which it sounds like FreeBSD still does (albeit to a smaller degree).
    - emaste 4y ago
      tcp_wrappers is still there because it provides functionality not otherwise available that is still used, and has a relatively small impact on the attack surface.
ninefathom 4y ago
For many years, I was a devoted FreeBSD user. The lack of basic security hardening found on FreeBSD as compared to other systems vexed me somewhat. When the HardenedBSD project got going, I was thrilled. "Ah-ha!" I thought. "Now I can keep using my favorite OS without feeling like security is taking a back seat." Then I found a bug (in the base FreeBSD, not Hardened-specific) that had prevented ipfw from being used on big-endian systems for several years. Years, mind you- ipfw went for years without working on big-endian systems and nobody had noticed. That was too much, and I ran for the hills. Now, on OpenBSD, I very much miss ZFS... but that's a small price to pay in my book.
- pdimitar 4y ago
  Wait what? Only FreeBSD gives you ZFS on your boot/OS drive? What about OpenBSD / NetBSD / DragonflyBSD etc.? EDIT: I love it that I get downvoted for asking a question. Seriously people, get a grip.
  - 1500100900 4y ago
    Have you tried auditing ZFS? That's way too much code to be secure, it's best for OpenBSD to never import it.
    - mrweasel 4y ago
      I figured OpenBSDs argument against ZFS was the licens. It makes sense that they would want to audit the code before importing it into base, and it can’t be a kernel module, given that OpenBSD yanked that feature years ago.
  - nix23 4y ago
    Just NetBSD, FreeBSD and HardenedBSD. But DragonflyBSD has Hammer2.
    - philkrylov 4y ago
      NetBSD has a root-on-ZFS recipe only for amd64.
alberth 4y ago
I wonder how Dragonfly BSD defaults compare. https://www.dragonflybsd.org/history/ https://www.dragonflybsd.org/history/
- snvzz 4y ago
  Very favorably. Dragonfly has superior architecture, performance and security, despite its much smaller team. It is a textbook example of how a small team of focused competent engineers will deliver higher quality than an heterogeneous large body of developers with no focus. They are actually scaling in a manner competitive with Linux, unlike the other BSDs. When Matt left Freebsd, which was due to a conflict that spawned over bad technical decisions, many good developers followed him. What was left did implicitly support bad decisions. Fine-grained locks for SMP do explode complexity and makes writing quality code that much harder. It is also a problem in Linux, which compensates with sheer manpower. Freebsd has been a cesspool since then. Jesus, what a mess Freebsd has become.
  - acoppora 4y ago
    Can you confirm that Dragonfly has all of the CPU vulnerability mitigations that Linux has, including Retbleed, Spectre V1, and Spectre-BHB? FreeBSD does not have those three. It would also be good to read about Dragonfly's exploit mitigations. Are these documented somewhere?
    - snvzz 4y ago
      The wikipedia article has a history[0] of releases. Meltdown and Spectre mitigation support are mentioned in 5.2. I know there have been new CPU vulnerabilities found past these, but I haven't been keeping track closely. It would help if they had an announce mailing list. Looking at older release notes seems to be a manner of digging through the users list, or guessing URLs based on the current release notes. They seem in dire need of a maintainer for the website. 0. https://en.wikipedia.org/wiki/DragonFly_BSD#Release_history https://en.wikipedia.org/wiki/DragonFly_BSD#Release_history
jaas 4y ago
There is a list of NTP vulnerabilities in this article. If you're interested in a more secure NTP client we've been building one: https://github.com/memorysafety/ntpd-rs https://github.com/memorysafety/ntpd-rs Server functionality and NTS support is on the way.
- emaste 4y ago
  Very interesting, but it looks like you're only targeting the Linux kernel right now?
- 0x457 4y ago
  Do you have intention to support PTP?
yakubin 4y ago
Many of the claims on this page are supported with links to commits, mailing lists posts, etc. However then there is this claim, which lacks any link supporting it: > FreeBSD's malloc (jemalloc) is very forgiving of buggy/hostile code compared to something like otto malloc. Sounds vague. I'm not disputing it, as I haven't read the code of the two mallocs. But I would be curious about the details. Does anybody know what that's about? I was under the impression that jemalloc was seen as quite robust, not least thanks to doing away with free-lists (which is also true for otto malloc, as far as I can tell from cursory research).
- emaste 4y ago
  > Many of the claims on this page are supported with links to commits, mailing lists posts, etc Their links to commits, mailing list posts, etc., are cherry-picked and taken out of context to present their view. For one example, they suggest that the FreeBSD community is unwilling to make changes to improve things, and say "some of their users like it that way though", linking to https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/019997.html https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01.... If you actually read the thread that response is taken from (starting at https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/019994.html https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01...) you'll see a wholly different picture: a FreeBSD developer proposed a change, there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made. The FreeBSD src git repo has hundreds of thousands of commits, and anyone can post to mailing lists, so of course it's possible to find examples of mistakes being made, or misguided posts from developers or users. I very much welcome constructive criticism and ideas for improving the security landscape within FreeBSD.
  - acoppora 4y ago
    > there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made. Help me understand here. The reply by Julian is a huge overreaction. The text you quote seems to be condemning him (a user, not the developer) for fighting a seemingly worthwhile change on the principle of it being the way it was for a long time. So doesn't that kind of prove the point that you're saying isn't true?

139 points by josephg 4y ago

I got as far as "HyperThreading is insecure so disable it". There are some absurd recommendations on here (disable TCP SACK, use TCP BBR) and the weirdest of all is why anyone who hates FreeBSD security this much would still use the OS?

acoppora 4y ago
Unfortunately Intel sold us all a very dangerous technology that we got used to. Hyperthreading has been disabled in more security-conscious OSes like OpenBSD and HardenedBSD. Greg KH praised OpenBSD for making this decision, even if he couldn't for Linux.
- Sunspark 4y ago
  Ironically, imo for servers it would make sense to leave hyperthreading turned on because a server has full control over what is installed and what is running.
mananaysiempre 4y ago
I mean, Greg Kroah-Hartman of Linux agrees[1,2] as far as Spectre etc. go; more generally there seems to be almost no microarchitectural isolation between HT threads on x86 implementations, so the leaks probably won’t ever really cease there. The performance benefits of HT are also not at all universal. I mean, they do exist in some cases—if you’re running closely related scalar-compute- (or, better, dependency-) bound tasks that bang on the same small piece of memory, or if you run several things that are just bad at loading the CPU so HT-induced contention doesn’t matter. (The latter scenario was obviously much more important at the time HT was introduced, when neither people nor compilers were particularly good at optimizing for superscalars.) Or, though it’s not a performance benefit, it can help if you have few cores and the OS scheduler is bad at letting interactive tasks run in the presence of long-running batch ones or heavy swapping. But properly optimized multithreaded data crunching like video coding or compression doesn’t really run faster when given extra threads to run on HT “cores” rather than just leaving them disabled or idle. [1] https://www.youtube.com/watch?v=jI3YE3Jlgw8 https://www.youtube.com/watch?v=jI3YE3Jlgw8 [2] https://news.ycombinator.com/item?id=20865492 https://news.ycombinator.com/item?id=20865492
- sph 4y ago
  Would it make sense to mitigations and hyperthreading on a workstation? Perhaps we're getting to a point that both disabled is faster than both enabled (and suffering from the mitigations penalties)
  - sillystuff 4y ago
    This is interesting. The mitigations have had a major impact. Especially with the recent loss of reptoline[1] on older AMD/Intel. Maybe enough that there isn't an advantage anymore to enable SMT on some processor families? At an old job, we disabled SMT on our hypervisor hosts in an effort to mitigate some of the security issues before patches were available. We had to roll back. Without SMT, the hosts struggled to keep up with load. If I had to quantify it, I'd estimate that we lost, at least, 30% performance by disabling SMT (probably more). Those servers were replaced before I left, but I'd be interested to compare disabled SMT to enabled SMT with all the current mitigations in place. [1] https://www.makeuseof.com/new-spectre-vulnerabilities-amd-intel-chips/ https://www.makeuseof.com/new-spectre-vulnerabilities-amd-in...
rsync 4y ago
I have been using fbsd almost exclusively, professionally, for 25 years - and built somewhat high profile projects (Johncompanies, rsync.net) on top of it and … there is plenty of hate in my love/hate relationship with it. It doesn’t seem odd to me at all that this individual would continue to use freebsd while maintaining such strongly held critiques of it.
- suprjami 4y ago
  If I hated something that badly or had such security concerns about it, I'd drop it like a hot potato for a superior alternative. I just don't have time for that level of irritation or worry in my life.
  - nix23 4y ago
    Ahhh another OpenVMS user!! Hello buddy!!

bell-cot 4y ago

Submitted to HN ~10 times in the past 6 1/2 years. Some of the older submissions have a fair amount of discussion: https://news.ycombinator.com/from?site=mrsk.me https://news.ycombinator.com/from?site=mrsk.me

mnd999 4y ago

This reads like a rant from somebody with an axe to grind. Rightly or wrongly, I’m gonna ignore it for that reason.

werid 4y ago
That's because it is. Author is an OpenBSD fan/user, and have updated this article many times as the years pass. Maybe time for them to write an article on OpenBSD's pros directly instead of indirectly by attacking FreeBSD.
- crest 4y ago
  Even as a FreeBSD "fan" I have to admit that there are some valid points in his rant e.g. the threaded AES-CTR did introduce a slightly larger attack surface to bugs hidden by OpenSSH opting to use only processes. I still preferred filling my multi-Gb/s pipes with backups for an hour or two every night instead of having replication take most of the day at ~300Mb/s. I need backups to be replicated nightly off-site before the start of business. The largest single backup job alone would have been too slow to finish in time after a busy day over unpatched SSH. I needed a tool that's fast enough to finish transfers in the available time window. Had FreeBSD shipped an unpatched SSH I would've had to implement most of its core features in something else instead of running a multi-threaded implementation of the same symmetric ciphers.
  - cma 4y ago
    Maybe the process method in place and added a --less-secure-turbo-threaded-mode option.
- GekkePrutser 4y ago
  It sounds like they're also still using FreeBSD. I wonder why if they consider it so bad.
  - ctrlmeta 4y ago
    The most active users of a technology make the best critic too. Being an active user of something and being a critic of it are not mutually exclusive.

phoe-krk 4y ago

Is/are there any sort of FreeBSD distributions which change these defaults as a part of their distribution process?

crest 4y ago
The FreeBSD release building tools [1] support customisation. You can either patch the defaults in the code or include different default configuration files. Don't take this rant too seriously. [1]: https://www.freebsd.org/cgi/man.cgi?query=release&apropos=0&sektion=7&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html https://www.freebsd.org/cgi/man.cgi?query=release&apropos=0&...
GekkePrutser 4y ago
No, FreeBSD is really only one distribution which is a big plus IMO. The GNU/Linux world is very fragmented because of this. Now, there are some spinoffs like DesktopBSD, GhostBSD and HelloSystem but they're very small compared to the situation with Linux where there are several major distros. But if your focus is security, OpenBSD would be a good alternative for sure.
- kastagg 4y ago
  If everyone using Linux should use one distribution, which one should it be? Who gets to run it?
  - GekkePrutser 4y ago
    I'm not saying Linux should change. Just that this is a plus for FreeBSD for me.
  - deleted 4y ago
    [deleted]
yjftsjthsd-h 4y ago
HardenedBSD?

RedShift1 4y ago

> FreeBSD also re-enabled insecure encryption ciphers in their build after they were disabled upstream, with backward compatibility apparently being more important to them than the security of their users. You know what? I appreciate that. The security people want to break stuff all the time and it is terribly annoying to have to go and fix stuff. Sometimes you even can't, there is software out there that only supports older TLS ciphers and you have to keep an old browser around to access it. And inevitably that old browser is going stop working at some point too... If you are so anal about security, the knobs are there to make adjustments. For the rest of us, stop breaking shit!

GekkePrutser 4y ago
Indeed. And it's not like those ciphers are completely broken to the point of being easily exploitable. I have some old servers with older iLO that suffer from this, and I'm only using them on a local network. Similarly, I have used the "None" cipher on a local network to sync a lot of data from my old NAS which definitely did speed things up (that box didn't have AES-NI, ancient processor). They don't have to enable it out of the box but having it in there when needed is definitely helpful. On another point, that 'huge diverging patch' from OpenBSD PF was all about multithreading and dramatically improving performance on modern systems, it's not like it was done for the sake of it... But it should have been kept more up to date, yes.
crest 4y ago
IIRC FreeBSD changed the default value to keep the old crypto enabled by default in a minor release after they imported a newer OpenSSH version. They imported the new OpenSSH release because the old one was uncomfortable close to end of life to include in a new release and they changed the default cipher selection to a less secure one to maintain compatibility within a major release. If minor releases locked people out in the name of "you shouldn't be using this anyway" fewer people would install them in production. You would end up with more end of life systems in production, because nobody dared to touch them. Oh and if you do it often enough most users will migrate to a saner platform.
- rovr138 4y ago

alberth 4y ago

From a HN thread 6-years ago where @cperciva wrote: > Some things fall into the category of "we can't change this overnight because we have users, but it will be changing in the future". I get and appreciate what’s said above. But, 6-years also seems like a long time for FreeBSD to not address some of these things. https://news.ycombinator.com/item?id=11318788 https://news.ycombinator.com/item?id=11318788

Joker_vD 4y ago
Well, you see, there are still some users even 6 years later that are using FreeBSD, so they can't change it yet. Maybe in another 6 years nobody will use it so they finally will be able to change it? Only time can tell!
emaste 4y ago
The linked blog post gives the impression that little has changed, but it is very much not the case. Taking a look at the first section, "OpenSSH Modifications" - rather little of it is current. With respect to ciphers disabled by default in upstream we may follow along in main but leave them enabled in a stable/release branch, in an attempt to avoid breaking existing users while deprecating increasingly insecure options over time. We do indeed add support for tcp_wrappers back in. With respect to the base system I think the rest of the section is not applicable.
- acoppora 4y ago
  Why is tcp wrappers still there? The overlying theme of the SSH section is about going against upstream in the name of backwards compatibility, which it sounds like FreeBSD still does (albeit to a smaller degree).
  - emaste 4y ago
    tcp_wrappers is still there because it provides functionality not otherwise available that is still used, and has a relatively small impact on the attack surface.

ninefathom 4y ago

For many years, I was a devoted FreeBSD user. The lack of basic security hardening found on FreeBSD as compared to other systems vexed me somewhat. When the HardenedBSD project got going, I was thrilled. "Ah-ha!" I thought. "Now I can keep using my favorite OS without feeling like security is taking a back seat." Then I found a bug (in the base FreeBSD, not Hardened-specific) that had prevented ipfw from being used on big-endian systems for several years. Years, mind you- ipfw went for years without working on big-endian systems and nobody had noticed. That was too much, and I ran for the hills. Now, on OpenBSD, I very much miss ZFS... but that's a small price to pay in my book.

pdimitar 4y ago
Wait what? Only FreeBSD gives you ZFS on your boot/OS drive? What about OpenBSD / NetBSD / DragonflyBSD etc.? EDIT: I love it that I get downvoted for asking a question. Seriously people, get a grip.
- 1500100900 4y ago
  Have you tried auditing ZFS? That's way too much code to be secure, it's best for OpenBSD to never import it.
  - mrweasel 4y ago
    I figured OpenBSDs argument against ZFS was the licens. It makes sense that they would want to audit the code before importing it into base, and it can’t be a kernel module, given that OpenBSD yanked that feature years ago.
- nix23 4y ago
  Just NetBSD, FreeBSD and HardenedBSD. But DragonflyBSD has Hammer2.
  - philkrylov 4y ago
    NetBSD has a root-on-ZFS recipe only for amd64.

alberth 4y ago

I wonder how Dragonfly BSD defaults compare. https://www.dragonflybsd.org/history/ https://www.dragonflybsd.org/history/

snvzz 4y ago
Very favorably. Dragonfly has superior architecture, performance and security, despite its much smaller team. It is a textbook example of how a small team of focused competent engineers will deliver higher quality than an heterogeneous large body of developers with no focus. They are actually scaling in a manner competitive with Linux, unlike the other BSDs. When Matt left Freebsd, which was due to a conflict that spawned over bad technical decisions, many good developers followed him. What was left did implicitly support bad decisions. Fine-grained locks for SMP do explode complexity and makes writing quality code that much harder. It is also a problem in Linux, which compensates with sheer manpower. Freebsd has been a cesspool since then. Jesus, what a mess Freebsd has become.
- acoppora 4y ago
  Can you confirm that Dragonfly has all of the CPU vulnerability mitigations that Linux has, including Retbleed, Spectre V1, and Spectre-BHB? FreeBSD does not have those three. It would also be good to read about Dragonfly's exploit mitigations. Are these documented somewhere?
  - snvzz 4y ago
    The wikipedia article has a history[0] of releases. Meltdown and Spectre mitigation support are mentioned in 5.2. I know there have been new CPU vulnerabilities found past these, but I haven't been keeping track closely. It would help if they had an announce mailing list. Looking at older release notes seems to be a manner of digging through the users list, or guessing URLs based on the current release notes. They seem in dire need of a maintainer for the website. 0. https://en.wikipedia.org/wiki/DragonFly_BSD#Release_history https://en.wikipedia.org/wiki/DragonFly_BSD#Release_history

jaas 4y ago

There is a list of NTP vulnerabilities in this article. If you're interested in a more secure NTP client we've been building one: https://github.com/memorysafety/ntpd-rs https://github.com/memorysafety/ntpd-rs Server functionality and NTS support is on the way.

emaste 4y ago
Very interesting, but it looks like you're only targeting the Linux kernel right now?
0x457 4y ago
Do you have intention to support PTP?

yakubin 4y ago

Many of the claims on this page are supported with links to commits, mailing lists posts, etc. However then there is this claim, which lacks any link supporting it: > FreeBSD's malloc (jemalloc) is very forgiving of buggy/hostile code compared to something like otto malloc. Sounds vague. I'm not disputing it, as I haven't read the code of the two mallocs. But I would be curious about the details. Does anybody know what that's about? I was under the impression that jemalloc was seen as quite robust, not least thanks to doing away with free-lists (which is also true for otto malloc, as far as I can tell from cursory research).

emaste 4y ago
> Many of the claims on this page are supported with links to commits, mailing lists posts, etc Their links to commits, mailing list posts, etc., are cherry-picked and taken out of context to present their view. For one example, they suggest that the FreeBSD community is unwilling to make changes to improve things, and say "some of their users like it that way though", linking to https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/019997.html https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01.... If you actually read the thread that response is taken from (starting at https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/019994.html https://lists.freebsd.org/pipermail/freebsd-arch/2020-May/01...) you'll see a wholly different picture: a FreeBSD developer proposed a change, there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made. The FreeBSD src git repo has hundreds of thousands of commits, and anyone can post to mailing lists, so of course it's possible to find examples of mistakes being made, or misguided posts from developers or users. I very much welcome constructive criticism and ideas for improving the security landscape within FreeBSD.
- acoppora 4y ago
  > there was general agreement with a small amount of opposition including the cherry-picked message, and the change was made. Help me understand here. The reply by Julian is a huge overreaction. The text you quote seems to be condemning him (a user, not the developer) for fighting a seemingly worthwhile change on the principle of it being the way it was for a long time. So doesn't that kind of prove the point that you're saying isn't true?