FreeBSD RELEASE-10.0: the worst release of FreeBSD yet

Okay, so since FreeBSD 10.0 has been released, we decided to analyze what the FreeBSD project has done and report new features. All we found was a system that was more unusable then it’s earlier versions.

The hardware we used was a ThinkPad T510 with the following specs:

CPU: Intel® Core™ i7-620M, Dual-core, 2.66GHz

RAM: 8GB PC3-10666(1333Mhz)

Hard Drive: 250GB 5400rpm 2.5″ SATA HDD

Graphics Processor: Intel HD Graphics

Ethernet: Intel Gigabit Ethernet

Wireless: Intel Centrino Advanced-N 6200

Sound Card: Intel HD Audio

We first downloaded the DVD ISO image called “FreeBSD-10.0-RELEASE-amd64-dvd1.iso”, burned it to a DVD, boot from it and encountered the first big change with FreeBSD 10. The speed. It is much slower then previous versions. A quick skim through of dmesg reveals why:

############################################

FreeBSD 10.0-RELEASE #0 r260789: thu Jan 16 22.34.59 UTC 2014

root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610

############################################

Yes stock versions of FreeBSD are now compiled with CLANG not GCC. As of 2014, CLANG still produces vastly inferior binaries compared to GCC. These CLANG binaries have problems with speed, size and memory consumption. They are also notorious for memory leaks. Compiling FreeBSD with clang has made FreeBSD slower then before which shows just how much BSD developers are willing to sacrifice usability and performance for the sake of being more proprietary friendly.

With the kernel fully booted and the slow and obsolete BSD init finally activating all required services, we started the installation and ran into the next big change. Arrow keys do not work anymore. It is unknown whether this is the case with our hardware or a global problem but one thing we do know is that the arrows keys worked when we were assessing FreeBSD 9.1 on this same laptop. Luckily for us, the other keys were still functioning as they should and thus the installation was continued. During the installation, we chose to use the ZFS on root option which was not present in the 9.x installers. It was a decision that would be regret later as file operations of every type (even simple ones) would use huge quantities of RAM and CPU. The installation on the whole went smoothly but took much longer then previous versions.

Finally with the installation done, we now boot from the hard drive and encounter probably the biggest change to FreeBSD 10.0. Booting from the hard drive is now far slower then booting from the CD. The boot loader and kernel are both so slow with the kernel being the worst. The computer screen spent 2 minutes on the following line:

#################################

/boot/kernel/kernel text=0xed9008 data=…

#################################

So it now takes 2 minutes to boot just the FreeBSD kernel which makes you wonder what’s the blood alcohol level of the FreeBSD developers when they created this crap (By the way, it’s worth nothing that the majority of funding received by the FreeBSD project goes into buy beer for the developers). We also believe that this is a side effect of building the kernel and userland with clang.

With the OS fully booted, we can now take a look at some the so called “new” features. First and foremost intel wireless iwn0 device nodes now disappears after 5 minutes of booting so wireless is useless. And there’s still old, vulnerable and useless software like SendMail still included in the base system. PKGNG is still slow and terrible.

KMS on BSD: Failure of Epic Proportions

If you are expecting something pleasant when using KMS on FreeBSD, you can forget about it because all you get is misery. If you are using a graphics card in which supports KMS on FreeBSD (now Intel and AMD), versions of Xorg obtained from precompiled packages don’t work anymore. You now have to add the following to /etc/make.conf:

#######################################

WITH_NEW_XORG=yes

WITH_KMS=yes

#######################################

And then compile all of Xorg and Xorg’s dependencies from ports. To reduce the suffering of others, we recommend doing a:

# pkg install gcc48

And adding the following extra lines to /etc/make.conf:

#######################################
CC=gcc48
CXX=g++48
CPP=cpp48

#######################################

Using our machine, it took us nearly 20 hours to build Xorg. Once Xorg has been build, the troubles are only just beginning. When started, Xorg is far slower then it was without KMS. Wost still is that the virtual consoles are no longer functional when the KMS module is loaded and unloading the KMS resulted in the crash of the entire system. The system was so unbearable and unusable with Xorg that we had to disable it permanently.

This just shows us how much BSD developers are trying to force users away from FOSS respecting GPU manufacturers like Intel and AMD and instead make them use drivers from proprietary terrorists like NVidia.

BHyVe: Too Little too Late

Now for the feature that is so big in FreeBSD 10.0 because BSD lacked in that area for more then 10 years. Virtualization. In FreeBSD this now finally being done with the BSD Hypervisor. Stupidly called BhyVe or Bhyve. Bhyve is a type-2 hypervisor that tries to match Xen and KVM that was created for Linux near the begin of the 2000s. Our assessment of Bhyve shows that that is nothing new to it and has virtually no potential to be on par with KVM or Xen in Linux.

One of the worst problem with Bhyve is that you have to set it up BSD style (manual edit config files and reboot) which everyone knows is time consuming, tedious and prone to errors. We demonstrated this by doing an example.

First, search for documentation. Bhyve documentation is a mess not understandable. Next, you have to add the right configuration lines to both /etc/rc.conf and /boot/loader.conf.

/etc/rc.conf

##########################################

ifconfig_vnet0=”DHCP”

zfs_enable=”YES”

linux_enable=”YES”

##########################################

/boot/loader.conf

##########################################

virto_load=”YES”
if_vnet_load=”YES”
virto_pci_load=”YES”
virto_blk_load=”YES”

##########################################

And then reboot and wait for 3o minutes. By the way, you have to create both /etc/rc.conf and /boot/loader.conf as they do not exists by default.

You can see the difference here between Linux and BSD. Linux with KVM or Xen only requires loading up a kernel module and the system is set to vitalize. In FreeBSD, you have to jump through hoops and into crap to do the same thing.

Once system has finished rebooting, you have to load up not one but tree kernel modules: vmm, if_tap and if_bridge and manually create network interfaces for the virtual machines:

#######################################
ifconfig tap0 create
ifconfig bridge0 create
ifconfig bridge0 addm em0 addm tap0 up
ifconfig tap0 up

sysctl net.link.tap.up_on_open=1

#######################################

Once again, you can see the difference from Linux. In Linux the network interfaces are created automatically. In BSD you create them by yourself.

By this time keep many knives and cutting weapons far from yourself because you will now be having the urge to harm yourself (Serious).

Download another Freebsd ISO and create a disk image by typing into the same directory:

# truncate -s <size> <disk-image>

Now here’s where the half brain creator’s of Bhyve admit that the pile of crap they created is unusable so they created a script that would make this easier. Copy the script to the same directory as the disk and ISO images.  The shell script is located at /usr/share/examples/bhyve/vmrun.sh. Now edit that shell script:

###########################################
DEFAULT_MEMSIZE=512M
DEFAULT_CPUS=2

DEFAULT_VIRTIO_DISK=”<change to your disk image>”
DEFAULT_ISOFILE=”<ISO image>”

###########################################

Now you finally start virtual machine.

###################################

sh ./<shell script> -i -I <ISO images>

###################################

And see your system slow down by a 1000 times

We tried out these instructions and got one FreeBSD virtual machine to boot after 10 hours (just pointless). By contrast, KVM in Linux took only 30 minutes. Other problems with Bhyve are:

-Can only work on Intel i5 and i7 CPUs

-No AMD support

-No ARM support

-Can only run FreeBSD as a guest

-Huge resource consumption

-Virtual machines require constant attention

-Adjustments are very manual, tedious and time consuming

So as you can see, Bhyve just isn’t fit for use in the real world as each virtual machine takes would unnecessary amounts of work and hours to setup. Bhyve is just simply uncompetitive with Linux KVM or Xen in the area of virtualization. The only positive thing about Bhyve is that it was introduced in a BSD operating system but in terms of it’s virtualizing capabilities and ease of setup, it is just pure bullshit incapable of rapid deployment.

Conclusion

So the sum up everything, FreeBSD 10.0:

-Is much slower

-Xorg is noew virtually unusable except with NVidia

-Intel wifi deos not work anymore

-Bhyve is usless, and not production ready.

Blog defacement

In the past few days, a bunch of hackers managed to hack into this account and deleted all the posts written by our team. Luckily we keep backups of all of our posts.

We apologize for not responding and fixing the defacement quickly. We’ll continue to investigate the perpetrators of this incident.

OpenBSD’s ASLR: Weak, Not Very Random and Not Truly ASLR

Many of the red neck BSD supporters have slashed out by our report on the BSD’s lack of security. Many of them argue that OpenBSD has it’s own ASLR implementation and thus BSD as a whole is somehow more secure that Linux.

We’ve decided to test extent of OpenBSD’s ASLR implementation and compare them with Linux 2.6. We achieve this by running an executable which prints out the location of the stack pointer (ESP). The code for this executable is found in “Gray Hat Hacking” by Shon Harris, Allen Harper, Chris Eagle and Jonathan Ness. This code is:

############################

#include <stdio.h>

unsigned long get_sp(void){
__asm__(“movl %esp, %eax”);
}

int main(){
printf(“Stack pointer (ESP): 0x%xn”, get_sp());
}

############################

This code was executed, 19 times in both OpenBSD 5.4 and CentOS 5.5 (Linux 2.6). Here are the results:

For CentOS 5.5 (Linux 2.6),

#############################

[buxley@localhost HAE]$ uname -a
Linux localhost.localdomain 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:35 EDT 2010 i686 i686 i386 GNU/Linux
[buxley@localhost HAE]$ for i in {1..19}; do ./get_sp; done
Stack pointer (ESP): 0xbf82c528
Stack pointer (ESP): 0xbfbdd478
Stack pointer (ESP): 0xbfa0d9e8
Stack pointer (ESP): 0xbfaf53c8
Stack pointer (ESP): 0xbfe4a318
Stack pointer (ESP): 0xbfa260f8
Stack pointer (ESP): 0xbfe4cac8
Stack pointer (ESP): 0xbf8ba5f8
Stack pointer (ESP): 0xbf8c49b8
Stack pointer (ESP): 0xbffe42c8
Stack pointer (ESP): 0xbfe33a88
Stack pointer (ESP): 0xbfa28cc8
Stack pointer (ESP): 0xbfab8e18
Stack pointer (ESP): 0xbfc42718
Stack pointer (ESP): 0xbfb6d5f8
Stack pointer (ESP): 0xbf945458
Stack pointer (ESP): 0xbfe2a388
Stack pointer (ESP): 0xbfd83d68
Stack pointer (ESP): 0xbfda20c8
[buxley@localhost HAE]$

#############################

For OpenBSD 5.4

#############################

$ uname -a
OpenBSD WorkStation.my.domain 5.4 GENERIC.MP#41 amd64
$ for i in 1 2 3 4 5 6 7 8 9 10 12 13 14 15 16 17 18 19 20; do ./get_sp; done
Stack pointer (ESP): 0xfffdd080
Stack pointer (ESP): 0xfffddaf0
Stack pointer (ESP): 0xffff5810
Stack pointer (ESP): 0xfffdc560
Stack pointer (ESP): 0xfffd20e0
Stack pointer (ESP): 0xfffd06f0
Stack pointer (ESP): 0xfffcf3b0
Stack pointer (ESP): 0xfffbda20
Stack pointer (ESP): 0xfffe1b00
Stack pointer (ESP): 0xfffd81e0
Stack pointer (ESP): 0xfffd7a50
Stack pointer (ESP): 0xfffec200
Stack pointer (ESP): 0xfffde5b0
Stack pointer (ESP): 0xffff9610
Stack pointer (ESP): 0xfffbc6b0
Stack pointer (ESP): 0xffff6df0
Stack pointer (ESP): 0xfffe3940
Stack pointer (ESP): 0xffff5c70
Stack pointer (ESP): 0xffff6cd0
$

#############################

As one can see, OpenBSD’s ASLR implementation is not as random as Linux’s and worst, it appears to follow a vague pattern thus make it not truly random. Thus it can be said that OpenBSD has an “ASLR-like” implementation that is not truly ASLR and not as effective.

Linus Torvalds:

I think the OpenBSD crowd is a bunch of masturbating monkeys…

 

More software projects drop BSD as usage dwindles

Just recently, Opera software, the creator of the Opera web browser announced that they are dropping support for FreeBSD.

http://my.opera.com/desktopteam/blog/2013/09/11/opera-18-developer-stream?startidx=150#comment111974752

As one would deduce, this is a very smart move on the part of Opera as the FreeBSD port of it’s software has always been a huge waste as maintenance is far higher then any other port (due to FreeBSD’s vast and growthing POSIX incompatibility) while it’s usage is an abysmal 0.03% that of Linux ports. Opera staff and developers have noted that FreeBSD usage isn’t just growing slowly or stagnating but it has been shrinking. With the FreeBSD port now liquidated, Opera can invest more man power into increasing the quality of their software.

As for FreeBSD, the repercussions are grave as a survey shows that around 90% of people who actually use FreeBSD is a desktop, use Opera. As Opera becomes usable on FreeBSD, many of these users will eventually jump ship to Linux thus accelerating the shrinking of BSD usage which in turn encourages more software projects to drop BSD support. Many BSD zealots know the implications all too well as they squabble about it an FreeBSD forums (link below).

http://forums.freebsd.org/viewtopic.php?t=41888

The case of Opera abandoning BSD is not the first time that a software project ceased BSD support. There is almost CPanel. Also, almost all Free and Open software projects (like Firefox, GNOME, Xfce etc.) develop and compile their software for Linux leaving BSD porters to do all the work. This results in the latest BSD versions of the software being grossly out of date and full of know security vulnerabilities thus adding to BSD’s already appalling base system security woes. In the case of Opera, there will be no future version of it in BSD as Opera is a proprietary product with BSD components (the irony of the BSD license).

More demonstrations which show that BSD is insecure

A presentation and showing various security faults in FreeBSD, OpenBSD and NetBSD which the developers chose to ignore. Also a full demonstration on how to crack OpenBSD thus busting the myth of it’s security.

Myths and Facts pt.1

Myth
The BSD license does not prevent incorporation of code into proprietary software which makes it more free then the GPL which does.
Fact
By failing to prevent the incorporation of code into proprietary software, the BSD license effectively strips the freedom of the users of proprietary derivatives the software. The GPL in contrast ensures users of all derivatives of the software have retain their freedom.

Myth
The copyright on BSD license cannot be changed or removed as the BSD license does not allow it.
Fact
The BSD license says you must retail the copyright but can modify the code. One can take the copyright and remove/change it under the protection of the modify act and thus effectively removing the copyright and the BSD license. The code no longer belongs to the old copyright owner who put the BSD license on it. The new copyright own now has the right to sue others using the same piece of code.

Myth
The BSD license is a legally valid license.
Fact
The BSD license is legally invalid as it is very short, vague and easily subjected to a wide variety of interpretations so much so that many lawyers and judges today deemed it too vague to be a proper license and thus it is moot.

Myth
With the BSD license, there is little need to worry about any legal complications, limitations or strings attached.
Fact
This is a huge lie. The BSD license’s extreme vagueness and subjectively to interpretations puts it’s all of it’s users great legal risks from companies like Apple, Microsoft and Sony who use the ambiguity of the BSD license and their interpretation as legal leverage on smaller competitors. In fact many law experts say that the BSD license is one of the most dangerous licenses for small and medium sized businesses and thus many now avoid BSD licensed code due to this.

Myth
The FreeBSD project has stated that “The GPL is that it is very favorable to large companies that want to undercut small companies and contributing to monopolistic behavior while the BSD license doesn’t”.
Fact
The FreeBSD project is nothing more then a bunch blatant liars. It is the BSD license that contribute to monopolistic behavior while the GPL actually helps small businesses. The nature of the BSD license forces code and software under it to be of poor quality and useless but none the less a huge starting point. It takes a lot of money, manpower and risk to turn useless BSD cparts and pieces such as FreeBSD, OpenBSD or NetBSD into pseudo-effective proprietary software such as Mac OSX and Windows. Many small companies lack the resources to do this while larger companies do effectively giving them a huge advantage. Also stated earlier, the BSD license can be used by larger companies as legal leverage against smaller companies. Statistics have shown that the BSD license is related to the failure of 40% of all start up software businesses each year and experts predict that statistic could be 70% if it were not for the GPL.

Renewed trolling against Linux at forums.freebsd.org

Well unfortunately, the people at FreeBSD forums have once again started spreading lies about Linux and GNU. This time, the subject was originally meant to start a flame war between FreeBSD and Solaris fan boys but instead one individual managed to steer the thread way off it’s original topic into dragging Linux’s name through mud. The thread can be found here.

I’m going to give my thoughts and responses to some of these comments of interest.

Post by SirDice

Yes, I can’t find my way around any Linux distribution because they all seem to do things differently.

Post by TjPhysicist

Yeah, I recently had the misfortune of doing my Red Hat certification along with my Linux+. So many configuration files in all different places. *shudder*.

Unfortunately due to his BSD logic and thinking, SirDice and TjPhysicist here isn’t able to make use of configuration tools pre-installed in most Linux distribution which negates the need to know the exact setup of the configuration files. It appears that BSD zealots do not know who to use configuration tools except in MacOSX and Windows.

Post by SirDice

Besides that, getting things done on FreeBSD involves learning how it works. That same knowledge can then be applied to any system.

Yes on FreeBSD, you have to learn a lot just to get a little bit done thanks to the poor decisions in design by BSD devs.

Going on, this knowledge cannot be applied to any other system because of a simple fact: *BSDs use the obsolete and flaky BSD style init while many other UNIX systems use the more flexible and functional System V init.

Post by SirDice

On a lot of Linux distributions it usually works with a few mouse-clicks, you can get it running without knowing how it works. It’s almost like Windows

Doesn’t that make Linux systems far easier to configure then BSD systems thus waste less time and money on configuration?

Ah, and then there was this pile of self-contradicting nonsense by BSD junky gpatrick:

Post by gpatrick

Linux does NOT offer anything over AIX or Solaris.

Either gpatrick’s company uses a very old version of Linux from the early 1990s or he himself can’t learn new things or qpatrick is an outright lair (like most BSD nutcases). Either way, there is proof all around that Linux so many things to offer over AIX, Solaris and in particular, BSD. More file systems to choose from, supports more hardware, higher performance kernel with more features, systemd, modern security (SELinux, AppArmor etc), far greater scalability etc.

Post by gpatrick

The mantra of “Linux is less expensive and saves the company money” is outrageous.

GNU/Linux’s use of simple to use configuration tools and the fact that most distributions can be downloaded for free both the cost of procurement and maintenance of Linux systems undercut those of AIX, Solaris and BSD. This has been shown in many companies and as a result, more are adopting Linux.

Post by gpatrick

The company I work for is a Fortune 150 and spends nearly $1 million per year for Linux support. Support should be quoted, because more often than not, they don’t solve any open cases. We’ve had cases open for 2 and 3 years. We’ve had problems with Apache and have been told that since it isn’t Red Hat’s rpm then “sorry we can’t help you.” Some of the Red Hat “crap” just doesn’t work either and has been removed from service like GFS at our company. Too many problems that RH couldn’t figure out and too much of a hassle.

gpatrick here is talking as if Red Hat is the worst provider in terms of support. However, think about the support a company would get if they use BSD. Nothing, no support. Because there is no company which you can go to from support and the BSD project (particualrly OpenBSD) cannot be relied upon because of their general unwillingness to help people. The only “support” an organization using BSD gets is the cryptic online handbook that only the BSD developers themselves can understand.

Post by gpatrick

We constantly have servers with filesystems that go read-only and have to reboot — on production servers.

I have tested Free, Open and DragonflyBSD before and I can tell you that data loss due to file system and kernel crash happens once a week on average. HammerFS was the worse. Also, there will be no one you could go to for help. This is not the case with Red Hat, SUSE or Canonical.

Post by gpatrick

That has never happened to me on either Solaris or AIX.

Typical BSD Orwellian doublethink.

Post by gpatrick

Right now if we “upgrade” a server from RHEL4 to RHEL5 or RHEL6, it is, overwrite the disk and restore data.

Same with BSD

Post by gpatrick

Architecture also plays a crucial role. Power and Sparc are clearly winners over the x86 garbage architecture. We have way more downtime with Linux/x86 than with AIX/Power and Solaris/Sparc.

gpatrick here must be using 1990s era 16-bit x86 hardware because today’s x86 architectures have far out stripped Power and Sparc architectures due to more investment being put into them. This is one reason why MacOSX switched from powerpc to intel x86 hardware. Even gpatrick here should know that as he is a hardcore BSD zealot thereby, uses a Mac.

Post by gpatrick

The only reason Linux has its place in the corporate world is some stooge higher up in the company sees some other stooge at another company doing it, and that moron says it is saving them huge amounts of money. Nothing can be further from the truth. I point you to the preceding paragraphs as proof.

So as I said above, even the stooges who brought in one of the worst operating systems ever developed on the garbage architecture it runs upon realize it is a pig in a poke, but they won’t change because their mistake would be very visible and they’d have to answer why they chose it.

Sounds a lot like typical BSD project management.

Post by CoTones

Little off topic, but dinosaurs so big and powerful, especially when compared to mammals, so talking about their extinction is pure nonsense, isn’t?

True, except that Solaris is a lot more like an annoying ant.

Post by gpatrick

This week at work we have had a Red Hat GFS cluster on x86 have major problems which required one of the nodes to be rebuilt. After the rebuilt was completed we were told not to join the node back into the cluster because, and this is just classic, “management doesn’t trust GFS or the hardware.”

It’s more like gpatrick screwed up his companies’ Linux installations. This is why many companies looking to hire UNIX administrators don’t hire BSD nutcases like gpatrick because they know know so little about Linux and often screw up when administrating a Linux server. They’d hire people who are good at Linux.

Post by gpatrick

So as I said above, even the stooges who brought in one of the worst operating systems ever developed on the garbage architecture it runs upon realize it is a pig in a poke, but they won’t change because their mistake would be very visible and they’d have to answer why they chose it.

Stooges are people who bring BSD in to their company even as it has been shown to be a less then efficient and effective solution even in server environments. Also, the lack of protection mechanisms such as ASLR make deploying BSD in any situation suicidal.

In terms of being a Desktop, Server, embedded or anything, BSD can easily be the worst operating system for the task. Choosing it over literally anything else is a clear sign of brain damage.

Post by gpatrick

So the stooges just pretend that $1 million per year for Red Hat support and the many hours of downtime in Red Hat Linux problems, that usually are not ever resolved by Red Hat, and defective x86 hardware is saving them money.

Again sounds a lot like the BSD projects.

Post by Crivens

Hatred? I don’t think so. Or at least hope so. Dislike, with experience to back it up? More likely.

This is typical BSD mentally on the Linux communities and free software. Fueled, not by experience or knowledge but by jealousy, fanaticism, hatred of freedom and brainwashing.

And the thread then switches to the subject of how good AIX is. Considering how much they love proprietary software such as Macs, AIX and Solaris it’s no suprise.

Spyware now implementing on FreeBSD.org

While browsing through the FreeBSD mailing lists, I came across a very alarming piece of development at FreeBSD’s official website.

Quote taken from the thread:

The FreeBSD Project’s Web developer announced his intent to incorporate corporate spyware into the FreeBSD.org Web site.

Horrifying as it is, it is not surprising that such proprietary friendly organisation would do such a thing. Since the 1990s, the BSDs as a whole has been assisting the proliferation of proprietary systems such as Microsoft Windows and Apple Macintosh in a hope that they can use them as a vehicle to destroy GNU/Linux, the operating system that champions individual freedom. This move in some sense backfired on the BSD projects as they are now forced into servitude by these tyrants they help thus resulting in little code contributions and lost of developers to these tyrants or (if the developer excepts the the facts) GNU/Linux and worst of all, infiltration and influence by proprietary interests. Today, many BSD project members area in fact operatives from proprietary and freedom hating entities steering the BSD projects to for their own ends keeping BSD from being usable and instead making the project produce code fragments that used as fuel for the development of proprietary software.

FreeBSD is more Insecure then Windows

Yesterday, We received information from a friend about some alarming information about FreeBSD and the attitude that the FreeBSD community (more like cult) has to this issue.

After being banned from accessing forum.FreeBSD.org for simply mentioning this problem, Felix Doggoson deciding to share with us this information. Here is what he says:

By Felix Doggoson


I was doing an analysis for my company who is looking to select a new operating system
for their recently created server farm. I was analyzing FreeBSD when I found something
alarming about it.

I ran a program that I made called simplegets, and then I looked at it’s layout in virtual
memory while running and this is what I got:


doggoson@fbsd:/home/doggoson % ps aux | grep simplegets

doggoson 13381 0.0 0.1 9920 1416 0 I+ 2:07PM 0:00.00 ./simplegets

doggoson 13398 0.0 0.1 16288 1776 1 S+ 2:08PM 0:00.00 grep simplegets

doggoson@fbsd:/home/doggoson % cat /proc/13381/map

0x400000 0x401000 1 0 0xfffffe003c103828 r-x 1 0 0x1000 COW NC vnode
/usr/home/doggoson/simplegets NCH -1

0x600000 0x800000 2 0 0xfffffe0016de89f8 rw- 1 0 0x3000 NCOW NNC default - CH
1001

0x800600000 0x800618000 24 0 0xfffffe00076ed658 r-x 90 0 0x1004 COW NC vnode
/libexec/ld-elf.so.1 NCH -1

0x800618000 0x800639000 21 0 0xfffffe001e195828 rw- 1 0 0x3000 NCOW NNC
default - CH 1001

0x800817000 0x800819000 2 0 0xfffffe0023bf22b8 rw- 1 0 0x3000 NCOW NNC default
- CH 1001

0x800819000 0x800947000 258 0 0xfffffe00076ed000 r-x 166 76 0x1004 COW NC
vnode /lib/libc.so.7 NCH -1

0x800947000 0x800b46000 0 0 0xfffffe005afdc9f8 --- 1 0 0x2000 NCOW NNC default -
NCH -1

0x800b46000 0x800b51000 11 0 0xfffffe00374cd9f8 rw- 1 0 0x3000 COW NNC vnode
/lib/libc.so.7 CH 1001

0x800b51000 0x800b6c000 8 0 0xfffffe0067d37740 rw- 2 0 0x3000 NCOW NNC default
- CH 1001

0x800c00000 0x801000000 8 0 0xfffffe0067d37740 rw- 2 0 0x3000 NCOW NNC default
- CH 1001

0x7ffffffdf000 0x7ffffffff000 3 0 0xfffffe00790363a0 rw- 1 0 0x3000 NCOW NNC default
- CH 1001
0x7ffffffff000 0x800000000000 0 0 0xfffffe0007515cb0 r-x 94 0 0x4 COW NC default -
NCH -1

doggoson@fbsd:/home/doggoson %


The suprise came when I ran simplegets a second time:


doggoson@fbsd:/home/doggoson % ps aux | grep simplegets

doggoson 13446 0.0 0.1 9920 1416 0 S+ 2:12PM 0:00.00 ./simplegets

doggoson 13449 0.0 0.1 16288 1776 1 S+ 2:12PM 0:00.00 grep simplegets

doggoson@fbsd:/home/doggoson % cat /proc/13446/map

0x400000 0x401000 1 0 0xfffffe003c103828 r-x 1 0 0x1000 COW NC vnode
/usr/home/doggoson/simplegets NCH -1

0x600000 0x800000 2 0 0xfffffe004a9b3910 rw- 1 0 0x3000 NCOW NNC default - CH
1001

0x800600000 0x800618000 24 0 0xfffffe00076ed658 r-x 90 0 0x1004 COW NC vnode
/libexec/ld-elf.so.1 NCH -1

0x800618000 0x800639000 21 0 0xfffffe00660a13a0 rw- 1 0 0x3000 NCOW NNC
default - CH 1001

0x800817000 0x800819000 2 0 0xfffffe00790390e8 rw- 1 0 0x3000 NCOW NNC default
- CH 1001

0x800819000 0x800947000 258 0 0xfffffe00076ed000 r-x 166 76 0x1004 COW NC
vnode /lib/libc.so.7 NCH -1

0x800947000 0x800b46000 0 0 0xfffffe00486fd910 --- 1 0 0x2000 NCOW NNC default -
NCH -1

0x800b46000 0x800b51000 11 0 0xfffffe00600819f8 rw- 1 0 0x3000 COW NNC vnode
/lib/libc.so.7 CH 1001

0x800b51000 0x800b6c000 8 0 0xfffffe00302672b8 rw- 2 0 0x3000 NCOW NNC default
- CH 1001

0x800c00000 0x801000000 8 0 0xfffffe00302672b8 rw- 2 0 0x3000 NCOW NNC default
- CH 1001

0x7ffffffdf000 0x7ffffffff000 3 0 0xfffffe007219f740 rw- 1 0 0x3000 NCOW NNC default
- CH 1001

0x7ffffffff000 0x800000000000 0 0 0xfffffe0007515cb0 r-x 94 0 0x4 COW NC default -NCH -1

doggoson@fbsd:/home/doggoson %


As you can see, all the memory addresses have not changed which shows that FreeBSD
lacks Address Space Layout Randomization or ASLR, an important security feature that all
other operating systems including Windows have.

Linux has ASLR as shown when simplegets is executed once:


doggoson@bluebook ~ $ ps aux | grep simplegets

doggoson 4134 0.0 0.0 4080 348 pts/0 S+ 13:59 0:00 ./simplegets

doggoson 4145 0.0 0.0 8052 916 pts/1 S+ 13:59 0:00 grep --colour=auto simplegets

doggoson@bluebook ~ $ cat /proc/4134/maps

00400000-00401000 r-xp 00000000 08:06 261421
/home/doggoson/Workspace/CC+/simplegets

00600000-00601000 rw-p 00000000 08:06 261421
/home/doggoson/Workspace/CC+/simplegets

7f704e324000-7f704e4c6000 r-xp 00000000 08:08 4461920 /lib/x86_64-linux
gnu/libc-2.17.so

7f704e4c6000-7f704e6c6000 ---p 001a2000 08:08 4461920 /lib/x86_64-linux
gnu/libc-2.17.so

7f704e6c6000-7f704e6ca000 r--p 001a2000 08:08 4461920 /lib/x86_64-linux
gnu/libc-2.17.so

7f704e6ca000-7f704e6cc000 rw-p 001a6000 08:08 4461920 /lib/x86_64-linux
gnu/libc-2.17.so

7f704e6cc000-7f704e6d0000 rw-p 00000000 00:00 0

7f704e6d0000-7f704e6f1000 r-xp 00000000 08:08 4461916 /lib/x86_64-linux
gnu/ld-2.17.so

7f704e8d0000-7f704e8d3000 rw-p 00000000 00:00 0

7f704e8ee000-7f704e8f1000 rw-p 00000000 00:00 0

7f704e8f1000-7f704e8f2000 r--p 00021000 08:08 4461916 /lib/x86_64-linux
gnu/ld-2.17.so

7f704e8f2000-7f704e8f4000 rw-p 00022000 08:08 4461916 /lib/x86_64-linuxgnu/ld-2.17.so

7fffdca09000-7fffdca2a000 rw-p 00000000 00:00 0 [stack]

7fffdca49000-7fffdca4b000 r-xp 00000000 00:00 0 [vdso]

ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

doggoson@bluebook ~ $


and again


doggoson@bluebook ~ $ ps aux | grep simplegets

doggoson 4173 0.0 0.0 4080 348 pts/0 S+ 14:02 0:00 ./simplegets

doggoson 4176 0.0 0.0 8052 916 pts/1 S+ 14:02 0:00 grep --colour=auto simplegets

doggoson@bluebook ~ $ cat /proc/4173/maps

00400000-00401000 r-xp 00000000 08:06 261421
/home/doggoson/Workspace/CC+/simplegets

00600000-00601000 rw-p 00000000 08:06 261421
/home/doggoson/Workspace/CC+/simplegets

7f1e449ac000-7f1e44b4e000 r-xp 00000000 08:08 4461920 /lib/x86_64-linux
gnu/libc-2.17.so

7f1e44b4e000-7f1e44d4e000 ---p 001a2000 08:08 4461920 /lib/x86_64-linux
gnu/libc-2.17.so

7f1e44d4e000-7f1e44d52000 r--p 001a2000 08:08 4461920 /lib/x86_64-linux
gnu/libc-2.17.so

7f1e44d52000-7f1e44d54000 rw-p 001a6000 08:08 4461920 /lib/x86_64-linux
gnu/libc-2.17.so

7f1e44d54000-7f1e44d58000 rw-p 00000000 00:00 0

7f1e44d58000-7f1e44d79000 r-xp 00000000 08:08 4461916 /lib/x86_64-linux
gnu/ld-2.17.so

7f1e44f58000-7f1e44f5b000 rw-p 00000000 00:00 0

7f1e44f76000-7f1e44f79000 rw-p 00000000 00:00 0

7f1e44f79000-7f1e44f7a000 r--p 00021000 08:08 4461916 /lib/x86_64-linux
gnu/ld-2.17.so
7f1e44f7a000-7f1e44f7c000 rw-p 00022000 08:08 4461916 /lib/x86_64-linux
gnu/ld-2.17.so

7fff4049f000-7fff404c0000 rw-p 00000000 00:00 0 [stack]

7fff405fe000-7fff40600000 r-xp 00000000 00:00 0 [vdso]

ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

doggoson@bluebook ~ $


As you can see, not only is the address space layout of simplegets neater and simpler but
more importantly, the memory addresses have changed showing that Linux is well
protected using ASLR.

It just goes to show, FreeBSD is not safer then Linux but rather the other way round.

As what Felix himself said, FreeBSD and possibly all other BSDs include OpenBSD lack modern security features. By comparison, even Microsoft Windows has an implementation of ASLR.

In the case of FreeBSD, it is particularly alarming as the FreeBSD project under IXsystems has been suspected of working with malicious organizations such as Apple, Microsoft, the CIA, NSA, and possibly even the KGB.

FreeBSD’s voluntary exclusion of protection mechanisms and the unwillingness of the FreeBSD community to discuss this issue with Felix shows that it is very likely that the FreeBSD project like the OpenBSD project intentionally makes their OS releases less secure to allow easy access for malicious agencies.

Richard Stallman, Linus Torvalds and the GNU/Linux community by contrast have show that such things are unacceptable in their OS releases and go though every measure to prevent that from happening.

“BSD hacker” – A self contradicting term

When ever I take a look at the BSD mailing lists, often see the term “BSD hacker” been used which is a huge irony.

The term hacker (before popular media used it for something else) is to describe a people how goes through lengths at trying to discover new ways to get more out of a piece of software or a piece engineering even to a extent in which it was not originally designed for. Hackers avoid reinventing the wheel and instead focus on discovering new things. This is in exact contrast BSD developers who consistently reinvent the wheel and stubbornly stick to outdating practices and technology even then it is causing them to fall behind. BSD developers thus are the extreme opposite of hackers.