Personally I've never heard of something similar in FreeBSD.Kees Cook said:"I hear a lot of blame-shifting of where this problem needs to be solved," he told the audience. "Even if upstream says 'oh sure we found that bug, we fixed it,' what kernel version was it fixed in? Did it end up in a stable release?"
Yeah, I agree about the implementation of proactively defensive technologies and all the problems caused by third parts softwares, but what hit me was this Cook's consideration:
Personally I've never heard of something similar in FreeBSD.
We are in an happy (unhappy?) situation where almost none of the major vendors have a real interest in supporting FreeBSD directly in form of their own drivers. Intel is the major exception and is of course an example how it should be done, we have many competent developers working on the Intel drivers with direct support from Intel's engineers. We still have another problem with some of the kernel drivers. For example, the bluetooth support in FreeBSD was done by a single person (as I understand it) and it's quite honestly a disaster, nobody seems to want to touch the code because it's so broken. We also have problems with testing device drivers, just look at how long it has taken to produce the DRM/KMS drivers only because the devs working on it have had access only to a small percentage of the huge variety of the hardware targeted by the drivers.
Looking at the big picture we shouldn't treat our favorite OS with silk gloves, it's still a result of the exact same thinking and design that produced all of UNIX and UNIX-like operating systems including Linux. The design is still a monolithic kernel with nothing separating device drivers from the main kernel code at runtime, a single mistake in any of the device drive code can potentially take down the whole system and that's not something I would call a feature of a modern operating system. Don't get me started on the security implications of this design.