<!DOCTYPE HTML PUBLIC "-//FreeBSD//DTD HTML 4.01 Transitional-Based Extension//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD$">
<!ENTITY title "FreeBSD Summer of Code 2008">
<!ENTITY % navinclude.developers "INCLUDE">
<!ENTITY % developers PUBLIC "-//FreeBSD//ENTITIES FreeBSD Developers Entities//EN"> %developers;
]>

<html>
&header;

<p>The FreeBSD Project is proud to have taken part in the Google <a
  href="http://code.google.com/soc">Summer of Code
  2008</a>.  We received more high quality applications this year than
  ever before.  In the end it was a very tough decision to narrow it
  down to the 21 students selected for funding by Google.  
  These student projects included security research,
  improved installation tools, new utilities, and more.  Many of the
  students have continued working on their FreeBSD projects even after
  the official close of the program.</p>

<p>We are happy to report that the 19 students listed below
  completed the program successfully.</p>

<p>Information about the student projects is available from our <a
  href="http://wiki.freebsd.org/SummerOfCode2008">Summer of Code
  wiki</a> and all of the code is checked into <a
  href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/">Perforce</a>.
  The summaries below were submitted by the individual students and
  their mentors with minor editing for consistency.</p>

<a name="students"></a>
<h2>2008 Student Projects</h2>

<ul>
  <li>
    <strong>Project:</strong> Implementation of MPLS in FreeBSD<br>
    <strong>Student:</strong> Ryan French<br>
    <strong>Mentor:</strong> &a.andre;<br>

    <strong>Summary:</strong>

    <p>MPLS is a networking protocol used for routing information
      quickly and efficiently. It is used extensively in the
      internet's backbone networks.  Over the course of the program,
      code has been ported to FreeBSD from the OpenBSD/NetBSD
      operating systems. Basic functionality of sending and receiving
      packets was the main goal of the project, but unfortunately this
      was not achieved. It is very close to having this functionality,
      but there are a few minor bugs preventing the code from
      integrating fully with the FreeBSD networking stack.</p>

    <p>This project will continue to be worked on until sending,
      receiving, label swapping, tunnels, and the LDP daemon has been
      successfully implemented.</p>

    <strong>Ready to enter CVS/SVN:</strong> No.</li>

  <li>
    <strong>Project:</strong> TCP/IP regression test suite (tcptest)<br>
    <strong>Student:</strong> Victor Hugo Bilouro<br>
    <strong>Mentor:</strong> &a.gnn;<br>

    <strong>Summary:</strong>

    <p>As a testing tool, it can perform regression, protocol
      conformance, and fuzz tests. The tool may also be employed as an
      aid to protocol developers and both testing and debugging of
      firewalls/routers.</p>

    <p>It is built on top of PCS(Packet Construction Set) "PCS is a set
      of Python modules and objects that make building network
      protocol code easier for the protocol developer. PCS enables
      testing at OSI layers 3, 4, and 5."</p>

    <p>Tcptest mainly is a python module and one script for each test
      covered (more then one per script often) The module count with
      methods acting as fasteners, doing things like (a)three way
      handshake, (b)active/passive close and (c)several createXX and
      assertXX, where XX=(ip, tcp, rst, urg, fin, syn, psh, so on...)
      As the tests are being created, the number of 'fasteners' are
      growing, turning each moment easier to create new tests.</p>

    <p>Use of small tests. So we can cover a wide range of traffics,
      events and transitions predetermined separately. The development
      would be like a protocol, but without covering all possible
      events and transitions, only traffic previously
      determined. Instead of targeting a TCP Finite State Machine
      (FSM) like the implementation of TCP/IP protocols, the
      development will be based towards flow of packets, where traffic
      is composed of packets that are sent and received in a
      previously registered way.</p>

    Links:
    <a href="http://wiki.freebsd.org/VictorBilouro/TCP-IP_regression_test_suite">project wiki</a>
    <a href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/bilouro_tcptest/src">&os; Perforce project repository</a>
    <a href="http://code.google.com/p/tcptest/">source code download</a>
    <a href="http://bilouro.com/tcptest">source code documentation</a>
    <a href="http://pcs.sf.net">Packet Construction Set</a>
  </li>

  <li>
    <strong>Project:</strong> Porting Open Solaris Dtrace Toolkit to FreeBSD<br>
    <strong>Student:</strong> Liqun Li<br>
    <strong>Mentor:</strong> &a.jb;<br>

    <strong>Summary:</strong>

    <p>Sun Open Solaris Dtrace is pretty useful feature.  Users can find
      performance bottlenecks with Dtrace in real production
      environment. Since many probes implemented in Open Solaris are
      not supported in FreeBSD, the Open Solaris Dtrace Toolkit should be
      ported to &os;. Its main job is to find whether a given probe is supported by
      FreeBSD, if so, find it; if not, develop one to support this
      function. This summer, at first, I went through all DTK script
      commands, found some of them work directly. But most do
      not. Under my mentor John Birrell careful help, I retrieved the
      respective FreeBSD kernel variables, and ended up making
      system/uname.d work. In addition, I tried to make sar-c.d work
      under FreeBSD. Since we need to investigate in Sun Open
      Solaris Kernel how Open Solaris defines the probe and
      what probes it needs, this work is really time consuming, and not
      done yet. From this project, I got to know much about FreeBSD
      kernel and Dtrace probes. I found kernel hacking/coding pretty
      interesting.</p>

    <strong>Ready to enter CVS/SVN:</strong> not decided</li>

  <li>
    <strong>Project:</strong> Adding .db support to pkg_tools --> pkg_improved<br>
    <strong>Student:</strong> Anders Nore<br>
    <strong>Mentor:</strong> &a.flz;<br>

    <strong>Summary:</strong>

    <p>This project is a replication of the pkg_install tools with
      several new features and speed improvements due to the caching
      of some package-information to a B-Tree Berkeley DB file. Some
      of the new features is the adding of installtime to the
      installed packages +CONTENTS file, human-readable size-output in
      pkg_info(1), progress indication to pkg_add's remote
      option. Installtime range searches with pkg_info(1) and
      pkg_delete(1) similar to that of version search is now available
      using the -M option.</p>

    <p>A new tool pkg_convert(1), caches some parts of the existing
      /var/db/pkg/ flat database into a Berkeley DB file, and the
      tools check for this file and uses it for speed improvements if
      it is available and updates it according to
      pkg_{add|delete}'s. You can also use pkg_convert(1) to view the
      entries in the cache. The tools will give you an indication if
      the database is corrupt, and it is fully recoverable by using
      pkg_convert(1).</p>

    <p>Two bugs in the existing pkg_tools have also been discovered
      and fixed, everything is of course backwards-compatible with the
      older/original pkg_install tools.</p></li>

  <li>
    <strong>Project:</strong> Porting BSD-licensed text-processing tools from OpenBSD<br>
    <strong>Student:</strong> Gabor Kovesdan<br>
    <strong>Mentor:</strong> Max Khon<br>

    <strong>Summary:</strong>

    <p>At the moment, BSD grep seems to be ready and highly compatible
      with the GNU version. However, there are differences in the
      regex handling, which is a result of the different
      interpretations, that the different regex libraries use and thus
      it is not really possible to fix at the level of grep. As for
      diff, some progress has been made, but some important features
      are still missing. The sort utility seemed to be badly
      constructed concerning the wide character support and the
      overall implementation. Because of these difficulties, the
      efforts were prioritized for grep and diff. Probably sort needs
      a complete rewrite or at least an extreme amount of
      modifications.</p>

    <strong>Ready to enter CVS/SVN:</strong> If we can accept the
      regex differences in grep, it is ready to enter SVN after some
      thorough testing. As for diff and sort, they can be installed
      via the Ports Collection.
  </li>

  <li>
    <strong>Project:</strong> Multibyte collation support<br>
    <strong>Student:</strong> Konrad Jankowski<br>
    <strong>Mentor:</strong> &a.dds;<br>

    <strong>Summary:</strong>

    <p>Collation is what allows for current language/encoding correct
      sorting/ordering of strings. This project aimed to add proper
      collation in UTF-8 encodings for all languages for FreeBSD. This
      summer I have accomplished:</p>

    <ul>
      <li>imported data from the Unicode Consortium: POSIX locale files
       and regression test data</li>
      <li>written converter scripts to extract collation data from this
       files</li>
      <li>ported Apple's version of colldef (which is our version, but
       much extended by them)</li>
      <li>extended the colldef even more, to work on collation data from
       the Unicode Consortium</li>
      <li>added some performance improvements, the biggest one not used
       by default now (no time to test yet) - reading the charmap only
       once for all languages</li>
      <li>ported Apple version of strcoll, wcscoll, strxfrm, wcsxfrm and
       locale/collate.c, taking out xlocale (rationale on wiki)</li>
      <li>Written regression test scripts. It appeared that Apple's code
       doesn't full Unicode Collation Algorithm - the part which deals
       with expansions. It is needed for half of languages to pass the
       more advanced regression tests.</li>
      <li>for last few days I am working on implementing expansions, I will
       not rest until they work</li>
      <li>I was not able to start writing manpages and create a megapatch
       against HEAD, I'll do that when the algorithm is 100% correct
       for all the languages.</li>
    </ul>

    <p>Current information will be available on my wiki:
    http://wiki.freebsd.org/KonradJankowski/Collation</p>

    <strong>Ready to enter CVS/SVN:</strong> After finishing expansion support and
	  cleanup.
  </li>

  <li>
    <strong>Project:</strong> VM Algorithm Improvement<br>
    <strong>Student:</strong> Mayur Shardul<br>
    <strong>Mentor:</strong> &a.jeff;<br>

    <strong>Summary:</strong>

    <p>A new data structure, viz. radix tree, was implemented and used
      for management of the resident pages. The objective is efficient
      use of memory and faster performance. The biggest challenge was
      to service insert requests on the data structure without
      blocking. Because of this constraint the memory allocation
      failures were not acceptable, to solve the problem the required
      memory was allocated at the boot time. Both the data structures
      were used in parallel to check the correctness and we also
      benchmarked the data structures and found that radix trees gave
      much better performance over splay trees.</p>

    <strong>Ready to enter CVS/SVN:</strong> We will investigate some more approaches
    to handle allocation failures before the new data structure goes
    in CVS.
  </li>

  <li>
    <strong>Project:</strong> TCP anomaly detector<br>
    <strong>Student:</strong> Rui Paulo<br>
    <strong>Mentor:</strong> &a.andre;<br>

    <strong>Summary:</strong>

    <p>The TCP Anomaly Detector (tcpad, for short) project went
      reasonably well. I am currently tracking some bugs and lowering
      the number of false positives.</p>

    <p>tcpad tries to monitor TCP connections and detect
      non-conformant hosts. It does this by sniffing packets on the
      wire and creating, what I would like to call, a virtual TCP
      stack on each end. When an error is detected, tcpad creates a
      pcap file with all the packets exchanged between the two hosts
      and the state of each virtual TCP stack.</p>

    <p>tcpad is still being developed, so expect it to "detect" dozens
      of "problems" after running for some minutes.</p>

    <p>I was a bit late developing results because the SoC began
      before my exams did (I was still having classes), but now, that
      "damage" is partly fixed. ;-) Overall, this SoC was a really
      interesting learning experience. I must say that my TCP
      knowledge has increased a few points. :-)</p>

    <p>Andre Oppermann is my mentor. I blogged a bit about this
      project at <a href="http://blogs.freebsdish.org/rpaulo/">my blog</a>.
      The wiki page is located <a
	href="http://wiki.freebsd.org/RuiPaulo/TCPAnomaly">here</a>.</p>

    <strong>Ready to enter CVS/SVN:</strong> No.
  </li>

  <li>
    <strong>Project:</strong> FreeBSD auditing system testing<br>
    <strong>Student:</strong> Vincenzo Iozzo<br>
    <strong>Mentor:</strong> Attilio Rao<br>

    <strong>Summary:</strong>

    <p>The project was focused on testing the audit system. The first
      part of the project consisted of writing a patch for
      /dev/auditpipe in order to preselect events by process' pid. The
      second half was focused on creating a testing framework for
      audit. Some auxiliary functions and modules were written. What is
      missing: - More abstraction in the framework - More tests for
      events</p>
  </li>

  <li>
    <strong>Project:</strong> Dynamic memory allocation for dirhash in UFS2<br>
    <strong>Student:</strong> Nick Barkas<br>
    <strong>Mentor:</strong> &a.dwmalone;<br>

    <strong>Summary:</strong>

    <p>Modified dirhash code in perforce is now able to free up memory
      used by older dirhashes when the VM system invokes vm_lowmem
      events. This will allow the default dirhash_maxmem value to be
      increased, improving performance on large directory lookups when
      there is memory to spare on they system. There are versions of
      the low memory event handling code for both -CURRENT and
      7-STABLE. A number of tests have been run showing the new event
      handler seems to work properly.</p>

    <p>I intend to do further testing and benchmarking to find the
      best default values to use for vfs.ufs.dirhash_reclaimage (the
      number of seconds a dirhash can sit unused before the dirhash
      low memeory event handler will unconditionally delete it) and
      the minimum percentage of memory that will be freed upon
      vm_lowmem events even if there are not enough hashes older than
      dirhash_reclaimage (currently this is hard coded to 10%). I
      would also like to add some code to choose a reasonable new
      default vfs.ufs.dirhash_maxmem value based upon the amount of
      memory in the system, set automatically at boot time and tunable
      via sysctl. Once these tweaks have been made I plan to ask for
      testing from more users to shake out any bugs or potential
      workloads where the new code may hurt overall performance.</p>

    <p>Current details about status are on the <a
	href="http://wiki.freebsd.org/DirhashDynamicMemory">wiki</a>.</p>
  </li>

  <li>
    <strong>Project:</strong> Reference implementation of the SNTP client<br>
    <strong>Student:</strong> Johannes Maximilian Kohn<br>
    <strong>Mentor:</strong> Harlan Stenn<br>

    <strong>Summary:</strong>

    <p>A reference implementation of the SNTP client based on the
      latest ntpv4 document. SNTP is a lightweight client that enables
      admins to synchronize with NTP servers. SNTP's networking code
      is written protocol independent and should work with almost any
      protocol like IPv4 or IPv6. SNTP supports MD5 authentication to
      verify the authenticity of the queried server.</p>

    <strong>Ready to enter CVS/SVN:</strong> Not determined yet.
  </li>

  <li>
    <strong>Project:</strong> NFSv4 ACLs<br>
    <strong>Student:</strong> Edward Tomasz Napierala<br>
    <strong>Mentor:</strong> &a.rwatson;<br>

    <strong>Summary:</strong>

    <p>The aim of my GSoC project was to implement NFSv4 ACLs in a
      similar way POSIX.1e ACLs are supported. That was done by
      extending user utilities (setfacl(1)/getfacl(1)), libc API and
      adding necessary kernel stuff, for ACL storage and enforcement
      on both UFS and ZFS. Regression tests were implemented to ensure
      correct operation. Semantics is supposed to be identical to the
      one in SunOS. There is also a wrapper (distributed separately)
      that implements SunOS-compatible acl(2)/facl(2) API, to make
      porting applications like Samba easier.</p>

    <strong>Ready to enter CVS/SVN:</strong> not yet
  </li>

  <li>
    <strong>Project:</strong> Enhancing FreeBSD's Libarchive<br>
    <strong>Student:</strong> Anselm Strauss<br>
    <strong>Mentor:</strong> &a.kientzle;<br>

    <strong>Summary:</strong>

    <p>The idea was to work on some missing parts of
      Libarchive. Despite the many goals, only few of them could be
      implemented. So far the project contributed a ZIP writer with
      tests. It supports basic functionality, except compression,
      ZIP64 and some fancy features of the ZIP specification. Work
      will now continue free from GSOC. It will include finishing the
      ZIP writer, and working a bit on the other goals, like PAX
      frontend, and others.</p>

    <strong>Ready to enter CVS/SVN:</strong> not yet
  </li>

  <li>
    <strong>Project:</strong> Allowing for parallel builds in the FreeBSD Ports<br>
Collection
    <strong>Student:</strong> David Forsythe<br>
    <strong>Mentor:</strong> Mark Linimon<br>

    <strong>Summary:</strong>

    <p>This project added locks to targets taken from bsd.port.mk that
      could perform conflicting operations if multiple builds were
      running at the same time. First, fake-pkg was modified to obtain
      a lock over PKG_DBDIR to prevent clobbering of the database in
      case more than one port tries to register at a time. Next, a
      lock called BASE_LOCK was added for every port to obtain at the
      beginning of a build. This lock is located in a ports directory,
      and prevents any port from being built by multiple make
      processes. Locks were then added for other sensitive targets,
      and the pkg_install tools were modified to honor locks on
      PKG_DBDIR.</p>

    <p>Once these locks were added, a new variable, FAKE_J, to take
      advantage of makes -j flag. This allows make to fork multiple
      processes to handle dependencies and fetching, without passing
      the -j flag onto the actual build of a port.</p>

    <strong>Ready to enter CVS/SVN:</strong> Probably not.
  </li>

  <li>
    <strong>Project:</strong> Ports license auditing infrastructure<br>
    <strong>Student:</strong> Alejandro Pulver<br>
    <strong>Mentor:</strong> &a.brooks;<br>

    <strong>Summary:</strong>

    <p>This project is about adding license support to the Ports
      Collection, so ports with certain licenses can be
      identified. The ports makefile part is functional (may need some
      adjustments though): definition of licenses by port, notions of
      permissions (sell and redistribute, for distfiles and packages)
      replacing NO_{PACKAGE,CDROM} and RESTRICTED, configuration
      (one-time, and saved; with checksum in case the license
      changes), verbose/diagnostic output of the internal processing
      logic (how it is accepted or rejected, if by the user, by
      default or by saved configuration), registration of license
      information and license itself in the package (so that both
      packages and ports can be searched for properties such as
      license types or restrictions), and more can be easily added to
      the current code.</p>

    <p>The license database (a list of them and their properties) was
      going to be mirrored from FOSSology: a tool to analyze software
      licenses. We are working on getting FOSSology to automatically
      classify ports (I've sent suggestions and patches to the
      developers, who accepted them and provided very good
      support). So for the moment it is not usable (at least
      licenses/properties are defined manually, and each port is
      marked manually to indicate its license).</p>

    <p>I will continue working on the FOSSology's port, and on the
      missing features such as multiple licenses support (AND, OR,
      etc). For more information see the wiki page: Ports license
      auditing infrastructure</p>

    <strong>Ready to enter CVS/SVN:</strong> not yet
  </li>

  <li>
    <strong>Project:</strong> Improving layer2 filtering<br>
    <strong>Student:</strong> Gleb Kurtsou<br>
    <strong>Mentor:</strong> Andrew Thompson<br>

    <strong>Summary:</strong>

    <p>Project aimed to improve layer2 filtering in ipfw and pf. All
      of the project goals are achieved: pfil framework is extended to
      handle ethernet packets, ipfw layer2 filtering is greatly
      simplified, added l2filter and l2tag per interface flags. Both
      ipfw and pf firewalls support filtering by ethernet addresses,
      support stateful filtering with ethernet addresses and
      firewall's lookup tables are extended to contain ethernet
      addresses.</p>

    <p>ipfw was extended to perform arp packet filtering: arp-op,
      src-arp and dst-arp options added.</p>

    <p>Details and usage examples are on my
      <a href="http://blogs.freebsdish.org/gleb/">blog</a>.</p>

    <strong>Ready to enter CVS/SVN:</strong> Not yet, diff is submitted to freebsd-net@
    for public review.
  </li>

  <li>
    <strong>Project:</strong> Porting FreeBSD to Efika (PPC bring up)<br>
    <strong>Student:</strong> Przemek Witaszczyk (vi0@)<br>
    <strong>Mentor:</strong> &a.raj;<br>

    <strong>Summary:</strong>

    <p>The main aim of the project is to port FreeBSD operating system
      to MPC5200B evaluation board. Among subleading tasks, there were
      objectives such as making kernel proceed to device drivers
      initialization, modelling newbus hierarchy of devices, writing
      the programmable interrupt controller driver, writing the PCI
      driver. The ultimate goal is reaching multiuser mode.</p>

    <p>As for now, half of the project is realized. After solving a
      few difficult problems at the basic level (binary interface
      issues with entry point to the SmartFirmware on the device), the
      boot procedure reaches the device drivers initialization stage,
      and hits the PIC driver init. At this point, the driver skeleton
      is constructed and is called. The driver uses ofwbus bus driver
      which intermediates between the openfirmware and the FreeBSD
      newbus devices hierarchy. After completing the PIC driver, I'll
      be in the position to write the remaining drivers for
      peripherals integrated on the MPC5200B chip using the newbus
      architecture.</p>

    <p>I am determined to continue the work on the project after the
      formal GSoC end date in order to bring at least the interrupt
      controller driver to operation.</p>

    <p>More info available at project's wiki :
      http://wiki.freebsd.org/PrzemekWitaszczyk and at my GSoC 2008
      blog: http://bitbay.blogspot.com/</p>

    <strong>Ready to enter CVS/SVN:</strong> not yet, at least PIC driver required.
  </li>

  <li>
    <strong>Project:</strong> Audit Firewall Events from Kernel<br>
    <strong>Student:</strong> Diego Giagio (diego@)<br>
    <strong>Mentor:</strong> &a.csjp;<bR>

    <strong>Summary:</strong>

    <p>This project is part of TrustedBSD project and aims to provide
      auditing support to security-related events generated by various
      firewall implementations on FreeBSD such as IPFW, PF and
      IPFILTER.</p>

    <p>Currently both administrative events (such as add/remove rules)
      and network events (such as network connection establishment)
      are being audited on IPFW. This means that all IPFW
      security-related events are already being audited the way we
      planned it to. Although PF and IPFILTER auditing support aren't
      yet finished, all the hard infrastructure work needed to
      implement that is already committed.</p>

    <p>The next step is basically finish implementing PF and
      IPFILTER's auditing support. On the IPFW side, my research
      showed that the way it handles stateful connections (even
      before my work) needs improvement. I will also work on this. I
      will keep working on this project in order to polish every rough
      edge we might find. Once this is finished, I'll probably begin
      working on other interesting TrustedBSD projects.</p>

    <p>More information can be found here:
      http://wiki.freebsd.org/DiegoGiagio/Audit_Firewall_Events_from_Kernel</p>

    <strong>Ready to enter CVS/SVN:</strong> Not determined yet, perhaps parts of it.
  </li>

  <li>
    <strong>Project:</strong> Create a tiny operating system from FreeBSD<br>
    <strong>Student:</strong> James Harrison<br>
    <strong>Mentor:</strong> &a.imp;<br>

    <strong>Summary:</strong>

    <p>This project was a success and a failure at the same time. I
      started work imagining that I would be creating, genuinely
      creating, a new tiny operating system from FreeBSD. This was to
      be a worthy goal, a challenging goal, and overall a fun goal. I
      imagined it would involve making a bunch of shell scripts for
      stripping out various parts of the OS, integrate a custom
      kernel, and bob's your mother's brother, everything's done. This
      was even reflected in the name of the project; it's the same
      approach as TinyBSD, so I called mine ShinyBSD as a kind of
      homage.</p>

    <p>Instead, I gained respect for TinyBSD, which is a fantastic
      tool. A truly, truly, fantastic tool. Ultimately, with just a
      few tweaks, it could do exactly what I needed it to do; building
      a small OS has been completed for some time.</p>

    <p>The second portion was to cross compile and boot an arm
      device. I had more hardware issues than you can shake a large
      stick at, so though I can verify that I was working hard on
      cross compiling, I cannot verify that the cross compiled product
      I had made sense as a bootable image. I've started configuring
      qemu now to see if I can verify via that. In discussion with my
      mentor, I believe a profitable method of applying my knowledge
      post-GSOC is to get a Makefile prepared for TinyBSD that cross
      compiles out of the box.</p>

    <strong>Ready to enter CVS/SVN:</strong> Not yet, though when the Makefile is complete
    it would be good to offer it up for inclusion in base.
  </li>
</ul>

<a name="press"></a>
<h2>FreeBSD Summer of Code Links</h2>

<ul>
  <li><a href="http://wiki.freebsd.org/moin.cgi/SummerOfCode2008">FreeBSD
  Summer of Code 2008 Wiki</a> - with links to student project
  pages.</li>
  <li><a href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2008/">Perforce
  Directory for 2008 Projects</a>.</li>
</ul>

&footer;
</body>
</html>
