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
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
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.
The graphic modes are NOT in the list which you get if you boot with
vga=ask and hit return. The mode you wish to use is derived from the
VESA mode number. Here are those VESA mode numbers:
| 640x480 800x600 1024x768 1280x1024
----+-------------------------------------
256 | 0x101 0x103 0x105 0x107
32k | 0x110 0x113 0x116 0x119
64k | 0x111 0x114 0x117 0x11A
16M | 0x112 0x115 0x118 0x11B
The video mode number of the Linux kernel is the VESA mode number plus
0x200.
Linux_kernel_mode_number = VESA_mode_number + 0x200
So the table for the Kernel mode numbers are:
| 640x480 800x600 1024x768 1280x1024
----+-------------------------------------
256 | 0x301 0x303 0x305 0x307
32k | 0x310 0x313 0x316 0x319
64k | 0x311 0x314 0x317 0x31A
16M | 0x312 0x315 0x318 0x31B
To enable one of those modes you have to specify "vga=ask" in the
lilo.conf file and rerun LILO. Then you can type in the desired
mode at the "vga=ask" prompt. For example if you like to use
1024x768x256 colors you have to say "305" at this prompt.
For this code use mode 312 so the vga number will be 312.
You can also try loading a card-specific module as root
if you know your card's maker.
====================
This depends on version 1.1 of directfb. directfb is easily installed
on a Fedora system using "yum install directfb", but at the time of this
writing, this directfb is too old.
To update to the latest version of directfb, follow these steps:
Remove directfb, if you have it installed:
sudo yum remove directfb # If previously installed by yum
Make sure you have these installed:
autoconf
autoconf213
You may want to install VNC development packages ahead-of-time, so it
can use them.
We will install in "/usr" instead of "/usr/local"; by default Fedora
systems don't look at all the right /usr/local directories.
# Download into a ~/directfb
cd ~
mkdir directfb
cd directfb/
git clone git://git.directfb.org/git/directfb/core/DirectFB.git
git clone git://git.directfb.org/git/directfb/extras/DirectFB-extra.git
# Compile and build DirectFB
cd DirectFB
aclocal -I ./m4
autoheader
libtoolize --automake
automake --copy --add-missing
# Lots of warnings
autoconf
./configure --prefix=/usr
make
su
make install
# control-D to leave su mode
cd .. # Done.
# Compile and install DirectFB-extras.
# Note: You MUST install "DirectFB" before trying to build and install
# the DirectFB-extras.
cd DirectFB-extra
# Note: NOT aclocal -I ./m4
# because there's no "m4" subdirectory. If you "mkdir -p m4" first,
# then you could use the same command sequence as above.
aclocal
autoheader
libtoolize --automake
automake --copy --add-missing
# Lots of warnings
autoconf
./configure --prefix=/usr
make
su
make install
# control-D to leave su mode
cd ..
|
