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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
|
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/xml/statusreport.dtd">
<!-- $FreeBSD$ -->
<report>
<date>
<month>October-December</month>
<year>2003</year>
</date>
<section>
<title>Introduction:</title>
<p>The FreeBSD status reports are back again with the 2003 year-end
edition. Many new projects are starting up and gaining momentum,
including XFS, MIPS, PowerPC, and networking locking and
multithreading. The end of 2003 also saw the release of FreeBSD 4.9,
the first stable release to have greater than 4GB support for the
ia32 platform. Work on FreeBSD 5.2 also finished up and was released
early in January of 2004. Many thanks to all of the people who
worked so hard on these releases and made them happen.</p>
<p>This is the largest status report ever, so read and enjoy!</p>
<p>Scott Long, Robert Watson</p>
</section>
<project>
<title>libarchive, bsdtar</title>
<contact>
<person>
<name>
<given>Tim</given>
<common>Kientzle</common>
</name>
<email>kientzle@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~kientzle/libarchive/" />
</links>
<body>
<p>The libarchive library, which reads and writes tar and cpio
archives, is about ready to commit to the tree. The bsdtar
program, built on libarchive, is also nearing completion and
should soon be a worthwhile successor to our aging GNU tar. I
plan a gradual transition during which "bsdtar" and "gtar" will
coexist in the tree.</p>
<p>Oddly enough, libarchive and bsdtar are the first fruits of a
project to completely rewrite the pkg tools. I've started
architecting a libpkg library for handling routine package
management and have a prototype pkg_add that is three times faster
than the current version.</p>
</body>
</project>
<project>
<title>Publications Page Update</title>
<contact>
<person>
<name>
<given>Josef</given>
<common>El-Rayes</common>
</name>
<email>josef@daemon.li</email>
</person>
</contact>
<links>
<url href="http://www.daemon.li/freebsd/">Updated Publications Page</url>
</links>
<body>
<p>I did a xml/xslt conversion of the html files to make maintaining
of the page more comfortable. I removed the cdsets, which might be
kept in CVS or some kind of archive for historical reasons. The books
got an update, and were categorized in respect to the language they
are written in. As soon as I get my access on the cvs repository I
will commit the updates. People are encouraged to add local FreeBSD
books, I missed, especially in the asian area. Feel free to send me
links to books to add.</p>
</body>
</project>
<project>
<title>DVB-ASI Support</title>
<contact>
<person>
<name>
<given>Vincent</given>
<common>Jardin</common>
</name>
<email>Vincent.Jardin@6wind.com</email>
</person>
</contact>
<links>
<url href="http://proxy.6wind.com/~jardin/dvb/">Home page and source code</url>
<url href="http://www.computermodules.com/broadcast/broadcast-dvb.shtml">Computer Modules</url>
<url href="http://www.dvb.org/"/>
</links>
<body>
<p>DVB ASI stands for Digital Video Broadcast - Asynchronous Serial
Interface. It is the standard defined to send and receive DVB stream
from Satellite (DVB-S), Terrestrial link (DVB-T), and TV Cable
(DVB-C). This standard was developed in Europe to transport 188-byte
MPEG cells and 204-byte MPEG cells. However it can be used to carry IP
over DVB too.</p>
<p>The FreeBSD driver uses the newbus amd the bus-dma API. It means that it
could be easily ported to all the BSD flavors (NetBSD, OpenBSD).</p>
<p>It uses the same API than the Linux DVB ASI support from
ComputerModules that is based on the following devices:
<ul>
<li>/dev/asitxN for the transmit stream (only open, write, select,
close and ioctl are supported)</li>
<li>/dev/asirxN for the receive stream (only open, read, select, close
and ioctl are supported)</li>
</ul>
It means that software such as Videolan that support DVB-ASI
broadcasting could be supported by this driver.</p>
<p>Special thanks to Tom Thorsteinson from Computer Modules who helped
6WIND to port their driver. It is used by 6WIND in order to provide
IPv4, IPv6, Ethernet and our network services over DVB.</p>
<p>Copyright 2003-2004, 6WIND</p>
</body>
</project>
<project>
<title>FreeBSD ports monitoring system</title>
<contact>
<person>
<name>
<given>Mark</given>
<common>Linimon</common>
</name>
<email>linimon_at_lonesome_dot_com</email>
</person>
</contact>
<links>
<url href="http://lonesome.dyndns.org:4802/bento/errorlogs/index.html">FreeBSD
ports monitoring system</url>
</links>
<body>
<p>Enhancements continue to be made to the system. Several,
including improvements to the PR classification algorithm, the
ability to more correctly guess when a PR has been updated, and
better handling of errors in both port Makefiles and the bento
builds, are invisible to end-users. However, the addition of
a "repocopy" classification is notable, as is the allowing the
wildcard search in "overview of one port" (thanks to edwin@ for
the shove in that direction.) Additionally, logic has been
added to identify the proposed category/portname of new ports,
with the goal being to quickly identify possible duplications
of effort. (Some SQL performance was sacrificed to this goal,
leading to some pages to load more slowly; this needs to be
fixed.)</p>
<p>The other work has been on an email back-end to allow the
occasional sending of email to maintainers. Two functions are
currently available: "remind maintainers of their ports that
are marked BROKEN", and "remind maintainers of PRs that they
may not have seen." A recent run of the former got generally
good response, especially as changing some cases of BROKEN to
IGNORE (PR ports/61090) had removed almost all the annoying
false positives. However, work remains to try to find out why
a few allegedly broken ports only fail in certain environments
(including the bento cluster).</p>
<p>The next plan is to use the proposed DEPRECATED Makevar (see
ports/59362) to create a new report to allow querying of "ports
currently slated to be removed". This report could also be
posted to ports@ periodically with minimal work. The author
believes that doing this would allow the port deprecation process
to be much more visible to the general FreeBSD user community.</p>
</body>
</project>
<project>
<title>Compile FreeBSD with Intels C compiler (icc)</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Leidinger</common>
</name>
<email>netchild@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.Leidinger.net/FreeBSD/">Some patches</url>
</links>
<body>
<p>The FreeBSD kernel now builds and runs fine with icc v7 (only GENERIC
and a custom kernel tested so far). A review on arch@ revealed no
major concerns and some src committers are willing to commit the
patches. As icc v8 is out and defines __GNUC__ I want to rework the
patches before they get committed so an icc v8 compiled kernel DTRT
too.</p>
<p>A complete build of the ports collection (as of start of December)
finished and is under review to determine the reason of build
failures. Current <emph>icc</emph> stats:
<ul>
<li>1108 failed builds (excluding build failures because of failed
dependencies)</li>
<li>3535 successfully build packages (~ 1.7 GB)</li>
</ul>
A parallel build with <emph>gcc</emph> on the same snapshot of the
ports collection has:
<ul>
<li>520 failed builds (excluding build failures because of failed
dependencies)</li>
<li>7261 successfully build packages (~ 4.8 GB)</li>
</ul>
</p>
<p>The above mentioned build of the ports collection was run on a P4
with a icc compiled kernel (optimized for a P4). No kernel panics or
other strange behavior was noticed. The ports collection was build
with a CPUTYPE of p4 and CFLAGS set to "-Os -pipe -mfpmath=sse -msse2"
in the gcc and "-O2" in the icc case. No package is tested for correct
run-time behavior so far.</p>
</body>
</project>
<project>
<title>Porting OpenBSD's pf</title>
<contact>
<person>
<name>
<given>Max</given>
<common>Laier</common>
</name>
<email>max@love2party.net</email>
</person>
<person>
<name>
<given>Pyun</given>
<common>YongHyeon</common>
</name>
<email>yongari@kt-is.co.kr</email>
</person>
</contact>
<links>
<url href="http://pf4freebsd.love2party.net" />
<url href="http://www.benzedrine.cx/pf.html">PF homepage</url>
<url href="http://openbsd.org/faq/pf/index.html">PF FAQ</url>
</links>
<body>
<p>Much work has been invested into getting release 2.00 stable. It
provides the complete OpenBSD 3.4 function set, as well as fine
grained locking to work with a giant free network stack.</p>
<p>pf provides: IPv6 filtering and normalization, "syn-proxy"
to protect (web)server against SYN-floods, passive OS detection, fast
and modular address tables, source/policy routing, stateful filter and
normalization engine, structured rulesets via anchors and many many
more. Especially in connection with ALTQ, pf can help to harden
against various flood attacks and improve user experience.</p>
<p>New features from OpenBSD-Current like: state synchronization over wire
and enhanced support for cloned interfaces require patches to the
kernel. We are trying to resolve this issue and start
OpenBSD-Current tracking again as soon as possible.</p>
</body>
</project>
<project>
<title>Binary security updates for FreeBSD</title>
<contact>
<person>
<name>
<given>Colin</given>
<common>Percival</common>
</name>
<email>cperciva@daemonology.net</email>
</person>
</contact>
<links>
<url href="http://www.daemonology.net/freebsd-update/" />
</links>
<body>
<p>Thanks to recent donations, I am now building binary security
updates for FreeBSD {4.7, 4.8, 4.9, 5.0, 5.1, 5.2}-RELEASE.
(Note that FreeBSD 4.7 and 5.0 are no longer officially
supported; any advisories which are not reflected in the CVS
tree will likewise not result in binary updates.)</p>
<p>The current version (1.5) of FreeBSD Update will warn about
locally modified files and will, by default, leave them
untouched; if a "distribution branch", (i.e. crypto, nocrypto,
krb4, or krb5) is specified, FreeBSD Update can be forced to
"update" files which have been compiled locally.</p>
<p>The only major issue remaining with FreeBSD Update is the
single-point-of-failure of the update building process; I
would like to resolve this in the future by having several
machines cross-verify and cross-sign, but this will require
a significant investment of time, and will probably have to
wait until I've finished writing my DPhil thesis.</p>
</body>
</project>
<project>
<title>SGI XFS port for FreeBSD</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Kabaev</common>
</name>
<email>kan@FreeBSD.org</email>
</person>
<person>
<name>
<given>Russell</given>
<common>Cattelan</common>
</name>
<email>cattelan@thebarn.com</email>
</person>
</contact>
<body>
<p>A project was started to revive a stalled effort to port SGI XFS
journaling filesystem to FreeBSD. The project is based on Linux
development sources from SGI and is currently being kept in a
private Perforce repository. The work is progressing slowly due
to lack of free time. At the moment we have XFS kernel module
which is capable of mounting XFS filesystems read-only, with a
panic or two happening infrequently, that need to be isolated and
fixed. Semi-working metadata updates with full transaction support
are there too, but will probably have to be rewritten to minimize
the amount of custom kernel changes required.</p>
<p>We seek volunteers to help with userland part of the port. Namely,
existing xfsprogs port needs to be cleaned up, incompletely ported
utilities brought into a working shape. xfs_dump/xfs_restore and
as much from xfstests suite as possible need to be ported too. We do
not need testers for now, so please to not ask for module sources
just yet.</p>
</body>
</project>
<project>
<title>
Bluetooth stack for FreeBSD (Netgraph implementation)
</title>
<contact>
<person>
<name>
<given>
Maksim
</given>
<common>
Yevmenkin
</common>
</name>
<email>m_evmenkin@yahoo.com</email>
</person>
</contact>
<body>
<p>Not much to report. Bluetooth code was integrated into the FreeBSD
source tree. Bluetooth kernel modules appear to be stable. I have
received few success stories from the users.</p>
<p>During last few months the efforts were to make Bluetooth code
more user friendly. Bluetooth Service Discovery Procotol daemon
sdpd was reimplemented under BSD-style license and committed. The
next step is to integrate existing Bluetooth utilities with SDP.</p>
<p>Thanks to Matt Peterson <matt at peterson dot org> I now have
Bluetooth keyboard and mouse for development. I'm currently
working on Bluetooth HID profile implementation.</p>
<p>Dave Sainty <dave at dtsp dot co dot nz> from NetBSD project
offered his help in porting Bluetooth stack to NetBSD.</p>
</body>
</project>
<project>
<title>Network interface naming changes</title>
<contact>
<person>
<name>
<given>Brooks</given>
<common>Davis</common>
</name>
<email>brooks@FreeBSD.org</email>
</person>
</contact>
<body>
<p>At the end of October, the if_name and if_unit members of struct
ifnet were replaced with if_xname from NetBSD and if_dname and
if_dunit. These represent the name of the interface and the
driver name and instance of the interface respectively. Other then
breaking IPFilter for a few weeks due to the userland being on the
vendor branch, this change went quite well. A few ports needed
minor changes, but otherwise nothing changed from the user
perspective.</p>
<p>The purpose of this change was the lay the groundwork for support
for network interface renaming and to allow the implementation of
more interesting pseudo interface cloning support. An example of
interesting cloning support would be using "ifconfig fxp0.20
create" to create and configure a vlan interface on fxp0 that
handled frames marked with the tag 20. Interface
renaming is being worked on in Perforce at the moment with a
working version expected for review soon. Support for enhanced
device cloning is still in the planing stage.</p>
</body>
</project>
<project>
<title>Kernel Tunables Documentation Project</title>
<contact>
<person>
<name>
<given>Tom</given>
<common>Rhodes</common>
</name>
<email>trhodes@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/cgi/query-pr.cgi?pr=docs/44034">The
problem report which kicked this project in action</url>
</links>
<body>
<p>FreeBSD has well over a few hundred tunables without
documentation. This project aims at designing an
automated process to rip all available tunables and generate
a manual page based on the selected kernel options.
The ideal implementation, however; would gather tunables
from the LINT kernels as well. This would provide a
default manual page for all supported architectures.
A simple tool has been forged from the various off-list
and on-list discussions and is waiting review from the
-doc team. Anyone interesting in reviewing my current
work is requested to get in contact with me.</p>
</body>
</project>
<project>
<title>jpman project</title>
<contact>
<person>
<name>
<given>Kazuo</given>
<common>Horikawa</common>
</name>
<email>horikawa@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.jp.FreeBSD.org/man-jp/">jpman project</url>
</links>
<body>
<p>We have been updating existing Japanese translations
of manual pages to meet the 5.2-RELEASE schedule.
Also, 22 new translations were complete during this period.</p>
</body>
</project>
<project>
<title>FreeBSD MIDI</title>
<contact>
<person>
<name>
<given>Mathew</given>
<common>Kanner</common>
</name>
<email>matk@FreeBSD.org</email>
</person>
</contact>
<body>
<p>This project aims to update the current MIDI implementation. We
are currently looking at removing the current code sometime in
February and importing the new version soon after. I'm currently
working on a kernel/timidity bridge for those without external
hardware.</p>
</body>
</project>
<project>
<title>The FreeBSD Russian Documentation Project</title>
<contact>
<person>
<name>
<given>Andrey</given>
<common>Zakhvatov</common>
</name>
<email>andy@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/ru/index.html">The FreeBSD Project [Russian]</url>
</links>
<body>
<p>The FreeBSD Russian Documentation Project aims to provide FreeBSD
Documentation translated to Russian. Already done: FAQ, Porters
Handbook, WWW (partially synched with English version), some
articles.</p>
<p>We working at Handbook (and more docs) translation and synchronization
with English versions and need more translators (or financial aid to
continue our work. If you can help, please, contact us at
ru-cvs-committers@FreeBSD.org.ua (or andy@FreeBSD.org).</p>
</body>
</project>
<project>
<title>KSE</title>
<contact>
<person>
<name>
<given>Daniel</given>
<common>Eischen</common>
</name>
<email>deischen@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The libkse library will shortly be renamed to libpthread and
be made the default thread library. This includes making the
GCC -pthread option link to -lpthread instead of libc_r and
changing PTHREAD_LIBS to -lpthread. David Xu has been working
on GDB support and has it working with the GDB currently in our
tree. The next step is to make a libpthread_db and get it working
with GDB 6.0 which marcel has imported into the perforce tree.</p>
</body>
</project>
<project>
<title>Donations Team</title>
<contact>
<person>
<name>
<given>Michael</given>
<common>Lucas</common>
</name>
<email>donations@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/donations/">FreeBSD Donations Project</url>
</links>
<body>
<p>2003 was quite successful for the Donations team. We
shepherded over 200 items from donors into the hands of
developers. Some high points include: a small cluster for the
security team, assorted laptop hardware for our cardbus work,
and documentation for our standards group. In the main FreeBSD.org
cluster we were able to replace 8 DEC Miata machines with 6
Alpha DS10s (21264). Every committer doing SMP work now has
multi-processor testing hardware.</p>
<p>We have smoothed out the tax deduction process with the FreeBSD
Foundation, and can ship donated items directly to the
recipients instead of tying up Foundation time handling
shipping.</p>
<p>Current team membership is: Michael Lucas, David O'Brien, and
Tom Rhodes. Wilko Bulte has replaced Robert Watson as the Core
Team representative.</p>
</body>
</project>
<project>
<title>ACPI</title>
<contact>
<person>
<name>
<given>Nate</given>
<common>Lawson</common>
</name>
<email>njl@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.root.org/~nate/freebsd/">ACPI TODO</url>
<url href="http://home.jp.FreeBSD.org/mail-list/acpi-jp/">ACPI-JP
Mailing List</url>
</links>
<body>
<p>The updated acpi_cpu driver was committed in November. Work is
ongoing to finish support for _CST re-evaluation, which makes it
possible for laptops based on processors like the Centrino to use
varying CPU idle states when on or off AC power. 5.2-RELEASE also
went out with support for _CID packages, which fixed mouse probing
for Compaq users. Control of CPU idle states and throttling can
now be done through rc.conf(5) settings for the /etc/power_profile
script, which switches between performance/economy levels when
the AC status changes.</p>
<p>One huge task underway is the cpufreq project, a framework for
detecting and controlling various frequency/voltage technologies
(SpeedStep, LongRun, ACPI Performance states, etc.) The ACPI
performance states driver is working and the framework is being
implemented. It requires newbus attachments for CPUs so some
ground work needs to go in before the driver can be committed.</p>
<p>ACPI-CA was updated to 20031203 in early December and with a few
patches is reasonably stable. An ACPI debugging how-to has been
written and is being DocBooked by trhodes@. Ongoing work on fixing
interrupt storms due to various ways of setting up the SCI
is being done by jhb@.</p>
<p>I'd like to welcome Philip Paeps (philip@) to the FreeBSD team.
Philip has written an ACPI ASUS driver that will be committed soon
and has been very helpful on the mailing lists. We've also had
a lot of help from jhb@, marcel@, imp@, and peter@. We're hoping
to see the return of takawata@ and iwasaki@, who have been very
helpful in the past.
If any developers are interested in assisting with ACPI, please
see the ACPI TODO and send us an email.</p>
</body>
</project>
<project>
<title>kgi4BSD Status Report</title>
<contact>
<person>
<name>
<given>Nicholas</given>
<common>Souchu</common>
</name>
<email>nsouch@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~nsouch/kgi4BSD" />
<url href="http://www.kgi-project.org" />
</links>
<body>
<p>Most of the console blocks are in place with nice results
(see screenshots on the site). Boot console and virtual
terminals are working with 8bit rendering and perfect integration
of true graphic drivers in the kernel.</p>
<p>Now it is time to bring it to end user and a precompiled R5.2 GENERIC
kernel is available for this (see the site news). In parallel,
after providing a last tarball/patch for R5.2, everything will
move to Perforce.</p>
<p>As always, volunteers are welcome. The task is huge but very
exciting.</p>
</body>
</project>
<project>
<title>FreeBSD/powerpc on PPCBug-based embedded boards</title>
<contact>
<person>
<name>
<given>Rafal</given>
<common>Jaworowski</common>
</name>
<email>rafal.jaworowski@motorola.com</email>
</person>
</contact>
<body>
<p>The direct objective is to make FreeBSD/powerpc work on Motorola
MCP750 and similar (single board computer that is compliant with
Compact PCI standard) Based on this work it would be easy to bring it
to other embedded systems.</p>
<p>1. loader(8): it is based on the existing loader for FreeBSD/powerpc
port but binding to OpenFirmware was removed and replaced with PPCBug
firmware binding. It only supports netbooting for the moment, so disk
(compact flash) support needs to be done one day. The loader is the
only piece that relies onPPCBug system calls - once the kernel starts
it doesn't need firmware support any longer.</p>
<p>2. kernel: it is now divorced from OpenFirmware dependencies; most of
the groundwork finished includes: nexus stuff is sorted out (resources
management is ok except interrupts assignment); host to PCI bridge low
level routines are finished so configuration of and access to PCI
devices works; the only important thing missing is the IRQ management
(Raven MPIC part is done, but the board has the second PIC,
8259-compatible that needs to be set up, but here the existing code
from x86 arch will be adopted).</p>
<p>Once the IRQ management is cleared out, most of the devices on board
would work straight away since they are pretty standard chips with
drivers already implemented in the tree (e.g. if_de).</p>
<p>At the moment work is on hold (don't have physical access to the
device) but will resume when I'm back home (late Feb).</p>
</body>
</project>
<project>
<title>TrustedBSD Mandatory Access Control (MAC)</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<given>TrustedBSD Discussion Mailing List</given>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.trustedbsd.org/mac.html">TrustedBSD MAC
page</url>
</links>
<body>
<p>The TrustedBSD Mandatory Access Control (MAC) Framework
permits the FreeBSD kernel and userspace access control
policies to be adapted at compile-time, boot-time, or
run-time. The MAC Framework provides common infrastructure
components, such as policy-agnostic labeling, making it
possible to easily development and distribute new access
control policy modules. Sample modules include Biba, MLS,
and Type Enforcement, as well as a variety of system
hardening policies.</p>
<p>TrustedBSD MAC development branch in Perforce integrated
to 5.2-RELEASE.</p>
<p>The TrustedBSD MAC Framework now enforces protections on System
V IPC objects and methods. Shared memory, semaphores, and
message queues are labeled, and most operations are controlled.
The Biba, MLS, Test, and Stub policies have been updated for
System V IPC. (Not yet merged)</p>
<p>The TrustedBSD MAC Framework now enforces protections on POSIX
semaphore objects and methods. The Biba, MLS, Test, and Stub
policies have been updated. (Not yet merged)</p>
<p>The TrustedBSD MAC Framework's central kernel implementation
previously existed in one large file, src/sys/kern/kern_mac.c.
It is now broken out into a series of by-service files in
src/sys/security/mac. src/sys/security/mac/mac_internal.h
specifies APIs, structures, and variables used internally
across the different parts of the framework. System calls
and registration still occur in kern_mac.c. This permits
more easy maintenance of locally added object types. (Merged)</p>
<p>Break out mac_policy_list into two different lists, one to
hold "static" policy modules -- ones loaded prior to kernel
initialization, and that may not be loaded, and one for
"dynamic" policy modules -- that are either loaded later in
boot, or may be unloaded. Perform less synchronization when
using static modules only, reducing overhead for entering
the framework when not using dynamic modules. (Merged)</p>
<p>Introduced a kernel option, MAC_STATIC, which permits only
statically registered policy modules to be loaded at boot
or compiled into the kernel. When running with MAC_STATIC,
no internal synchronization is required in the MAC Framework,
lowering the cost of MAC Framework entry points. (Not yet
merged)</p>
<p>Make mac.h userland API definition C++-happy. (Merged)</p>
<p>Created mac_support.4, a declaration of what kernel and
userspace features are (and aren't) supported with MAC.
(Not yet merged)</p>
<p>Stale SEBSD module deleted from MAC branch; SEBSD module will
solely be developed in the SEBSD branch from now on. See
the TrustedBSD SEBSD report for more detail.</p>
<p>Use only pointers to 'struct label' in various kernel objects
outside the MAC Framework, and use a zone allocator to allocate
label storage. This permits label structures to have their
size changed more easily without changing the normal kernel
ABI. This also lowers the non-MAC memory overhead for base
kernel structures. This also simplifies handling and storage
of labels in some of the edge cases where labels are exposed
outside of the Framework, such as in execve(). Include files
outside of the Framework are substantially simplified and now
frequently no longer require _label.h. (Merged)</p>
<p>Giant pushed down into the MAC Framework in a number of MAC
related system calls, as it is not required for almost all
of the MAC Framework. The exceptions are areas where the
Framework interacts with pieces of the kernel still covered
by MAC and relies on Giant to protect label storage in those
structures. However, even in those cases, we can push Giant
in quite a bit past label internalization/externalization/
storage allocation/deallocation. This substantially simplifies
file descriptor-based MAC label system calls. (Merged)</p>
<p>Remove unneeded mpo_destroy methods for Biba, LOMAC, and MLS
since they cannot be unloaded. (Merged)</p>
<p>Biba and MLS now use UMA zones for label allocation, which
improves storage efficiency and enhances performance. (Merged)</p>
<p>Bug fix for mac_prepare_type() to better support arbitrary
object label definitions in /etc/mac.conf. (Merged)</p>
<p>Labels added to 'struct inpcb', which represents TCP and UDP
connections at the network layer. These labels cache socket
labels at the application layer so that the labels may be
accessed without application layer socket locks. When a label
is changed on the socket, it is pushed down to the network
layer through additional entry points. Biba, MLS policies
updated to reflect this change. (Merged)</p>
<p>SO_PEERLABEL socket option fixed so that peer socket labels
may be retrieved. (Merged)</p>
<p>mac_get_fd() learns to retrieve local socket labels, providing
a simpler API than SO_LABEL with getsockopt(). mac_set_fd()
learns about local socket labels, providing a simpler API than
SO_LABEL with setsockopt(). This also improves the ABI by not
embedding a struct label in the socket option arguments, instead
using the copyin/copyout routine for labels used for other object
types. (Merged)</p>
<p>Some function names simplified relating to socket options.
(Merged)</p>
<p>Library call mac_get_peer() implemented in terms of getsockopt()
with SO_PEERLABEL to improve API/ABI for networked applications
that speak MAC. (Merged)</p>
<p>mac_create_cred() renamed to mac_cred_copy(), similar to other
label copying methods, allowing policies to implement all the
label copying method with a single function, if desired. This
also provides a better semantic match for the crdup() behavior.
(Merged)</p>
<p>Support "id -M", similar to Trusted IRIX. (Not yet merged)</p>
<p>TCP now uses the inpcb label when responding in timed wait,
avoiding reaching up to the socket layer for label information
in otherwise network-centric code.</p>
<p>Numerous bug fixes, including assertion fixes in the MAC
test policy relating to execution and relabeling. (Merged)</p>
</body>
</project>
<project>
<title>TrustedBSD Access Control Lists (ACLs)</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<given>TrustedBSD Discussion Mailing List</given>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.trustedbsd.org/components.html#acls">TrustedBSD
ACLs page</url>
</links>
<body>
<p>TrustedBSD Access Control Lists (ACLs) provide extended
discretionary access control support for the UFS and UFS2
file systems on FreeBSD. They implement POSIX.1e ACLs with
some extensions, and meet the Common Criteria CAPP
requirements. Most ACL-related work is complete, with
remaining tasks associated with userspace integration, third
party applications, and compatibility</p>
<p>Prototyped Solaris/Linux semantics for combining ACLs and
the umask: if an default ACL mask is defined, substitute that
mask for the umask, permitting ACLs to override umasks. (Not
merged)</p>
</body>
</project>
<project>
<title>TrustedBSD "Security-Enhanced BSD" -- FLASK/TE Port</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<given>TrustedBSD Discussion Mailing List</given>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/sebsd.html">TrustedBSD
SEBSD page</url>
</links>
<body>
<p>TrustedBSD "Security-Enhanced BSD" (SEBSD) is a port of NSA's
SELinux FLASK security architecture, Type Enforcement (TE)
policy engine and language, and sample policy to FreeBSD using
the TrustedBSD MAC Framework. SEBSD is available as a loadable
policy module for the MAC Framework, along with a set of
userspace extensions support security-extended labeling calls.
In most cases, existing MAC Framework functions provide the
necessary abstractions for SEBSD to plug in without SEBSD-specific
changes, but some extensions to the MAC Framework have been
required; these changes are developed in the SEBSD development
branch, then merged to the MAC branch as they mature, and then
to the FreeBSD development tree.</p>
<p>Unlike other MAC Framework policy modules, the SEBSD module
falls under the GPL, as it is derived from NSA's
implementation. However, the eventual goal is to support
plugging SEBSD into a base FreeBSD install without any
modifications to FreeBSD itself.</p>
<p>TrustedBSD SEBSD development branch in Perforce integrated
to 5.2-RELEASE. Other changes in the MAC branch, including
restructuring of MAC Framework files also integrated, and a
move to zone allocation for labels. See the TrustedBSD MAC
Framework report for more detail on these and other MAC
changes that also affect the SEBSD work.</p>
<p>FreeBSD PTY code modified so that the MAC Framework and SEBSD
module can create pty's with the label of the process trying
to access them. Improves compatibility with the SELinux
sample policy. (Not yet merged)</p>
<p>SEBSD now loads its initial policy in the boot loader rather
than using a dummy policy until the root file system is
mounted, and then loading it using VFS operations. This
avoids initial labeling and access control conditions during
the boot.</p>
<p>security_load_policy() now passes a memory buffer and length
to the kernel, permitting the policy reload mechanisms to
be shared between the early boot load and late reloads. The
kernel SEBSD code now no longer needs to perform direct file
I/O relating to reading the policy. checkpolicy now mmap's
the policy before making the system call.</p>
<p>SEBSD now enforces protections on System V IPC objects and
methods. Shared memory, semaphores, and message queues are
labeled, and most operations are controlled. The sample
policy has been updated.</p>
<p>The TrustedBSD MAC Framework now controls mount, umount, and
remount operations. A new MAC system call, mac_get_fs() can
be used to query the mountpoint label. lmount() system call
allows a mount label to be explicitly specified at mount
time. The SEBSD policy module has been updated to reflect
this functionality, and sample TE policy has been updated.
(Not yet merged)</p>
<p>SEBSD now enforces protections on POSIX semaphores; the sample
policy has been updated to demonstrate how to label and control
sempahores. This includes sample rules for PostgreSQL.</p>
<p>The SEBSD sample policy, policy syntax, and policy tools have
been updated to the SELinux code drop from August. Bmake these
pieces so we don't need gmake.</p>
<p>Provide file ioctl() MAC Framework entry point and SEBSD
implementation.</p>
<p>A large number of sample policy tweaks and fixes. The policy
has been updated to permit cron to operate properly. It has
been updated for FreeBSD 5.2 changes, including dynamically
linked root. Teach the sample policy about FreeBSD's sendmail
wrapper.</p>
<p>Adapt sysinstall and install process for SEBSD pieces. Teach
sysinstall, newfs, et al, about multilabel file systems, install
SEBSD sample policy pieces, build policy. Automatically load
the SEBSD module on first boot after install.</p>
<p>Allow "ls -Z" to print out labels without long format.</p>
</body>
</project>
<project>
<title>TrustedBSD Audit</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<given>TrustedBSD Audit Discussion List</given>
</name>
<email>trustedbsd-audit@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.trustedbsd.org/components.html#audit">TrustedBSD
Audit Page</url>
</links>
<body>
<p>The TrustedBSD Project is producing an implementation of CAPP
compliant Audit support for use with FreeBSD. Little progress
was made on this implementation between October and December
other than an update to the existing development tree. However,
in January, work began on porting the Darwin Audit
implementation to FreeBSD. Details on this work will appear in
the next report; more information is available on the TrustedBSD
audit discussion list. Perforce messages may be seen on the
trustedbsd-cvs mailing list.</p>
</body>
</project>
<project>
<title>TrustedBSD Documentation</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<given>TrustedBSD Discussion Mailing List</given>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/docs.html">TrustedBSD
Documentation Page</url>
</links>
<body>
<p>The TrustedBSD Project is implementing many new features
for the FreeBSD Project. It also provides documentation for
users, administrators, and developers.</p>
<p>mac_support.4 added -- documents TrustedBSD MAC Framework
feature compatibility. See also the MAC Framework report.</p>
<p>FreeBSD security architecture updated and corrections/additions
made.</p>
<p>A variety of documentation updates relating to API changes,
including the socket-related API changes in libc/mac(3).</p>
</body>
</project>
<project>
<title>FreeBSD/MIPS Status Report</title>
<contact>
<person>
<name>
<given>Juli</given>
<common>Mallett</common>
</name>
<email>jmallett@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/projects/mips/" />
</links>
<body>
<p>TLB support code and PMAP have come along nicely. GCC and related
have been kept up to date with the main tree. An evaluation board
from Broadcom was donated and initial work on that platform has been
occurring. Much old and obsolete code brought from NetBSD for
bootstrapping the effort has been cleaned up. The system has been
seen to get to the point of trying to initialize filesystems, but
there are still bugs even before that milestone.</p>
</body>
</project>
<project>
<title>AGP 3.0 Support</title>
<contact>
<person>
<name>
<given>John</given>
<common>Baldwin</common>
</name>
<email>jhb@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Simple support AGP 3.0 including support for AGP 8x mode was
added. The support is simple in that it still assumes only one
master and one target. The main gain is the ability to use AGP
8x with drm modules that support it.</p>
</body>
</project>
<project>
<title>Network Subsystem Locking and Performance</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The purpose of this project is to improve performance of the network
subsystem. A major part of this work is to complete the locking of
the networking subsystem so that it no longer depends on the "Giant
lock" for proper operation. Removing the use of Giant will improve
performance and permit multiple instances of the network stack to
operate concurrently on multiprocessor systems.</p>
<p>Locking of the network subsystem is largely complete. Network
drivers, middleware layers (e.g. ipfw, dummynet, bridge, etc.), the
routing tables, IPv4, NFS, and sockets are locked and operating
without the use of Giant. Much of this work was included in the 5.2
release, but not enabled by default. The remaining work (mostly
locking of the socket layer) will be committed to CVS as soon as we
can resolve how to handle "legacy protocols" (i.e. those protocols
that are not locked). The code can be obtained now from the Perforce
database. A variety of test and production systems have been running
this code for several months without any obvious issues.</p>
<p>Performance analysis and tuning is ongoing. Initial results indicate
SMP performance is already better than 4.x systems but UP performance
is still lagging (though improved over -current). The removal of Giant
from the network subsystem has reduced contention on Giant and
highlighted performance bottlenecks in other parts of the system.</p>
<p>This work was supported by the FreeBSD Foundation.</p>
</body>
</project>
<project>
<title>Wireless Networking Support</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Work to merge the NetBSD and MADWIFI code bases is almost complete.
This brings in new features and improves sharing which will enable
future development. Support was added for 802.1x client
authentication (using the open1x xsupplicant program) and for shared
key authentication (both client and AP) which improves interopability
with systems like OS X. The awi driver was updated to use the common
802.11 layer and the Atheros driver received extensive work to support
hardware multi-rate retry. Kismet now works with the
device-independent radiotap capture format. All of this work is still
in Perforce but should be committed to CVS soon. </p>
<p>Work has begun on full 802.1x and WPA support.</p>
</body>
</project>
<project>
<title>SMPng Status Report</title>
<contact>
<person>
<name>
<given>John</given>
<common>Baldwin</common>
</name>
<email>jhb@FreeBSD.org</email>
</person>
<person>
<email>smp@FreeBSD.org</email>
</person>
</contact>
<links/>
<body>
<p>Work is progressing on SMPng on several different fronts. Sam
Leffler and several other folks have been working on locking the
network stack as mentioned elsewhere in this update. Several
infrastructure improvements have been made in the past few months
as well.</p>
<p>The low-level interrupt code for the i386 architecture has been
redesigned to allow for a runtime selection between different types
of interrupt controllers. This work allows the Advanced Programmable
Interrupt Controllers (APICs) to be used instead of the AT 8259A PIC
without having to compile a separate kernel to do so. It also allows
the APIC to be used in a UP kernel as well as on a UP box. Together,
all these changes allow an SMP kernel to work on a UP box and thus
allowed SMP to be enabled in GENERIC as it already is on all of the
other supported architectures. This work also reworked the APIC
support to correctly route PCI interrupts when using an APIC to
service device interrupts. This work was also used to add SMP support
to the amd64 port.</p>
<p>A turnstile implementation was committed that implemented a queue
of threads blocked on a resource along with priority inheritance of
blocked threads to the owner of the resource. Turnstiles were then
used to replace the thread queue built into each mutex object which
shrunk the size of each mutex as well as reduced the use of the
sched_lock spin mutex.</p>
</body>
</project>
</report>
|
