1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
This is "Linpicker", a Linux version of Nitpicker.
As much code as possible was copied from the Nitpicker implementation,
so the same license (GNU GPL) applies.
Phil Dollery came up with the name "Linpicker"; David A. Wheeler
confirmed on Apr 20, 2007 that Google found no hits for the name.
Nitpicker's original implementation is deeply married to L4; trying to get its
incredibly baroque build environment and tools (esp. the DICE CORBA compiler)
working took enormous amounts of time, even with the start of a Linux
implementation. That start turned out to be painful; it presumed that
UDP packets are never dropped (but they are!), that UDP port numbers have
same properties as local thread ids (but they don't!), and so on.
It was also deeply unsuitable for real security; Nitpicker itself was small,
but all the code it deeply depended on turned out to be a massive
infrastructure that "had" to come with it. Not only would that be hard
to validate for security - it was clear that it was NOT secure (against
buffer overflows, denial-of-service attacks, and so on).
Nitpicker's DICE compiler was particularly troublesome; it generated code
that was unsuitable, so you ended up having to edit generated (code).
DICE is specifically designed to be an "IDL kernel for L4 micro-kernels",
as it clearly states on its web page... woe to those who don't use L4.
In theory you could modify DICE, but DICE was absurdly complex (an example
of how with enough method calls you can obscure any functionality).
The build environment depended on virtual paths, which ONLY make could see...
so all other tools (e.g., ctags, grep, etc.) were nearly useless,
since any search would find multiple instances of files.
So this re-implements Nitpicker, but with the KISS notion.
SIMPLICITY is the goal here, with small amounts of code.
Currently this implementation uses the CORBA implementation ORBit2,
because this is a well-supported implementation. The original Nitpicker
depended on a CORBA interface, so this simplifies transition.
The plan is to port to Linux using ORBit, and then separately replace
the comm structure to use Xen directly.
We must port to Xen (on grant tables, etc.), and nearly all CORBA functionality
is unneeded, so eventually a tiny comm structure that we can directly
control will be helpful. The issue is that we want to know EXACTLY
what the code does, and limit its size, so that we can be confident of
its security. The eventual system need not be CORBA (or DCE) compliant, see
"The Rise and Fall of CORBA" by Michi Henning, ZeroC.
The comm structure will have the goals of:
* Very simple tool implementation
* Very simple resulting code (easily examined)
* Robust against malicious clients: clients may drop partway through,
send excessive or insufficient data, or send "wrong" messages.
The code uses the "directfb" library, a library that simplifies access
to the underlying framebuffer. In particular, this means that we don't
have to write code for drawing lines, characters, doing blits, etc.
This library also supports 2D hardware acceleration, which is a nice plus.
For this library to work, the underlying
kernel must provide framebuffer access via /dev/fb. On Linux,
this means that kernel level frame buffer driver must be loaded.
You can use a driver specific your graphics card that supports framebuffer
access. If one is not available, you can use the svga (vesa) framebuffer
driver, which supports the application framebuffer interface by
using the widely-supported vesa interface to the graphics card.
In order to load the svga (vesa) frame buffer you must load it in
at kernel boot time. For GRUB users, this means modifying grub.conf
by adding the following line to the boot kernel (change the kernel id
to yours):
kernel /vmlinuz-2.6.22.9-61.fc6 ro root=LABEL=/1 video=vesafb:ywrap,mtrr vga=788
This fb driver is only activated at boot time and the settings cannot be
changed using fbset.
You can also try loading a card-specific module as root
if you know your card's maker.
|
