FreeBSD security design flaws

And there's HardenedBSD, which (as far as I know and if I understand correctly) configures security features FreeBSD has activated as much as possible (minus anything depending on running hardware having specific feature or not that cannot make as defaults on releases) and adding some additional tools.

It's still (almost) FreeBSD (rebasing their repo with FreeBSD), but released as different downstream release as it should break backward compatibilities with previous releases of FreeBSD. And breaking backward compatibilities disallows FreeBSD project to switch to HardenedBSD's defaults.
 
I'm not fond how of HardenedBSD has splintered the community and potential resources for FreeBSD. They could've simply relegated to being a security patchkit for vanilla FreeBSD. (ie. grsecurity, Hardened Gentoo) With pkgbase, I see less reason for it.
 
rcbsdpge said:
So I have word back from one of the greybeards from the Reddit arm of the community. This is his advice and I will quote as originally advised:

“As someone whose been on the BSD community for decades, I’d advise you to take anything said by a greybeard with multiple grains of salt, when it comes to new developments. Most of them seem to be stuck in a time loop. In the past, there were greybeards who were also against these now common technologies:
Click to expand...

Uh, yeah?
And some greybeard somewhere on the internet told me:

'As someone whose part of BSD development since its dawn, I'd advice you to take anything said by a greenhorn with a lot of salt and caution, when it comes to development. Most of them seem to live in some fluffy pink candyfloss SciFi air castle, snatching unquestioned everything new there is just because it's new. Blindly trust and naive believe in all new things bring benefits only, just because they are new. Never experienced all things always also bring downsides. Nor people not telling the whole truth, often even lying ruthless. Never using new technologies for making the world a better place but abusing them greedy for just to make money only. Not seldom trying to sell the same old crappy junk over and over again for decades, only disguised as something new. And because the greenhorns do not seen it yet so far, they fall for it, believing it was something new, and so it must be done, because it's new, so better.
We greybeards already seen most of it and experienced all the shit it already caused, and the effort it took to clean up the mess afterwards again. We share our experience with the greenhorns not to repeat the same mistakes again and again. Not to fall blindly for anything presumptive new unquestioned and uncritically. For that we are named cavemen, preventing progress, stuck in the past or time loops, had no idea how the world works.

If all things were done only by greenhorn's ways, all we had today was a wild zoo of zillions fancy ideas, all started, none finished. An unreliable, unusable, not working chaos.
The kernel sources alone would consist of at least two dozens different languages. Impossible to maintain. Only new features were brought in. Bugs in old language's sources not fixed, because everybody refuses to learn those "ancient, obsolete" languages. Anything but reliably solid.
Documentation, if done at all, was only done on websites. Most of them 404 or obsolete, because nobody has access. No manpages delivered with the software, but everything depends on having always internet connection and servers randomly maintained by thirds.
If there were any BSD at all anymore, not drowned in a swamp of zillions of different forks. Single people left former teams mopey, because they fell their fancy ideas were not appreciated enough. So starting their own fork. But then stop somewhere on the way, when they realize it takes a lot more to bring a project to an usable, solid working state than just having fancy ideas. But alas their work power and competences are lost for the original project.'
 
Last edited:
What a pointless thread, because no OS is 100% safe by design on purpose. You always have to make tradeoffs for it to be usable and flexible enough.

If you really want to hear own researched meanings about it look at Ilja van Sprudel instead of Claude playing Captain Obvious.

@OP: Your "Get working!" is really disrespectful in a multitude of ways, because the consequence would be rewriting major parts of the OS. Alone using a LLM shows that you've got no clue what you are talking about.

Rewriting the kernel in Rust... hahaha NO!
 
CShell said:
But I don't remember if this idea actually went to production or not
Click to expand...
I never heard of that, but I highly doubt that such a chip was capable for the market.
I estimate the instruction set was extremely large and complex, so the chip became very large and expensive. And I wouldn't be surprised if it was a real juice sucker and very slow at the same time. And then it could run Java only, so being pretty incompatible to anything else?
I highly doubt such a thing would become a bestseller.
 
Maturin said:
I highly doubt such a thing would become a bestseller.
Click to expand...

Ah .. well Sun Microsystems was likely interested in licensing Java for hardware chip production :cool: . Imagine getting revenue (aka "paid") for each Java processor deployed to (each) customer.

At the time Windows/Intel (aka "WinTel") was making a lot of money in the market place and Sun was interested in getting Java-On-A-Chip to compete. They (were likely?) also thinking about "devices" at the time - aka Cell Phones, PADs, Tablets... but I do remember some discussion of having PC's run these chips as well.

Sun was already making SPARC chips (RISC) and so forth for their Sun manufactured Unix machines. (Link Wikipedia): Sun SPARC

You can read a little bit about this here: (Link Wikipedia): Java_processor
 
The greatest security factor is always human factor,although design of software also matters.To me the more centralized development model of FreeBSD (and other BSDs) is better at blocking supply chain attack,and allows better code quality.
 
CShell said:
Ah .. well Sun Microsystems was likely interested in licensing Java for hardware chip production :cool: . Imagine getting revenue (aka "paid") for each Java processor deployed to (each) customer.
Click to expand...
Everybody is always interested in everything, and thinks about it. 😎
That means nothing.
And of course you can make a lot of money with such a thing - if it sells. 🤓
CShell said:
Sun was already making SPARC chips (RISC) and so forth for their Sun manufactured Unix machines.
Click to expand...
Yeah, I'm fully aware of that.

Such are also always BA's decisions.
One MBA comes and says, 'we can make a lot more money, if we don't buy those parts, but produce them ourselves, because we don't need to pay other's revenue but keep it for ourselves.'
Then a couple of years later another MBA (sometimes even the same) say, 'We need to sell that branch of our business. We are saving more money and be more flexible when we do not produce those things ourselves but simply buy those parts on the market by competing companies.'
Then a couple of years later again it's, 'We better produce those things ourselves. Makes us more independent and gives us a bonus towards competitors. Also the collaboration between the different disciplines stay under the same roof...'
Then it needs to be sold again, 'we need to focus on our core business.'
etc, etc.

But RISC is quite the opposite of how I can imagine a processor executing an object oriented HOL directly.
Processor design always also is to find the right compromise for the size.
A more comprehendable instruction set means more complex things can be done with fewer lines of machine code, so less clock cycles and less memory.
In contrary a smaller instruction set means you need more machine commands to accomplish the same job, but it also means less circuits, less complex circuits, that keeps the die small. This means less size, less power consumption, less heat dissipation (mobile apps), less silicon needed, so less production cost. Plus fewer development effort. Plus commonly the chip can be clocked at higher frequencies, which in many cases comes at the end to more computation speed than saving code by using a more complex instruction set.

Those were my concerns. I never doubted such a thing was technically possible. I just doubt it could hit the market and become profitable.
 
You must log in or register to reply here.
Back
Top