=>  Releases

Stable: 1.3.7
for kernels:

  • 2.4.36
  • 2.6.23.14

Devel 1.4: 1.4.0-rc3
for kernels:

  • 2.4.36.9
  • 2.6.27.5

Full RSBAC kernels
Lazy of patching ? Get the already rsbac-patched kernel. Choose your flavor.

Classic kernels
Includes vanilla kernel with the RSBAC patch

  • 2.6.23.14
  • 2.4.35.3

Enhanced kernels
Kernels including latest security fixes, goodies, and of course PaX+RSBAC

  • 2.6.23.15 (20080217)
  • 2.4.36 (20080217)

Debian repository
Also works for Ubuntu and other Debian-based distributions, of course

SVN
Cutting edge RSBAC source code, can be unstable sometimes

=>  Events

No events planned

2.4.18-UP-RSBAC-v1.2.0-pre6-Celeron-333-256MB

These Linux kernel compile benchmarks have been run on an Celeron-333 UP system with kernel 2.4.18 and RSBAC version 1.2.0-pre6. Three runs each of ‘make clean && time make bzImage’ on the same plain 2.4.18 kernel source tree in single user mode after one untimed run produced the following average times in seconds:

Kernel type Total time Kernel/Sys + User Kernel/Sys time User/Process time
Clean kernel 734.53 734.53 34.81 699.72
Maint kernel (no modules) 738.28 (+0.51%) 738.28 (+0.51%) 37.49 (+7.70%) 700.79 (+0.15%)
RC + AUTH, network support, no other options 747.52 (+1.77%) 747.52 (+1.77%) 43.59 (+25.22%) 703.93 (+0.60%)
AUTH + ACL, network support, no other options 749.28 (+2.01%) 749.28 (+2.01%) 47.34 (+36.00%) 701.94 (+0.32%)
Default config: REG, FF, AUTH, RC, ACL, CAP, network support, full log settings, but nothing logged 767.76 (+4.52%) 767.76 (+4.52%) 65.57 (+88.37%) 702.19 (+0.35%)
All options and models, except MS 813.44 (+10.74%) 813.44 (+10.74%) 104.53 (+200.28%) 708.91 (+1.31%)
Full MS, no other options 747.49 (+1.76%) 747.49 (+1.76%) 44.22 (+27.03%) 703.27 (+0.51%)

The significant kernel time increase with more models, compared to the previous v1.1.2 benchmark, is probably related to the distribution of attributes over separate lists for each module, which results in more list lookups. Also, the RC changes from fixed size role and type arrays to lists slow this model down a bit.

In larger setups, the list separation should result in much shorter lists and thus speed things up again. You can see this and the internal list optimizations in the much better MS results, where large lists of scanning results are generated.

 

documentation/benchmarks/2.4.18.txt · Last modified: 2006/05/02 15:40
This website is kindly hosted by m-privacy