FreeBSD Q2 2016 Status Report
freebsd.org
freebsd.org
I wish more of the HardenedBSD features would land in FreeBSD trunk. Other than that, I'm really glad to see that it's making great progress, like RISC-V support. The address randomization feature in 11 is ASR (not ASLR), per the review comments by the inventor of ASLR (PaX dev), so it's a pity the initial HardenedBSD devs decided to not continue upstreaming things after they felt the ASLR patch review was taking too long. OPNsense seems to be basing itself on HardenedBSD, so that's nice to see.
However, its worth noting, that if it wasnt for them persistently making a lot of 'noise' around this particular feature, FreeBSD guys wouldnt come up with their own implementation anytime soon.
[0] https://www.openbsd.org/papers/bsdcan08-sensors.pdf
[1] I attended the BSDCan this was presented at, and sat close to phk and witnessed the exchanges about the technical merits, problems, "'good enough' vs 'good'", but am recalling from memory.
[2] Poul-Henning Kamp, https://twitter.com/bsdphk
Do you know if there are there plans to implement the rest of the important mitigation techniques?
That is because ASLR, by itself, is almost totally worthless, and is meant as a stop-gap to stop certain direct code attacks (vs "data only" attacks). It is a stop-gap because most modern systems are completely riddled with things like infoleaks, and you only need to leak one pointer to actually defeat the setup completely.
The real vector that's sitting around to be killed is control-flow based exploits (e.g. ROP, simple stack smashing, vtable ptr overwrites, all those de jour exploit techniques). You need a powerful form of control-flow integrity to stop this at the software level. You also need a method to actually help mitigate information leaks so they can do less damage, and increase attacker cost (e.g. "execute only pages" are worthless if all users have the same kernel image. I can just download your GENERIC kernel elf image, and just find the opcodes to do e.g. a ROP attack anyway. grsecurity uses compiler plugins that randomize kernel stacks and the compilation method with a particular private seed, at compile-time, so every compiled grsecurity kernel is different from the last one).
TBQH: FreeBSD is probably better off copying the other twenty gazillion exploit mitigation features from grsecurity that can reasonably stop exploits, even by themselves, dead in their tracks - like UDEREF, KERNEXEC, refcount overflows, triggering the kernel on unmarked signed overflow, the compiler plugin features, etc. Those will actually ban classes of exploits outright, every time, and always work, without wasting time through lots of wincing over the finer details, like ASLR.
You won't get to parade "look at our weak ASLR implementation!" (thankfully), but I feel we already have enough of that going around.
>"and get management to make a donation in kind"
Unlike FreeBSD and pretty much every other serious donation-supported project (including NetBSD) the OpenBSD Foundation is not a [strike]legal non-profit[/strike] "tax deductible charity" (in the US that'd commonly be a 501(c) tax empty). So donations are not tax deductible and may run into barriers that others sail through. Many of the matching programs I've seen for example simply have official non-profit status as a flat-out requirement. While of course it might be possible to negotiate exceptions with management, just in having the conversation at all we're already talking massively more friction, and friction is the enemy of spending.
OpenBSD has some little bit of handwaving about it (Canadian, too much trouble) which may well be valid in isolation but is irrelevant in the larger picture, and feels more like a common pattern of prideful disdain at being about "anything but the code". But to the extent money from non-coders is considered important, the interests of non-coders also have to be at least mildly considered if an increased response rate is desired. It's the 100% right of OpenBSD to make it a PITA and have snark and proudly run rough sites and such, but of course that's going to have natural consequences in interactions with the rest of the world.
There's no right or wrong answer here, but I don't think your "it's pretty sad and says a lot about the IT industry that they are not" actually fully captures the situation. Other foundations are registered non-profits, have somewhat nicer pages (not crazy webapp monstrosities, but even little things like simple acknowledgment of smaller donors that OpenBSD blows off), and so on. Donors are special and rare, and a bit of personal recognition and appreciation is free and can go a long way. A lot of coders may dislike the softer general human networking side of things, but tossing it aside will generally result in a reduced experience unless there is some other form of stickiness.
Yes, it is true The OpenBSD Foundation is not a US 501(c)3 (side note: that is not the only type of US non-profit). That is because instead it is a _Canadian Not-For-Profit-Corporation_, which is a legal non-profit for Canada.
Please, do NOT spread FUD that The OpenBSD Foundation is not a non-profit. It absolutely is.
Proof: Canada Federal Corporation Information https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDt... The OpenBSD Foundation Bylaws: http://www.openbsdfoundation.org/foundation/bylaws.html
This is absolutely true; however, the OpenBSD Foundation is not a charitable organization (and donations don't get any special income tax treatment) -- because Canada is far more restrictive in our definition of "charity". The FreeBSD Foundation wouldn't have any special tax status if it was set up in Canada either.
I have added an edit and tried to reword that bit slightly, I hope that you find it a little better. It was an honest terminology flub I guess, when I used "legal non-profit" I was aiming for the more colloquial sense it's often used in America when discussing "donations", which is the subtopic at hand here, wherein it tends to be taken for granted that the entity provides receipts for tax deduction. However, I can see how it'd be confusing and could be taken the wrong way, or feel like a slur. FUD was the very farthest thing from my mind.
I stand by the thrust of the post however. The quality of code produced and its foundational status for much of the development world is not in question, but I don't think the (often celebrated) "roughness" of Theo et al in small ways is either (again, mostly in small ways like not listing anything but huge donors or that Comic Sans initial LibreSSL site [1]). This is not a value judgement; I think there are good arguments for both sides about the pros and cons of "public friendliness" and the resources that takes up vs the return for any given project. But it's not fair to pretend that abrasiveness is or should be cost free either. When you launch a project like LibreSSL in the midst of a relatively huge (and as always temporary) amount of temporary news coverage over the subject and the first general impression of the project to the general public is [1]
>"This page scientifically designed to annoy web hipsters," the site says. "Donate now to stop the Comic Sans and Blink Tags."
well, that may or may not result in a lot of people "donating now" right? Like it or not webs of trust, proxies, and authorities are the methods people have to use to evaluate most of the information input they deal with in life, at least as a first pass filter.
I want OpenBSD to make as much money as they need, but I don't think they're immune to basic forces of competition that everyone else faces either. I'm honestly not sure if they're actually even facing any money issues they care about beyond a basic "more is certainly helpful and would allow for more hardware testing and the like". There are other models beyond soliciting individual small donations, and I see significant corp ones (and pressuring other large companies to toss in $10-50k a year might be effective, why isn't Apple in Gold/Platinum?). But in the restricted context of the post I was replying too arguing that the lack of tons more coming in from smaller distributed sources, small businesses and so on, and then slamming all involved, well I don't think that's entirely fair. OpenBSD could do better there, if they need/want to. And I've repeated that because if they're happy with how things are now then there is certainly no need for them to change. Not everything is about getting as much as possible, if they're satisfied with what they have as "enough" then good for them.
[1]: https://arstechnica.com/information-technology/2014/04/opens...
I've also had the FreeBSD Foundation as my Amazon Smile beneficiary ever since Smile was introduced. It's not a huge amount (0.5%), but I shop a lot on Amazon.
Money well spent.
I'm not talking about Linus. Linus swears, I think that's almost OK. No, I'm talking about the people who go out of their way to be unpleasant. Some of them swear too, but saying fuck isn't the heart of what makes them bad. And I wish Linus wouldn't swear — he attracts too much criticism and shields people who could use a little headwind.
I'm going to donate to freebsd just for that.
Look at ports/sysutils/u-boot-cubieboard2 for a template on how to build a suitable U-Boot, and sys/boot/fdt/dts/arm/cubieboard2.dts for a template for your dtb.
For a detailed list of supported hardware, have a look at the wiki: https://wiki.freebsd.org/FreeBSD/arm/Allwinner
Also, the sddm package didn't build because the kdemerge tool can't merge the UIDs/GIDs files. That was changed to go ahead and build the package and give a pkg-message to create the user.
I want people to be able to test using 11.0-BETA2 and have sddm, so I've updated the jail and am currently in the process of rebuilding the packages.
Because the jail changed, everything builds from scratch, so it's taking a little while, but when they're done building (should be soon), I'll test some more and write up some docs on testing KDE5 and post them for those who are interested.
> Intel GPUs up to and including the unreleased Kaby Lake are supported
> Amdgpu AMD/ATI driver has been updated to GCN 1.1 and higher
Maybe at some point one of the BSDs will implement a new, cleaner init system.
Could you eloborate where you had problems? The BSD init system is already quite clean, much cleaner than sysvinit.
I'm not sure what systemd features you need but most if not all can be replaced by small unix tools - that's kind of the point of the BSD philosophy.
(I know these topics can get quite heated, but I'm genuinely not looking to start a flame war).
While systemd clearly helped consolidate and make administration more predictable across linux distros, there are deficiencies and regressions due to systemd which for the most part didn't exist in the pre-systemd era. It may be due to the scope of functionality systemd aims to cover, but some of the unconventional or missing command line options don't help either. However, it's used by enough mainstream distros that I expect the kinks to be fixed with time.
I was more interested in why the OP didn't consider FreeBSD to have a "useful init system". Just wondered if it was a preference thing or if there were features s/he considered it to be missing or were perhaps unaware of.
I keep seeing this argument, and i keep wondering what it is actually trying to say.
Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working.
But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.
Then again, maybe i am not the laptop packing dev convention goer that seems to use their laptop more like an oversized phone than a laptop (never mind a desktop).
Edit: damn keyboard ignored the copy command somehow, so i had the wrong quote pasted...
Funny enough, FreeBSD is handling runtime hardware changes neither in its init process or rc scripts. Instead the FreeBSD kernel has a single-reader device event channel, which is read by devd. The submitted events range from ACPI laptop lid close/open, to added usb things or ZFS errors. They are matched against configurable rulesets and their respective actions executed. Loading kernel modules, starting daemons etc. Devd also multiplexes the received events to arbitrary numbers of additional consumers via a number of available sockets in /var/run.
There's a new version of nosh ready on the new WWW site. I'll be announcing in the usual places soon. I believe that it has a few things of interest to people, including (given what was said above) a slight further extension on the cross-platform front.
URL: https://jdebp.eu/Softwares/nosh/
> It has moved. There's an article on the new WWW site about what happened.
Can't find the article though.
That's not the nosh 1.28 announcement, by the way. I have yet to do that.
> That's not the nosh 1.28 announcement, by the way. I have yet to do that.
Okay, will that include the "article on the new WWW site about what happened"?
As I said, it's on the new WWW site, and you can read it there.
For want of a better place, I put it on the new WWW site in the "author" section. For now. The change of WWW site motivated me to do some restructuring of things that I laid out decades ago and tidy up stuff that was only there for some old URLs that were floating around (that don't point to the new WWW site of course, making the fixes for them irrelevant). I still haven't settled on the layout of the "author" section, and it might change. Any URL valid now might not be valid in months and years to come when this comment is still visible to the world. And I have just been tidying up the long-term consequences of stale URLs on discussion fora from years ago.
So just follow an author hyperlink, from pretty much any page, to the (current) author section and proceed from there.
BSD init is pretty small and clean. I would argue systemd is much less so because of the large scope of the project. The more lines of code and features you have means there's going to be more bugs and more ugliness, and that's true for all large programs. New doesn't mean better either. If it isn't broken and still works well, then you don't need a replacement, which really is why systemd exists to begin with. Sysvinit was a god awful and byzantine program IMO.