This paper describes low level design and implementation of the FreeBSD operating system port for the MPC8572 system-on-chip device, a high-end member of the Freescale PowerQUICC III family. The primary focus of this work is describing how the multi-core operation was brought forward and full SMP capabilities achieved, but other major components developed in the course of this project, device drivers in particular, are also covered.
The FreeBSD 2009 Quarterly Status Report is now available (Jan – Mar):
Since the last Status Reports there has been interesting progress in FreeBSD Development. FreeBSD 7.2 was released just a few days ago. Some of the highlights include: Support for superpages in the FreeBSD Virtual Memory subsystem. The FreeBSD Kernel Virtual Address space has been increased to 6GB on amd64. An updated jail(8) subsystem that supports multi-IPv4/IPv6/noIP and much more.
Table of contents:
- Clang replacing GCC in the base system
- Device mmap() Extensions
- Release Engineering
- Sysinfo – a set of scripts which document your system
- TrustedBSD MAC Framework in GENERIC
- VFS/NFS DTrace Probes
- VirtualBox on FreeBSD
FreeBSD Team Reports
Google Summer of Code
Whole report below: [Read more…]
I sent an email to Dylan Cochran with some question regarding his Evoke BSD project. It’s been sitting in my email for a little while, so it’s time to post it.
These were my questions and Dylan’s answers:
1) Can you give a quick update on the state of the project and what you’re planning for 2009.
We are going to make a release soon, and have been working on solidifying procedures, adding documentation, etc. A lot of the unexciting phases.
2) Can you explain how Evoke is different from nanoBSD.
NanoBSD, TinyBSD, PicoBSD, etc, are toolkits to build FreeBSD for embedded devices.
Evoke is not primarily a toolkit, though we have a flexible build system similar to TinyBSD’s, it’s not intended to be used by the users.
I could spend several paragraphs explaining out differences in detail, however, I’d rather talk about our goals. For one, we have tried to clean up our namespace; so that there are no collisions in operation. This means that we can have multiple versions of evoke on a disk, support multiple architectures per version, and even, multiple abis per version. Since the beginning, we’ve built for 6.x and 7.x at the same time, and we’ve also had amd64 and i386 support being built at the same time (Unfortunately, due to economics, we can’t build the amd64 binaries at this time)
The active version, abi, architecture, they are all seperated on several levels. This allows us to remove restrictions that prevent users from running arbitrary i386 binaries on amd64, from moving a
machine from i386 to amd64, to i386, to back again, without losing data or putting the system in an inconsistant state if problems occur.
We also abstract as many interfaces as we can, that may be architecture or abi specific. For example, rather then using mount, you would use mounter, which has a more abstract interface for
handling various filesystems, native, fuse, or otherwise. This grew out of the necessity of dealing with many different mount interfaces between various kernels.
This is a small sample, there is much more. I’ve been pulling in a lot of design elements from a lot of sources, and using the most effective ones for our needs. It’s deceptively simple.
3) When are you planning to release a new version (alpha, beta?)
We are nearing our first ‘real’ release, 0.1. Though we aren’t there yet, there are some autoconf related bugs in the 6.4 target, and some missing features that I consider show stoppers. A big problem is Xorg support, as Xorg and it’s modules take up a large amount of disk space; inflating our image size signficantly. I would rather use kdrive, and build Xvesa, but all my attempts at porting it so far have
failed. So it’s still up in the air on whether or not X support will be in 0.1.
4) Are you planning to track FreeBSD releases (like PC-BSD, FreeNAS, pfSense etc) as the underlying base or are you forking (like MidnightBSD or DragonFlyBSD)
We build for multiple targets, FreeBSD 6.4, 7.1, and even 8-CURRENT. We also have support for other kernels, Linux, Plan 9, etc, but the build system and scripts don’t have any real support for it.
5) Does the project have a new logo yet?
6) Any other things you want to let the BSD community know?
We are always looking for help, our blog has an entry on contributions, and a list of things we are having problems with. If anyone has any knowledge on these problems (especially kdrive) I will be grateful.
Many thanks to Dylan for his time and for explaining a bit more about the background of Evoke.
Tonight I’ve updated the FreeBSD Flavours and projects page. There was a broken link, some missing pictures and the content had to be updated here and there.
Please have a look and let me know what you think and/or if anything is missing.
Also, I’d like to include some non English FreeBSD projects on there as well, and I need your help really. If you’re aware of, say, a Russian FreeBSD project (by Russions, for Russions), I’d love to hear from you. So if you know a localised, non-English FreeBSD project, please let me know, so they can be included here.
Android is an exciting and much promising (open source) mobile phone platform developed by Google.
Android 1.5 (Cupcake), has now been released and promises to be(come) a strong contender for Apple’s iPhone. The first Android powered netbook is coming, Acer is working on several Android devices, and Samsung is releasing the Android I7500 phone.
So, why am I writing this?
First, Android is exciting; second, there’s a project working on porting the Android framework to FreeBSD: BSDroid, and thirdly, the Android software uses bits of NetBSD and OpenBSD userland code.
The main goal of project is to provide native binaries for tools and make it possible to develop Android applications on FreeBSD powered system without Android SDK for Linux.
Visit BSDroid for more information and downloads
The developers of the CoreBoot project have released FlashROM 0.9 which is able to read, delete, rewrite and verify the flash chips which store a systems BIOS.
coreboot (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today’s computers. It performs just a little bit of hardware initialization and then executes a so-called payload.
Benefits: 100% Free Software (GPL), no royalties, no license fees! Fast boot times (3 seconds to Linux console)
FlashROM runs on FreeBSD, Linux, Solaris and Mac OS X and allows re-flashing to take place from the command line on a running operating system. With FlashROM it is possible to re-flash the BIOS without rebooting the PC at all. Most manufacturers’ flash programming utilities only support Windows / DOS and require you to reboot the PC in order to re-flash the BIOS. The FlashROM program only requires root access to a system and can be run remotely via SSH.
A wide range of motherboards and flash chip-sets (157 flash chip families and 75 different chip-sets) are supported. There’s also support for dozens of non-standard x86 motherboards are supported in the 0.9.0 release.
ZFS is a relatively new and exciting file storage system developed by Sun.
The features of ZFS include support for high storage capacities, integration of the concepts of filesystem and volume management, snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z and native NFSv4 ACLs. – Wikipedia
This page has some specific FreeBSD info relating to ZFS.
Interested to find out more about the strengths of ZFS? Have a look at the video’s below:
Pav Lucistnik has been working on ports compilations utilising multiple cores:
Two days ago, I have checked in probably most requested feature of last few years. Ports framework now systematically supports building ports on multiple processing cores. It is achieved by passing -jX flag to make(1) running on vendor code. Of course not all ports handle this well, experimental run on pointyhat with this flag globally enabled turned up shy of 400 failures. Because of that, the feature was designed as a
whitelist. Individual ports need to be enabled, and indeed, fellow developers took on and already started adding required declarations to popular ports like Firefox and others.
after a lot work and hacking we got finaly VirtualBox to start under FreeBSD HEAD. 6 Days work was needed with about 20 patches. :). This works is done by Bernhard Froehlich, beat@, dhn@ and myself. A lot thanks to the VirtualBox Developers were helped here :).
He’s posted a number of screenshots here.
More on VirtualBox on FreeBSD here.
These are some recent links with regards FreeBSD security:
1. Using DenyHosts to help thwart SSH attacks on FreeBSD
DenyHosts is a script intended to be run by UNIX-like system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).
- % su
- # cd /usr/ports/security/denyhosts
- # make install clean
- # echo ‘denyhosts_enable=”YES”‘ >> /etc/rc.conf
- # echo ‘syslogd_flags=”-s -c”‘ >> /etc/rc.conf
- # echo “sshd : /etc/hosts.deniedssh : deny” >> /etc/hosts.allow
- # echo “sshd : ALL : allow” >> /etc/hosts.allow
- # touch /etc/hosts.deniedssh
- Edit /usr/local/etc/denyhosts.conf and uncoment the BLOCK_SERVICE = sshd entry.
- # /usr/local/etc/rc.d/denyhosts onestart
Source – linux-bsd-sharing.blogspot.com
2. Network Security Monitoring
Richard Bejtlich, from TAO Security, did a presentation on network security monitoring using FreeBSD.
In this presentation I’ll discuss my latest thinking on using FreeBSD to identify normal, suspicious, and malicious traffic in enterprise networks. FreeBSD is a powerful platform for network traffic inspection and log analysis, and I’ll share a few ways I use it in production environments.
3. FreeBSD supported branches update
The branches supported by the FreeBSD Security Officer have been updated to reflect the EoL (end-of-life) of FreeBSD 7.0. The new list is below and at . Please note that FreeBSD 7.0 was originally announced with an EoL date of February 28, 2009, but the EoL was delayed by two months in order to allow a 3 month window for systems to be upgraded to FreeBSD 7.1. [source]
The current designation and estimated lifetimes of the currently supported branches are given below. TheEstimated EoL (end-of-life) column gives the earliest date on which that branch is likely to be dropped. Please note that these dates may be extended into the future, but only extenuating circumstances would lead to a branch’s support being dropped earlier than the date listed.
- RELENG_6 – 30 November 2010
- RELENG_6_3 – 31 January 2010
- RELENG_6_4 – 30 November 2010
- RELENG_7 – last release + 2 years
- RELENG_7_1 – 31 January 2011
These dates can also be found on the calendar at BSDEvents.net
4. How to harden FreeBSD
After a fresh install, it is important to harden the security on a server before it hits your network for use. Not only making configuration changes aid in the security of your box, but there are some practical rules to abide by. These are some hardening tips to make your FreeBSD box more secure and will apply to both the 5.x and 4.x branches, but I will assume you are running 5.x. If a 4.x change is different, I will note it.
Instructions here (Tux Training)