Browse Source

Plan 9 from Bell Labs 2004-08-03

David du Colombier 17 years ago
parent
commit
b20189097d

+ 28 - 29
dist/replica/_plan9.db

@@ -211,7 +211,7 @@
 386/bin/disk/prep - 775 sys sys 1085077037 95880
 386/bin/disk/sacfs - 775 sys sys 1020319075 79882
 386/bin/dossrv - 775 sys sys 1085077037 136028
-386/bin/du - 775 sys sys 1085077037 68337
+386/bin/du - 775 sys sys 1091416192 71534
 386/bin/echo - 775 sys sys 1085077038 55323
 386/bin/ed - 775 sys sys 1085077038 91066
 386/bin/eqn - 775 sys sys 1087442511 242933
@@ -3157,13 +3157,13 @@ sys/doc/8½/8½.ms - 664 sys sys 1020895859 31593
 sys/doc/8½/8½.ps - 664 sys sys 1020895860 797150
 sys/doc/8½/fig1.ps - 664 sys sys 1020895859 473747
 sys/doc/8½/mkfile - 664 sys sys 1020895860 215
-sys/doc/9.html - 664 sys sys 1019922805 87205
+sys/doc/9.html - 664 sys sys 1091459042 87309
 sys/doc/9.ms - 664 sys sys 953237044 84632
 sys/doc/9.ps - 664 sys sys 960837924 508340
-sys/doc/acid.html - 664 sys sys 1019922805 71930
+sys/doc/acid.html - 664 sys sys 1091459045 71723
 sys/doc/acid.ms - 664 sys sys 1015012437 64944
 sys/doc/acid.ps - 664 sys sys 1015012454 426359
-sys/doc/acidpaper.html - 664 sys sys 1019922806 46828
+sys/doc/acidpaper.html - 664 sys sys 1091459045 46880
 sys/doc/acidpaper.ms - 664 sys sys 952880777 44805
 sys/doc/acidpaper.ps - 664 sys sys 960837913 359639
 sys/doc/acme - 20000000775 sys sys 945616779 0
@@ -3175,23 +3175,23 @@ sys/doc/acme/acme.pdf - 664 sys sys 1020384351 117006
 sys/doc/acme/acme.ps - 664 sys sys 960837907 611301
 sys/doc/acme/bs - 664 sys sys 944959634 556
 sys/doc/acme/mkfile - 664 sys sys 961259926 304
-sys/doc/ape.html - 664 sys sys 1019922806 14176
+sys/doc/ape.html - 664 sys sys 1091459042 14415
 sys/doc/ape.ms - 664 sys sys 953344517 12595
 sys/doc/ape.ps - 664 sys sys 960837914 258779
-sys/doc/asm.html - 664 sys sys 1019922806 30830
+sys/doc/asm.html - 664 sys sys 1091459045 31098
 sys/doc/asm.ms - 664 sys sys 958247686 28542
 sys/doc/asm.ps - 664 sys sys 960837915 322051
-sys/doc/auth.html - 444 sys sys 1021580026 68719
+sys/doc/auth.html - 664 sys sys 1091459079 77445
 sys/doc/auth.ms - 664 sys sys 1021579975 66803
 sys/doc/auth.ps - 664 sys sys 1021579976 451672
 sys/doc/cleanps - 775 sys sys 961259933 184
 sys/doc/colophon.ps - 664 sys sys 960837922 214122
-sys/doc/comp.html - 664 sys sys 1019922807 41385
+sys/doc/comp.html - 664 sys sys 1091459046 42144
 sys/doc/comp.ms - 664 sys sys 954266992 37792
 sys/doc/comp.ps - 664 sys sys 960837915 345786
-sys/doc/compiler.html - 664 sys sys 1019922807 31977
+sys/doc/compiler.html - 664 sys sys 1091459044 32960
 sys/doc/compiler.ms - 664 sys sys 1067721142 30279
-sys/doc/compiler.ps - 664 sys sys 960837916 308797
+sys/doc/compiler.ps - 664 sys sys 1091459054 309735
 sys/doc/contents.ms - 664 sys sys 1019916701 4920
 sys/doc/contents.ps - 664 sys sys 1019916845 232629
 sys/doc/docfonts - 664 sys sys 1038117516 208
@@ -3226,23 +3226,23 @@ sys/doc/il/transition.pic - 664 sys sys 944959591 11912
 sys/doc/il/xx - 664 sys sys 944959591 48924
 sys/doc/index.htm - 664 sys sys 1019916696 6906
 sys/doc/index.html - 664 sys sys 1020082751 6906
-sys/doc/lexnames.html - 664 sys sys 1019922807 37017
+sys/doc/lexnames.html - 664 sys sys 1091459043 37261
 sys/doc/lexnames.ms - 644 sys sys 954383595 34046
 sys/doc/lexnames.ps - 664 sys sys 960837909 335546
-sys/doc/libmach.html - 664 sys sys 1020485624 26336
+sys/doc/libmach.html - 664 sys sys 1091459044 26650
 sys/doc/libmach.ms - 664 sys sys 1021579974 24145
 sys/doc/libmach.ps - 664 sys sys 960837916 291283
-sys/doc/lp.html - 664 sys sys 1019922808 21194
+sys/doc/lp.html - 664 sys sys 1091459043 21721
 sys/doc/lp.ms - 664 sys sys 954614673 22366
 sys/doc/lp.ps - 664 sys sys 960837917 294399
-sys/doc/mk.html - 664 sys sys 1019922808 38398
+sys/doc/mk.html - 664 sys sys 1091459046 40021
 sys/doc/mk.ms - 664 sys sys 952880779 34413
 sys/doc/mk.ps - 664 sys sys 960837917 329779
-sys/doc/mkfile - 664 sys sys 1038117513 4265
-sys/doc/mkfiles.html - 664 sys sys 1019922808 17143
+sys/doc/mkfile - 664 sys sys 1091459055 4411
+sys/doc/mkfiles.html - 664 sys sys 1091459045 17750
 sys/doc/mkfiles.ms - 664 sys sys 952880779 17888
 sys/doc/mkfiles.ps - 664 sys sys 960837918 269496
-sys/doc/names.html - 664 sys sys 1019922809 23530
+sys/doc/names.html - 664 sys sys 1091459046 23529
 sys/doc/names.ms - 664 sys sys 954269607 22103
 sys/doc/names.ps - 664 sys sys 960837918 288716
 sys/doc/net - 20000000775 sys sys 954033300 0
@@ -3255,27 +3255,27 @@ sys/doc/net/tree - 664 sys sys 944959636 866
 sys/doc/net/tree.pout - 664 sys sys 944959636 1755
 sys/doc/network.art - 664 sys sys 944959651 2260
 sys/doc/network.pic - 664 sys sys 944959651 4124
-sys/doc/plumb.html - 664 sys sys 1019922809 55298
+sys/doc/plumb.html - 664 sys sys 1091459044 55783
 sys/doc/plumb.ms - 644 sys sys 954383596 53250
 sys/doc/plumb.ps - 664 sys sys 960837910 391830
-sys/doc/port.html - 664 sys sys 1019922809 16498
+sys/doc/port.html - 664 sys sys 1091459042 18123
 sys/doc/port.ms - 664 sys sys 1020111393 16694
 sys/doc/port.ps - 664 sys sys 1020111394 268901
 sys/doc/preamble - 644 sys sys 961259497 203475
 sys/doc/prfile - 775 sys sys 944959668 3782
-sys/doc/prog4.html - 664 sys sys 1019932831 18563
+sys/doc/prog4.html - 664 sys sys 1091459046 18653
 sys/doc/prog4.ms - 664 sys sys 1019932830 16485
 sys/doc/prog4.ps - 664 sys sys 1019932831 271581
 sys/doc/ps - 664 sys sys 944959649 1739
-sys/doc/rc.html - 664 sys sys 1019922810 39710
+sys/doc/rc.html - 664 sys sys 1091459044 41702
 sys/doc/rc.ms - 664 sys sys 1063856321 34373
 sys/doc/rc.ps - 664 sys sys 960837920 337955
 sys/doc/release3.html - 664 sys sys 1019922810 6329
 sys/doc/release3.ms - 664 sys sys 961261276 5492
 sys/doc/release3.ps - 664 sys sys 961261277 230682
-sys/doc/release4.html - 664 sys sys 1019922810 5869
+sys/doc/release4.html - 664 sys sys 1091459042 6473
 sys/doc/release4.ms - 664 sys sys 1063856338 5160
-sys/doc/release4.ps - 664 sys sys 1020100480 230580
+sys/doc/release4.ps - 664 sys sys 1091459052 230868
 sys/doc/sam - 20000000775 sys sys 945617037 0
 sys/doc/sam/fig1.bm - 464 sys sys 944959645 42200
 sys/doc/sam/fig1.ps - 664 sys sys 944959645 86336
@@ -3295,10 +3295,10 @@ sys/doc/sam/sam.ms - 464 sys sys 954266468 94536
 sys/doc/sam/sam.pdf - 664 sys sys 1020384352 156123
 sys/doc/sam/sam.ps - 664 sys sys 960837910 707546
 sys/doc/sam/sam.tut - 464 sys sys 944959644 40481
-sys/doc/sleep.html - 664 sys sys 1019922810 16618
+sys/doc/sleep.html - 664 sys sys 1091459043 16602
 sys/doc/sleep.ms - 664 sys sys 953237030 15206
 sys/doc/sleep.ps - 664 sys sys 960837920 263882
-sys/doc/spin.html - 664 sys sys 1019922811 73927
+sys/doc/spin.html - 664 sys sys 1091459042 75873
 sys/doc/spin.ms - 664 sys sys 953344522 67475
 sys/doc/spin.ps - 664 sys sys 960837923 443064
 sys/doc/title - 664 sys sys 1018974170 740
@@ -3306,8 +3306,8 @@ sys/doc/title.ps - 664 sys sys 1018974170 214289
 sys/doc/trademarks.ps - 664 sys sys 960837912 217896
 sys/doc/troff.html - 664 sys sys 1019922811 110932
 sys/doc/troff.ms - 664 sys sys 953237047 120683
-sys/doc/troff.ps - 664 sys sys 960837921 782310
-sys/doc/utf.html - 664 sys sys 1019922811 43855
+sys/doc/troff.ps - 664 sys sys 1091459051 782310
+sys/doc/utf.html - 664 sys sys 1091459044 43965
 sys/doc/utf.ms - 664 sys sys 952880781 41659
 sys/doc/utf.ps - 664 sys sys 960837922 363085
 sys/doc/venti - 20000000775 sys sys 1019852318 0
@@ -5369,7 +5369,7 @@ sys/src/9/pc/mp.h - 664 sys sys 1015014520 6575
 sys/src/9/pc/nv_dma.h - 664 sys sys 1081384508 12943
 sys/src/9/pc/pc - 664 sys sys 1079575705 1367
 sys/src/9/pc/pcauth - 664 sys sys 1073851852 657
-sys/src/9/pc/pccd - 664 sys sys 1055090302 1302
+sys/src/9/pc/pccd - 664 sys sys 1091458811 1408
 sys/src/9/pc/pccpu - 664 sys sys 1084475127 806
 sys/src/9/pc/pccpuf - 664 sys sys 1073851852 1315
 sys/src/9/pc/pcdisk - 664 sys sys 1073851851 1427
@@ -12335,4 +12335,3 @@ usr/glenda/lib/profile - 664 glenda glenda 1021580005 847
 usr/glenda/readme.acme - 664 glenda glenda 1019860628 4753
 usr/glenda/readme.rio - 664 glenda glenda 1019860628 6370
 usr/glenda/tmp - 20000000775 glenda glenda 1018802620 0
-386/bin/du - 775 sys sys 1091416192 71534

+ 27 - 27
dist/replica/plan9.db

@@ -3157,13 +3157,13 @@ sys/doc/8½/8½.ms - 664 sys sys 1020895859 31593
 sys/doc/8½/8½.ps - 664 sys sys 1020895860 797150
 sys/doc/8½/fig1.ps - 664 sys sys 1020895859 473747
 sys/doc/8½/mkfile - 664 sys sys 1020895860 215
-sys/doc/9.html - 664 sys sys 1019922805 87205
+sys/doc/9.html - 664 sys sys 1091459042 87309
 sys/doc/9.ms - 664 sys sys 953237044 84632
 sys/doc/9.ps - 664 sys sys 960837924 508340
-sys/doc/acid.html - 664 sys sys 1019922805 71930
+sys/doc/acid.html - 664 sys sys 1091459045 71723
 sys/doc/acid.ms - 664 sys sys 1015012437 64944
 sys/doc/acid.ps - 664 sys sys 1015012454 426359
-sys/doc/acidpaper.html - 664 sys sys 1019922806 46828
+sys/doc/acidpaper.html - 664 sys sys 1091459045 46880
 sys/doc/acidpaper.ms - 664 sys sys 952880777 44805
 sys/doc/acidpaper.ps - 664 sys sys 960837913 359639
 sys/doc/acme - 20000000775 sys sys 945616779 0
@@ -3175,23 +3175,23 @@ sys/doc/acme/acme.pdf - 664 sys sys 1020384351 117006
 sys/doc/acme/acme.ps - 664 sys sys 960837907 611301
 sys/doc/acme/bs - 664 sys sys 944959634 556
 sys/doc/acme/mkfile - 664 sys sys 961259926 304
-sys/doc/ape.html - 664 sys sys 1019922806 14176
+sys/doc/ape.html - 664 sys sys 1091459042 14415
 sys/doc/ape.ms - 664 sys sys 953344517 12595
 sys/doc/ape.ps - 664 sys sys 960837914 258779
-sys/doc/asm.html - 664 sys sys 1019922806 30830
+sys/doc/asm.html - 664 sys sys 1091459045 31098
 sys/doc/asm.ms - 664 sys sys 958247686 28542
 sys/doc/asm.ps - 664 sys sys 960837915 322051
-sys/doc/auth.html - 444 sys sys 1021580026 68719
+sys/doc/auth.html - 664 sys sys 1091459079 77445
 sys/doc/auth.ms - 664 sys sys 1021579975 66803
 sys/doc/auth.ps - 664 sys sys 1021579976 451672
 sys/doc/cleanps - 775 sys sys 961259933 184
 sys/doc/colophon.ps - 664 sys sys 960837922 214122
-sys/doc/comp.html - 664 sys sys 1019922807 41385
+sys/doc/comp.html - 664 sys sys 1091459046 42144
 sys/doc/comp.ms - 664 sys sys 954266992 37792
 sys/doc/comp.ps - 664 sys sys 960837915 345786
-sys/doc/compiler.html - 664 sys sys 1019922807 31977
+sys/doc/compiler.html - 664 sys sys 1091459044 32960
 sys/doc/compiler.ms - 664 sys sys 1067721142 30279
-sys/doc/compiler.ps - 664 sys sys 960837916 308797
+sys/doc/compiler.ps - 664 sys sys 1091459054 309735
 sys/doc/contents.ms - 664 sys sys 1019916701 4920
 sys/doc/contents.ps - 664 sys sys 1019916845 232629
 sys/doc/docfonts - 664 sys sys 1038117516 208
@@ -3226,23 +3226,23 @@ sys/doc/il/transition.pic - 664 sys sys 944959591 11912
 sys/doc/il/xx - 664 sys sys 944959591 48924
 sys/doc/index.htm - 664 sys sys 1019916696 6906
 sys/doc/index.html - 664 sys sys 1020082751 6906
-sys/doc/lexnames.html - 664 sys sys 1019922807 37017
+sys/doc/lexnames.html - 664 sys sys 1091459043 37261
 sys/doc/lexnames.ms - 644 sys sys 954383595 34046
 sys/doc/lexnames.ps - 664 sys sys 960837909 335546
-sys/doc/libmach.html - 664 sys sys 1020485624 26336
+sys/doc/libmach.html - 664 sys sys 1091459044 26650
 sys/doc/libmach.ms - 664 sys sys 1021579974 24145
 sys/doc/libmach.ps - 664 sys sys 960837916 291283
-sys/doc/lp.html - 664 sys sys 1019922808 21194
+sys/doc/lp.html - 664 sys sys 1091459043 21721
 sys/doc/lp.ms - 664 sys sys 954614673 22366
 sys/doc/lp.ps - 664 sys sys 960837917 294399
-sys/doc/mk.html - 664 sys sys 1019922808 38398
+sys/doc/mk.html - 664 sys sys 1091459046 40021
 sys/doc/mk.ms - 664 sys sys 952880779 34413
 sys/doc/mk.ps - 664 sys sys 960837917 329779
-sys/doc/mkfile - 664 sys sys 1038117513 4265
-sys/doc/mkfiles.html - 664 sys sys 1019922808 17143
+sys/doc/mkfile - 664 sys sys 1091459055 4411
+sys/doc/mkfiles.html - 664 sys sys 1091459045 17750
 sys/doc/mkfiles.ms - 664 sys sys 952880779 17888
 sys/doc/mkfiles.ps - 664 sys sys 960837918 269496
-sys/doc/names.html - 664 sys sys 1019922809 23530
+sys/doc/names.html - 664 sys sys 1091459046 23529
 sys/doc/names.ms - 664 sys sys 954269607 22103
 sys/doc/names.ps - 664 sys sys 960837918 288716
 sys/doc/net - 20000000775 sys sys 954033300 0
@@ -3255,27 +3255,27 @@ sys/doc/net/tree - 664 sys sys 944959636 866
 sys/doc/net/tree.pout - 664 sys sys 944959636 1755
 sys/doc/network.art - 664 sys sys 944959651 2260
 sys/doc/network.pic - 664 sys sys 944959651 4124
-sys/doc/plumb.html - 664 sys sys 1019922809 55298
+sys/doc/plumb.html - 664 sys sys 1091459044 55783
 sys/doc/plumb.ms - 644 sys sys 954383596 53250
 sys/doc/plumb.ps - 664 sys sys 960837910 391830
-sys/doc/port.html - 664 sys sys 1019922809 16498
+sys/doc/port.html - 664 sys sys 1091459042 18123
 sys/doc/port.ms - 664 sys sys 1020111393 16694
 sys/doc/port.ps - 664 sys sys 1020111394 268901
 sys/doc/preamble - 644 sys sys 961259497 203475
 sys/doc/prfile - 775 sys sys 944959668 3782
-sys/doc/prog4.html - 664 sys sys 1019932831 18563
+sys/doc/prog4.html - 664 sys sys 1091459046 18653
 sys/doc/prog4.ms - 664 sys sys 1019932830 16485
 sys/doc/prog4.ps - 664 sys sys 1019932831 271581
 sys/doc/ps - 664 sys sys 944959649 1739
-sys/doc/rc.html - 664 sys sys 1019922810 39710
+sys/doc/rc.html - 664 sys sys 1091459044 41702
 sys/doc/rc.ms - 664 sys sys 1063856321 34373
 sys/doc/rc.ps - 664 sys sys 960837920 337955
 sys/doc/release3.html - 664 sys sys 1019922810 6329
 sys/doc/release3.ms - 664 sys sys 961261276 5492
 sys/doc/release3.ps - 664 sys sys 961261277 230682
-sys/doc/release4.html - 664 sys sys 1019922810 5869
+sys/doc/release4.html - 664 sys sys 1091459042 6473
 sys/doc/release4.ms - 664 sys sys 1063856338 5160
-sys/doc/release4.ps - 664 sys sys 1020100480 230580
+sys/doc/release4.ps - 664 sys sys 1091459052 230868
 sys/doc/sam - 20000000775 sys sys 945617037 0
 sys/doc/sam/fig1.bm - 464 sys sys 944959645 42200
 sys/doc/sam/fig1.ps - 664 sys sys 944959645 86336
@@ -3295,10 +3295,10 @@ sys/doc/sam/sam.ms - 464 sys sys 954266468 94536
 sys/doc/sam/sam.pdf - 664 sys sys 1020384352 156123
 sys/doc/sam/sam.ps - 664 sys sys 960837910 707546
 sys/doc/sam/sam.tut - 464 sys sys 944959644 40481
-sys/doc/sleep.html - 664 sys sys 1019922810 16618
+sys/doc/sleep.html - 664 sys sys 1091459043 16602
 sys/doc/sleep.ms - 664 sys sys 953237030 15206
 sys/doc/sleep.ps - 664 sys sys 960837920 263882
-sys/doc/spin.html - 664 sys sys 1019922811 73927
+sys/doc/spin.html - 664 sys sys 1091459042 75873
 sys/doc/spin.ms - 664 sys sys 953344522 67475
 sys/doc/spin.ps - 664 sys sys 960837923 443064
 sys/doc/title - 664 sys sys 1018974170 740
@@ -3306,8 +3306,8 @@ sys/doc/title.ps - 664 sys sys 1018974170 214289
 sys/doc/trademarks.ps - 664 sys sys 960837912 217896
 sys/doc/troff.html - 664 sys sys 1019922811 110932
 sys/doc/troff.ms - 664 sys sys 953237047 120683
-sys/doc/troff.ps - 664 sys sys 960837921 782310
-sys/doc/utf.html - 664 sys sys 1019922811 43855
+sys/doc/troff.ps - 664 sys sys 1091459051 782310
+sys/doc/utf.html - 664 sys sys 1091459044 43965
 sys/doc/utf.ms - 664 sys sys 952880781 41659
 sys/doc/utf.ps - 664 sys sys 960837922 363085
 sys/doc/venti - 20000000775 sys sys 1019852318 0
@@ -5369,7 +5369,7 @@ sys/src/9/pc/mp.h - 664 sys sys 1015014520 6575
 sys/src/9/pc/nv_dma.h - 664 sys sys 1081384508 12943
 sys/src/9/pc/pc - 664 sys sys 1079575705 1367
 sys/src/9/pc/pcauth - 664 sys sys 1073851852 657
-sys/src/9/pc/pccd - 664 sys sys 1055090302 1302
+sys/src/9/pc/pccd - 664 sys sys 1091458811 1408
 sys/src/9/pc/pccpu - 664 sys sys 1084475127 806
 sys/src/9/pc/pccpuf - 664 sys sys 1073851852 1315
 sys/src/9/pc/pcdisk - 664 sys sys 1073851851 1427

+ 28 - 0
dist/replica/plan9.log

@@ -16399,3 +16399,31 @@
 1091332923 1 c 386/bin/usb/usbmouse - 775 sys sys 1091331846 137865
 1091379612 0 c sys/src/cmd/du.c - 664 sys sys 1091379562 3302
 1091417419 0 c 386/bin/du - 775 sys sys 1091416192 71534
+1091458827 0 c sys/src/9/pc/pccd - 664 sys sys 1091458811 1408
+1091460627 0 c sys/doc/9.html - 664 sys sys 1091459042 87309
+1091460627 1 c sys/doc/acid.html - 664 sys sys 1091459045 71723
+1091460627 2 c sys/doc/acidpaper.html - 664 sys sys 1091459045 46880
+1091460627 3 c sys/doc/ape.html - 664 sys sys 1091459042 14415
+1091460627 4 c sys/doc/asm.html - 664 sys sys 1091459045 31098
+1091460627 5 c sys/doc/auth.html - 664 sys sys 1091459079 77445
+1091460627 6 m sys/doc/auth.html - 664 sys sys 1091459079 77445
+1091460627 7 c sys/doc/comp.html - 664 sys sys 1091459046 42144
+1091460627 8 c sys/doc/compiler.html - 664 sys sys 1091459044 32960
+1091460627 9 c sys/doc/compiler.ps - 664 sys sys 1091459054 309735
+1091460627 10 c sys/doc/lexnames.html - 664 sys sys 1091459043 37261
+1091460627 11 c sys/doc/libmach.html - 664 sys sys 1091459044 26650
+1091460627 12 c sys/doc/lp.html - 664 sys sys 1091459043 21721
+1091460627 13 c sys/doc/mkfile - 664 sys sys 1091459055 4411
+1091460627 14 c sys/doc/release4.ps - 664 sys sys 1091459052 230868
+1091460627 15 c sys/doc/troff.ps - 664 sys sys 1091459051 782310
+1091460627 16 c sys/doc/mk.html - 664 sys sys 1091459046 40021
+1091460627 17 c sys/doc/mkfiles.html - 664 sys sys 1091459045 17750
+1091460627 18 c sys/doc/names.html - 664 sys sys 1091459046 23529
+1091460627 19 c sys/doc/plumb.html - 664 sys sys 1091459044 55783
+1091460627 20 c sys/doc/port.html - 664 sys sys 1091459042 18123
+1091460627 21 c sys/doc/prog4.html - 664 sys sys 1091459046 18653
+1091460627 22 c sys/doc/rc.html - 664 sys sys 1091459044 41702
+1091460627 23 c sys/doc/release4.html - 664 sys sys 1091459042 6473
+1091460627 24 c sys/doc/sleep.html - 664 sys sys 1091459043 16602
+1091460627 25 c sys/doc/spin.html - 664 sys sys 1091459042 75873
+1091460627 26 c sys/doc/utf.html - 664 sys sys 1091459044 43965

+ 16 - 17
sys/doc/9.html

@@ -167,7 +167,7 @@ servers to office- and home-resident workstations or PCs, called terminals
 in Plan 9 terminology.
 Figure 1 shows the arrangement.
 <DL><DT><DD><TT><PRE>
-<br><img src="network.pic.6030.gif"><br>
+<br><img src="network.pic.19237420.gif"><br>
 </PRE></TT></DL>
 </P>
 <DL>
@@ -1026,21 +1026,21 @@ a relative of
 <TT>make</TT>,
 reads the names of the current and target
 architectures from environment variables called
-<TT>$cputype</TT>
+<TT></TT><I>cputype</I>
 and
-<TT>$objtype</TT>.
+</TT><TT></TT><TT>objtype</TT>.
 By default the current processor is the target, but setting
-<TT>$objtype</TT>
+<TT></TT><I>objtype</I>
 to the name of another architecture
 before invoking
-<TT>mk</TT>
+</TT><TT>mk</TT>
 results in a cross-build:
 <DL><DT><DD><TT><PRE>
 % objtype=sparc mk
 </PRE></TT></DL>
 builds a program for the SPARC architecture regardless of the executing machine.
 The value of
-<TT>$objtype</TT>
+</TT><TT></TT><TT>objtype</TT>
 selects a
 file of architecture-dependent variable definitions
 that configures the build to use the appropriate compilers and loader.
@@ -1273,13 +1273,13 @@ of the Plan 9 name space.
 For instance, the directory
 <TT>/bin</TT>
 is built as a union of
-<TT>/$cputype/bin</TT>
+<TT>/</TT><I>cputype/bin</I>
 (program binaries),
-<TT>/rc/bin</TT>
+</TT><TT>/rc/bin</TT>
 (shell scripts),
 and perhaps more directories provided by the user.
 This construction makes the shell
-<TT>$PATH</TT>
+</TT><TT></TT><TT>PATH</TT>
 variable unnecessary.
 </P>
 <P>
@@ -1312,7 +1312,7 @@ necessary to have a notation that permits
 direct access to the devices without an existing name space.
 The root directory
 of the tree served by a device driver can be accessed using the syntax
-<TT>#</TT>&lt;I&gt;c&lt;/I&gt;,
+<TT>#</TT><I>c</I>,
 where
 <I>c</I>
 is a unique character (typically a letter) identifying the
@@ -2022,7 +2022,7 @@ and
 It also measures the time to send a byte on a pipe from one process
 to another and the throughput on a pipe between two processes.
 The results appear in Table 1.
-<br><img src="-.6031.gif"><br>
+<br><img src="-.19237421.gif"><br>
 Table 1.  Performance comparison.
 </P>
 <br>&#32;<br>
@@ -2040,9 +2040,9 @@ An example is the problem of heterogeneous instruction architectures,
 which is addressed by the compilers (different code characters, portable
 object code),
 the environment
-(<TT>$cputype</TT>
+(<TT></TT><I>cputype</I>
 and
-<TT>$objtype</TT>),
+</TT><TT></TT><TT>objtype</TT>),
 the name space
 (binding in
 <TT>/bin</TT>),
@@ -2260,8 +2260,8 @@ USENIX Summer Conf. Proc.,
 Nashville, June, 1991, pp. 257-265,
 reprinted in this volume.
 <DT>[Pike93]<DD>
-Rob Pike and Ken Thompson, ``Hello World or &#191;ALPHA&#191;&#191;MU&#191;&#191;ALPHA &#191;&#191;&#191;MUEPSILON or
-&#191;&#191;&#191;&#191;&#191; &#191;&#191;'',
+Rob Pike and Ken Thompson, ``Hello World or &#922;&#945;&#955;&#951;&#956;&#941;&#961;&#945; &#954;&#972;&#963;&#956;&#949; or
+&#12371;&#12435;&#12395;&#12385;&#12399; &#19990;&#30028;'',
 USENIX Winter Conf. Proc.,
 San Diego, 1993, pp. 43-50,
 reprinted in this volume.
@@ -2364,10 +2364,9 @@ Volume 2,
 AT&amp;T Bell Laboratories,
 Murray Hill, NJ,
 1995.
-
 </H4>
 </dl>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2001 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 66 - 66
sys/doc/acid.html

@@ -110,11 +110,11 @@ language and program interact:
 /sys/lib/acid/port
 /sys/lib/acid/mips
 acid: new()
-75721: system call  _main ADD  $-0x14,R29
+75721: system call  _main ADD  <I>-0x14,R29
 75721: breakpoint   main+0x4   MOVW  R31,0x0(R29)
 acid: bpset(ls)
 acid: cont()
-75721: breakpoint   ls    ADD  $-0x16c8,R29
+75721: breakpoint   ls    ADD  </I>-0x16c8,R29
 acid: stk()
 At pc:0x0000141c:ls /sys/src/cmd/ls.c:87
 ls(s=0x0000004d,multi=0x00000000) /sys/src/cmd/ls.c:87
@@ -250,63 +250,63 @@ The supported format characters are:
 <DL><DD>
 </P>
 <DL COMPACT>
-<DT>&lt;TT&gt;o&lt;/TT&gt;<DD>
+<DT><TT>o</TT><DD>
 Print two-byte integer in octal.
-<DT>&lt;TT&gt;O&lt;/TT&gt;<DD>
+<DT><TT>O</TT><DD>
 Print four-byte integer in octal.
-<DT>&lt;TT&gt;q&lt;/TT&gt;<DD>
+<DT><TT>q</TT><DD>
 Print two-byte integer in signed octal.
-<DT>&lt;TT&gt;Q&lt;/TT&gt;<DD>
+<DT><TT>Q</TT><DD>
 Print four-byte integer in signed octal.
-<DT>&lt;TT&gt;B&lt;/TT&gt;<DD>
+<DT><TT>B</TT><DD>
 Print four-byte integer in binary.
-<DT>&lt;TT&gt;d&lt;/TT&gt;<DD>
+<DT><TT>d</TT><DD>
 Print two-byte integer in signed decimal.
-<DT>&lt;TT&gt;D&lt;/TT&gt;<DD>
+<DT><TT>D</TT><DD>
 Print four-byte integer in signed decimal.
-<DT>&lt;TT&gt;Y&lt;/TT&gt;<DD>
+<DT><TT>Y</TT><DD>
 Print eight-byte integer in signed decimal.
-<DT>&lt;TT&gt;Z&lt;/TT&gt;<DD>
+<DT><TT>Z</TT><DD>
 Print eight-byte integer in unsigned decimal.
-<DT>&lt;TT&gt;x&lt;/TT&gt;<DD>
+<DT><TT>x</TT><DD>
 Print two-byte integer in hexadecimal.
-<DT>&lt;TT&gt;X&lt;/TT&gt;<DD>
+<DT><TT>X</TT><DD>
 Print four-byte integer in hexadecimal.
-<DT>&lt;TT&gt;Y&lt;/TT&gt;<DD>
+<DT><TT>Y</TT><DD>
 Print eight-byte integer in hexadecimal.
-<DT>&lt;TT&gt;u&lt;/TT&gt;<DD>
+<DT><TT>u</TT><DD>
 Print two-byte integer in unsigned decimal.
-<DT>&lt;TT&gt;U&lt;/TT&gt;<DD>
+<DT><TT>U</TT><DD>
 Print four-byte integer in unsigned decimal.
-<DT>&lt;TT&gt;f&lt;/TT&gt;<DD>
+<DT><TT>f</TT><DD>
 Print single-precision floating point number.
-<DT>&lt;TT&gt;F&lt;/TT&gt;<DD>
+<DT><TT>F</TT><DD>
 Print double-precision floating point number.
-<DT>&lt;TT&gt;g&lt;/TT&gt;<DD>
+<DT><TT>g</TT><DD>
 Print a single precision floating point number in string format.
-<DT>&lt;TT&gt;G&lt;/TT&gt;<DD>
+<DT><TT>G</TT><DD>
 Print a double precision floating point number in string format.
-<DT>&lt;TT&gt;b&lt;/TT&gt;<DD>
+<DT><TT>b</TT><DD>
 Print byte in hexadecimal.
-<DT>&lt;TT&gt;c&lt;/TT&gt;<DD>
+<DT><TT>c</TT><DD>
 Print byte as an ASCII character.
-<DT>&lt;TT&gt;C&lt;/TT&gt;<DD>
+<DT><TT>C</TT><DD>
 Like
 <TT>c</TT>,
 with
 printable ASCII characters represented normally and
 others printed in the form <TT>\x</TT><I>nn</I>.
-<DT>&lt;TT&gt;s&lt;/TT&gt;<DD>
+<DT><TT>s</TT><DD>
 Interpret the addressed bytes as UTF characters
 and print successive characters until a zero byte is reached.
-<DT>&lt;TT&gt;r&lt;/TT&gt;<DD>
+<DT><TT>r</TT><DD>
 Print a two-byte integer as a rune.
-<DT>&lt;TT&gt;R&lt;/TT&gt;<DD>
+<DT><TT>R</TT><DD>
 Print successive two-byte integers as runes
 until a zero rune is reached.
-<DT>&lt;TT&gt;i&lt;/TT&gt;<DD>
+<DT><TT>i</TT><DD>
 Print as machine instructions.
-<DT>&lt;TT&gt;I&lt;/TT&gt;<DD>
+<DT><TT>I</TT><DD>
 As
 <TT>i</TT>
 above, but print the machine instructions in
@@ -315,7 +315,7 @@ an alternate form if possible:
 and
 <TT>mipsco</TT>
 reproduce the manufacturers' syntax.
-<DT>&lt;TT&gt;a&lt;/TT&gt;<DD>
+<DT><TT>a</TT><DD>
 Print the value in symbolic form.
 </DL>
 </dl>
@@ -467,7 +467,7 @@ examines and modifies Acid's map for a process.
 Name conflicts between keywords in the Acid language, symbols in the program,
 and previously defined functions are resolved when the interpreter starts up.
 Each name is made unique by prefixing enough
-<TT>$</TT>
+<TT></TT><I></I><TT>
 characters to the front of the name to make it unique. Acid reports
 a list of each name change at startup. The report looks like this:
 <DL><DT><DD><TT><PRE>
@@ -475,16 +475,16 @@ a list of each name change at startup. The report looks like this:
 /lib/acid/port
 /lib/acid/mips
 Symbol renames:
-	append=$append T/0xa4e40
+	append=</TT>append T/0xa4e40
 acid:
 </PRE></TT></DL>
 The symbol
 <TT>append</TT>
 is both a keyword and a text symbol in the program. The message reports
 that the text symbol is now named
-<TT>$append</TT>.
+<TT></TT><I>append</I><TT>.
 </P>
-<H4>Expressions
+</TT><H4>Expressions
 </H4>
 <P>
 Operators have the same
@@ -791,8 +791,8 @@ will generate Acid source code defining such complex types and functions; see
 A
 <I>unary-expression</I>
 may be qualified with a format specifier using the
-<TT>o</TT>
-perator. This has the same effect as passing the expression to the
+<TT>\</TT>
+operator. This has the same effect as passing the expression to the
 <TT>fmt</TT>
 builtin function.
 <DL><DT><DD><TT><PRE>
@@ -1214,7 +1214,7 @@ The source file address uses the same format as
 <br>
 acid: bpset(filepc("main:10"))
 acid: bptab()
-	0x00001020 usage  ADD	$-0xc,R29
+	0x00001020 usage  ADD	-0xc,R29
 </PRE></TT></DL>
 <br>
 
@@ -1235,8 +1235,8 @@ what kind of object will be fetched by the
 and
 <TT>@</TT>
 operators. The
-<TT>o</TT>
-perator is a short-hand form of the
+<TT>\</TT>
+operator is a short-hand form of the
 <TT>fmt</TT>
 builtin function. The
 <TT>fmt</TT>
@@ -1248,9 +1248,9 @@ unchanged.
 <br>
 acid: main=fmt(main, 'i') // as instructions
 acid: print(main\X, "\t", *main)
-0x00001020 ADD	$-64,R29
+0x00001020 ADD	<I>-64,R29
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -1512,7 +1512,7 @@ environment.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: newproc("-l .")
-56720: system call	_main	ADD	$-0x14,R29
+56720: system call	_main	ADD	-0x14,R29
 </PRE></TT></DL>
 <br>
 
@@ -1583,9 +1583,9 @@ acid: print(10, "decimal ", 10\D, "octal ", 10\o)
 acid: print({1, 2, 3})
 {0x00000001 , 0x00000002 , 0x00000003 }
 acid: print(main, main\a, "\t", @main\i)
-0x00001020 main	ADD	$-64,R29
+0x00001020 main	ADD	<I>-64,R29
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -1607,7 +1607,7 @@ accepts a maximum of 512 arguments.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: printto("/env/foo", "hello")
-acid: rc("echo -n $foo")
+acid: rc("echo -n foo")
 hello
 </PRE></TT></DL>
 <br>
@@ -1784,9 +1784,9 @@ is used to implement single stepping.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: startstop(pid)
-75374: breakpoint	ls	ADD	$-0x16c8,R29
+75374: breakpoint	ls	ADD	<I>-0x16c8,R29
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -1923,7 +1923,7 @@ function is passive; it does not itself cause the program to stop.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: waitstop(pid)
-75374: breakpoint	ls	ADD	$-0x16c8,R29
+75374: breakpoint	ls	ADD	-0x16c8,R29
 </PRE></TT></DL>
 <br>
 
@@ -1939,15 +1939,15 @@ Acid is started.
 These modules are located in the directory
 <TT>/sys/lib/acid</TT>.
 These functions may be overridden, personalized, or added to by code defined in
-<TT>$home/lib/acid</TT>.
+<TT></TT><I>home/lib/acid</I><TT>.
 The implementation of these functions can be examined using the
-<TT>whatis</TT>
+</TT><TT>whatis</TT><TT>
 operator and then modified during debugging sessions.
 
 
 
 </P>
-<br>&#32;<br>
+</TT><br>&#32;<br>
 <DL>
 <DT><DT>&#32;<DD>
 <TT>Bsrc</TT>
@@ -2089,12 +2089,12 @@ operator.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: asm(main)
-main     0x00001020 ADD    $-0x64,R29
+main     0x00001020 ADD    -0x64,R29
 main+0x4 0x00001024 MOVW   R31,0x0(R29)
 main+0x8 0x00001028 MOVW   R1,argc+4(FP)
-main+0xc 0x0000102c MOVW   $bin(SB),R1
+main+0xc 0x0000102c MOVW   <I>bin(SB),R1
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -2201,12 +2201,12 @@ this command stops disassembling at function boundaries.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: casm()
-main+0x10 0x00001030	MOVW	$0x1,R3
+main+0x10 0x00001030	MOVW	0x1,R3
 main+0x14 0x00001034	MOVW	R3,0x8(R29)
-main+0x18 0x00001038	MOVW	$0x1,R5
+main+0x18 0x00001038	MOVW	<I>0x1,R5
 main+0x1c 0x0000103c	JAL	Binit(SB)
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -2260,7 +2260,7 @@ to fetch each object.
 acid: dump(main+35, 4, "X2bi")
 0x00001043: 0x0c8fa700 108 143 lwc2 r0,0x528f(R4) 
 0x0000104d: 0xa9006811   0   0 swc3 r0,0x0(R24) 
-0x00001057: 0x2724e800   4  37 ADD  $-0x51,R23,R31 
+0x00001057: 0x2724e800   4  37 ADD  -0x51,R23,R31 
 0x00001061: 0xa200688d   6   0 NOOP
 0x0000106b: 0x2710c000   7   0 BREAK
 </PRE></TT></DL>
@@ -2342,9 +2342,9 @@ acid: func()
 95197: breakpoint	ls+0x8	MOVW	R1,R8
 95197: breakpoint	ls+0xc	MOVW	R8,R1
 95197: breakpoint	ls+0x10	MOVW	R8,s+4(FP)
-95197: breakpoint	ls+0x14	MOVW	$0x2f,R5
+95197: breakpoint	ls+0x14	MOVW	<I>0x2f,R5
 95197: breakpoint	ls+0x18	JAL	utfrrune(SB)
-95197: breakpoint	utfrrune	ADD	$-0x18,R29
+95197: breakpoint	utfrrune	ADD	</I>-0x18,R29
 </PRE></TT></DL>
 <br>
 
@@ -2489,10 +2489,10 @@ simultaneously. The user can rotate between the copies using
 <br>
 acid: progargs="-l"
 acid: new()
-60: external interrupt	_main	ADD	$-0x14,R29
+60: external interrupt	_main	ADD	<I>-0x14,R29
 60: breakpoint	main+0x4	MOVW	R31,0x0(R29)
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -2816,7 +2816,7 @@ function will trace down through function calls.
 acid: stmnt()
 62: breakpoint	main+0x18 MOVW	R5,0xc(R29)
 62: breakpoint	main+0x1c JAL	Binit(SB)
-62: breakpoint	Binit     ADD	$-0x18,R29
+62: breakpoint	Binit     ADD	-0x18,R29
 binit.c:91
  89	int
  90	Binit(Biobuf *bp, int f, int mode)
@@ -2898,18 +2898,18 @@ The variable
 <TT>progargs</TT>
 supplies arguments to the new process.
 The environment variable
-<TT>$8&#189;srv</TT>
+<TT></TT><I>8&#189;srv</I><TT>
 must be set to allow the interpreter to locate the mount channel for the
 window system.
 The window is created in the top left corner of the screen and is
 400x600 pixels in size. The
-<TT>win</TT>
+</TT><TT>win</TT><TT>
 function may be modified to alter the geometry.
 The window system will not be able to deliver notes in the new window
 since the pid of the created process is not passed when the server is
 mounted to create a new window.
 <DT><DT>&#32;<DD>
-<DL><DT><DD><TT><PRE>
+</TT><DL><DT><DD><TT><PRE>
 <br>
 acid: win()
 </PRE></TT></DL>
@@ -2917,5 +2917,5 @@ acid: win()
 </dl>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2002 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 23 - 24
sys/doc/acidpaper.html

@@ -262,7 +262,7 @@ Global variables are created by assignment and need not be declared.
 All variables and functions in the program
 being debugged are entered in the Acid symbol table as global
 variables during Acid initialization.
-Conflicting variable names are resolved by prefixing enough `$' characters
+Conflicting variable names are resolved by prefixing enough `<I>' characters
 to make them unique.
 Syntactically, Acid variables and target program
 symbols are referenced identically.
@@ -277,7 +277,7 @@ accessed by indirect reference through the Acid
 variable that has the same name; the value of an Acid variable is the
 address of the corresponding program variable.
 </P>
-<H4>5 Control Flow
+</I><H4>5 Control Flow
 </H4>
 <P>
 The
@@ -359,8 +359,8 @@ argument to the result and returns that value.
 If the result is assigned to a variable,
 the new format code applies to
 that variable.  For convenience, Acid provides the
-<TT>o</TT>
-perator as a shorthand infix form of
+<TT>\</TT>
+operator as a shorthand infix form of
 <TT>fmt</TT>.
 For example:
 <DL><DT><DD><TT><PRE>
@@ -390,7 +390,7 @@ acid: p=main\i                     // p=addr(main), type INST
 acid: loop 1,5 do print(p\X, @p++) // disassemble 5 instr's
 0x0000222e LEA	0xffffe948(A7),A7
 0x00002232 MOVL	s+0x4(A7),A2
-0x00002236 PEA	0x2f($0)
+0x00002236 PEA	0x2f(0)
 0x0000223a MOVL	A2,-(A7)
 0x0000223c BSR	utfrrune
 acid:
@@ -429,28 +429,28 @@ main
 acid: *R1=10                        // modify R1
 acid: asm(*PC+4)                    // disassemble @ PC+4
 main+0x4 0x00006240 	MOVW	R31,0x0(R29)
-main+0x8 0x00006244 	MOVW	$setR30(SB),R30
+main+0x8 0x00006244 	MOVW	<I>setR30(SB),R30
 main+0x10 0x0000624c 	MOVW	R1,_clock(SB)
 </PRE></TT></DL>
 Here, the saved
-<TT>PC</TT>
+</I><TT>PC</TT><I>
 is stored at address
-<TT>0xc0000f60</TT>;
+</I><TT>0xc0000f60</TT><I>;
 its current content is
-<TT>0x0000623c</TT>.
+</I><TT>0x0000623c</TT><I>.
 The
-`<TT>a</TT>'
+`</I><TT>a</TT><I>'
 format code converts this value to a string specifying
 the address as an offset beyond the nearest symbol.
 After setting the value of register
-<TT>1</TT>,
+</I><TT>1</TT><I>,
 the example uses the
-<TT>asm</TT>
+</I><TT>asm</TT><I>
 command to disassemble a short section of code beginning
 at four bytes beyond the current value of the
-<TT>PC</TT>.
+</I><TT>PC</TT><I>.
 </P>
-<H4>7 Process Interface
+</I><H4>7 Process Interface
 </H4>
 <P>
 A program executing under Acid is monitored through the
@@ -535,7 +535,7 @@ main(int argc, char *argv[])
 acid: src(*PC)			// print statements nearby
  9
  10 void
-&#62;11 main(int argc, char *argv[])
+&gt;11 main(int argc, char *argv[])
  12 {
  13	int a;
 </PRE></TT></DL>
@@ -584,7 +584,7 @@ illustrate the interaction of the debugger and the interpreter.
 <DL><DT><DD><TT><PRE>
 defn bpset(addr)                          // set breakpoint
 {
-	if match(addr, bplist) &#62;= 0 then
+	if match(addr, bplist) &gt;= 0 then
 		print("bkpoint already set:", addr\a, "\n");
 	else {
 		*fmt(addr, bpfmt) = bpinst;   // plant it
@@ -623,7 +623,7 @@ defn step()				// single step
 	local lst, lpl, addr, bput;
 
 	bput = 0;			// sitting on bkpoint
-	if match(*PC, bplist) &#62;= 0 then {	
+	if match(*PC, bplist) &gt;= 0 then {	
 		bput = fmt(*PC, bpfmt);	// save current addr
 		*bput = @bput;		// replace it
 	}
@@ -728,10 +728,10 @@ defn next()
 	bound = fnbound(*PC);		// begin &amp; end of fn.
 	stmnt();			// step 1 statement
 	pc = *PC;
-	if pc &#62;= bound[0] &amp;&amp; pc &#60; bound[1] then
+	if pc &gt;= bound[0] &amp;&amp; pc &lt; bound[1] then
 		return {};
 
-	while (pc&#60;bound[0] || pc&#62;bound[1]) &amp;&amp; sp&#62;=*SP do {
+	while (pc&lt;bound[0] || pc&gt;bound[1]) &amp;&amp; sp&gt;=*SP do {
 		step();
 		pc = *PC;
 	}
@@ -1008,7 +1008,7 @@ complex data type.
 Acid borrows the C operators
 <TT>.</TT>
 and
-<TT>-></TT>
+<TT>-&gt;</TT>
 to access the decoding parameters of a member of a complex type.
 Although this representation is sufficiently general for describing
 the decoding of both C and Alef complex data types, it may
@@ -1053,12 +1053,12 @@ now
 is
 the
 time
-&#60;ctrl-d&#62;
+&lt;ctrl-d&gt;
 is
 now
 the
 time
-27680 : breakpoint	_exits+0x4	MOVW	$0x8,R1
+27680 : breakpoint	_exits+0x4	MOVW	0x8,R1
 acid: 
 </PRE></TT></DL>
 The
@@ -1362,8 +1362,7 @@ San Antonio, TX.
 Proceedings of the Third International Conference on Architectural
 Support for Programming Languages and Operating Systems,
 SIGPLAN notices Nr. 22, May 1989.
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 37 - 38
sys/doc/ape.html

@@ -43,7 +43,7 @@ The
 command acts as a front end to the Plan 9 C compilers and loaders.
 It runs an ANSI C preprocessor over source files, using the APE
 headers to satisfy
-<TT>#include <<I>file</I>></TT>
+<TT>#include &lt;</TT><I>file</I><TT>&gt;</TT>
 directives; then it runs a Plan 9 C compiler; finally, it may load
 with APE libraries to produce an executable program.
 The document
@@ -51,12 +51,12 @@ The document
 explains how environment variables are used by convention to
 handle compilation for differing architectures.
 The environment variable
-<TT>$objtype</TT>
+<TT></TT><I>objtype</I>
 controls which Plan 9 compiler and loader are used by
-<TT>pcc</TT>,
+</TT><TT>pcc</TT>,
 as well as the location of header and library files.
 For example, if
-<TT>$objtype</TT>
+</TT><TT></TT><TT>objtype</TT>
 is
 <TT>mips</TT>,
 then
@@ -147,17 +147,17 @@ to turn on ANSI prototype warnings;
 <TT>-S</TT>
 to leave assembly language in
 <I>file</I>.s;
-<TT>-Wp,<I>args</I></TT>
+<TT>-Wp,</TT><I>args</I><TT></TT>
 to pass
 <I>args</I>
 to the
 <TT>cpp</TT>;
-<TT>-W0,<I>args</I></TT>
+<TT>-W0,</TT><I>args</I><TT></TT>
 to pass
 <I>args</I>
 to 2c, etc.;
 and
-<TT>-Wl,<I>args</I></TT>
+<TT>-Wl,</TT><I>args</I><TT></TT>
 to pass
 <I>args</I>
 to 2l, etc.
@@ -201,10 +201,10 @@ The most important feature test macro is
 when it is defined, exactly the symbols required by POSIX are
 visible in the appropriate headers.
 Consider
-<TT><signal.h></TT>
+<TT>&lt;signal.h&gt;</TT>
 for example:
 ANSI defines some names that must be defined in
-<TT><signal.h></TT>,
+<TT>&lt;signal.h&gt;</TT>,
 but POSIX defines others, such as
 <TT>sigset_t</TT>,
 which are not allowed according to ANSI.
@@ -238,7 +238,7 @@ by the C or POSIX standard, and those required by the POSIX standard
 are protected by
 <TT>#ifdef _POSIX_SOURCE</TT>.
 For example,
-<TT><errno.h></TT>
+<TT>&lt;errno.h&gt;</TT>
 defines
 <TT>EDOM</TT>,
 <TT>ERANGE</TT>,
@@ -294,7 +294,7 @@ The functions are as described in the Plan 9 manual (see
 had to be renamed
 <TT>ptdiv</TT>.
 Include the
-<TT><libg.h></TT>
+<TT>&lt;libg.h&gt;</TT>
 header to declare the needed types and functions.
 <DT>   -<DD>
 <TT>_LIMITS_EXTENSION</TT>.
@@ -303,12 +303,12 @@ POSIX does not require that names such as
 and
 <TT>OPEN_MAX</TT>
 be defined in
-<TT><limits.h></TT>,
+<TT>&lt;limits.h&gt;</TT>,
 but many programs assume they are defined there.
 If
 <TT>_LIMITS_EXTENSION</TT>
 is defined, those names will all be defined when
-<TT><limits.h></TT>
+<TT>&lt;limits.h&gt;</TT>
 is included.
 <DT>   -<DD>
 <TT>_BSD_EXTENSION</TT>.
@@ -316,45 +316,45 @@ This extension includes not only Berkeley Unix routines,
 but also a grab bag of other miscellaneous routines often
 found in Unix implementations.
 The extension allows the inclusion of any of:
-<TT><bsd.h></TT>
+<TT>&lt;bsd.h&gt;</TT>
 for
 <TT>bcopy()</TT>,
 <TT>bcmp()</TT>,
 and similar Berkeley functions;
-<TT><netdb.h></TT>
+<TT>&lt;netdb.h&gt;</TT>
 for
 <TT>gethostbyname()</TT>,
 etc.,
 and associated structures;
-<TT><select.h></TT>
+<TT>&lt;select.h&gt;</TT>
 for the Berkeley
 <TT>select</TT>
 function and associated types and macros
 for dealing with multiple input sources;
-<TT><sys/ioctl.h></TT>
+<TT>&lt;sys/ioctl.h&gt;</TT>
 for the
 <TT>ioctl</TT>
 function (minimally implemented);
-<TT><sys/param.h></TT>
+<TT>&lt;sys/param.h&gt;</TT>
 for
 <TT>NOFILES_MAX</TT>;
-<TT><sys/pty.h></TT>
+<TT>&lt;sys/pty.h&gt;</TT>
 for pseudo-tty support via the
 <TT>ptsname(int)</TT>
 and
 <TT>ptmname(int)</TT>
 functions;
-<TT><sys/resource.h></TT>;
-<TT><sys/socket.h></TT>
+<TT>&lt;sys/resource.h&gt;</TT>;
+<TT>&lt;sys/socket.h&gt;</TT>
 for socket structures, constants, and functions;
-<TT><sys/time.h></TT>
+<TT>&lt;sys/time.h&gt;</TT>
 for definitions of the
 <TT>timeval</TT>
 and
 <TT>timezone</TT>
 structures;
 and
-<TT><sys/uio.h></TT>
+<TT>&lt;sys/uio.h&gt;</TT>
 for the
 <TT>iovec</TT>
 structure and the
@@ -365,23 +365,23 @@ functions used for scatter/gather I/O.
 Defining
 <TT>_BSD_EXTENSION</TT>
 also enables various extra definitions in
-<TT><ctype.h></TT>,
-<TT><signal.h></TT>,
-<TT><stdio.h></TT>,
-<TT><unistd.h></TT>,
-<TT><sys/stat.h></TT>,
+<TT>&lt;ctype.h&gt;</TT>,
+<TT>&lt;signal.h&gt;</TT>,
+<TT>&lt;stdio.h&gt;</TT>,
+<TT>&lt;unistd.h&gt;</TT>,
+<TT>&lt;sys/stat.h&gt;</TT>,
 and
-<TT><sys/times.h></TT>.
+<TT>&lt;sys/times.h&gt;</TT>.
 <DT>   -<DD>
 <TT>_NET_EXTENSION</TT>.
 This extension allows inclusion of
-<TT><libnet.h></TT>,
+<TT>&lt;libnet.h&gt;</TT>,
 which defines the networking functions described in the Plan 9 manual page
 <A href="/magic/man2html/2/dial"><I>dial</I>(2).
 </A><DT>   -<DD>
 <TT>_REGEXP_EXTENSION</TT>.
 This extension allows inclusion of
-<TT><regexp.h></TT>,
+<TT>&lt;regexp.h&gt;</TT>,
 which defines the regular expression matching functions described
 in the Plan 9 manual page
 <A href="/magic/man2html/2/regexp"><I>regexp</I>(2).
@@ -390,7 +390,7 @@ in the Plan 9 manual page
 This extension enables a small library of functions from the Tenth Edition Unix
 Research System (V10).
 These functions and the types needed to use them are all defined in the
-<TT><libv.h></TT>
+<TT>&lt;libv.h&gt;</TT>
 header.
 The provided functions are:
 <TT>srand</TT>,
@@ -441,7 +441,7 @@ A good strategy for porting external programs is to first try using
 if that doesn't work, try adding
 <TT>_D_BSD_EXTENSION</TT>
 and perhaps include
-<TT><bsd.h></TT>
+<TT>&lt;bsd.h&gt;</TT>
 in source files.
 Here are some solutions to problems that might remain:
 </P>
@@ -456,15 +456,15 @@ global instead.
 <TT>OPEN_MAX</TT>,
 <TT>PATH_MAX</TT>,
 etc., assumed in
-<TT><limits.h></TT>.
+<TT>&lt;limits.h&gt;</TT>.
 Rewrite to call
 <TT>sysconf</TT>
 or define
 <TT>_LIMITS_EXTENSION</TT>.
 <DT>   -<DD>
-<TT><varargs.h></TT>.
+<TT>&lt;varargs.h&gt;</TT>.
 Rewrite to use
-<TT><stdarg.h></TT>.
+<TT>&lt;stdarg.h&gt;</TT>.
 </dl>
 <P>
 The second class of problems has to do with inadequacies in the Plan 9
@@ -525,9 +525,8 @@ code that does
 should be changed to
 <TT>getenv("home")</TT>
 on Plan 9.
-
 </dl>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 52 - 53
sys/doc/asm.html

@@ -160,7 +160,7 @@ offsets to
 <TT>SB</TT>,
 as in
 <DL><DT><DD><TT><PRE>
-	MOVL	$array(SB), TOS
+	MOVL	<I>array(SB), TOS
 </PRE></TT></DL>
 to push the address of a global array on the stack, or
 <DL><DT><DD><TT><PRE>
@@ -169,22 +169,22 @@ to push the address of a global array on the stack, or
 to push the second (4-byte) element of the array.
 Note the use of an offset; the complete list of addressing modes is given below.
 Similarly, subroutine calls must use
-<TT>SB</TT>:
+</I><TT>SB</TT><I>:
 <DL><DT><DD><TT><PRE>
 	BSR	exit(SB)
 </PRE></TT></DL>
 File-static variables have syntax
 <DL><DT><DD><TT><PRE>
-	local&#60;&#62;+4(SB)
+	local&lt;&gt;+4(SB)
 </PRE></TT></DL>
 The
-<TT><></TT>
+</I><TT>&lt;&gt;</TT><I>
 will be filled in at load time by a unique integer.
 </P>
-<P>
+</I><P>
 When a program starts, it must execute
 <DL><DT><DD><TT><PRE>
-	MOVL	$a6base(SB), A6
+	MOVL	a6base(SB), A6
 </PRE></TT></DL>
 before accessing any global data.
 (On machines such as the MIPS and SPARC that cannot load a register
@@ -239,7 +239,7 @@ to indicate the size and scaling of the data.
 </P>
 <DL>
 <DT><DT>&#32;<DD>
-<br><img src="data.10610.gif"><br>
+<br><img src="data.19116310.gif"><br>
 </dl>
 <H4>Laying down data
 </H4>
@@ -254,23 +254,23 @@ and
 lay down the value of their single argument, of the appropriate size,
 as if it were an instruction:
 <DL><DT><DD><TT><PRE>
-	LONG	$12345
+	LONG	<I>12345
 </PRE></TT></DL>
 places the long 12345 (base 10)
 in the instruction stream.
 (On most machines,
 the only such operator is
-<TT>WORD</TT>
+</I><TT>WORD</TT><I>
 and it lays down 32-bit quantities.
 The 386 has all three:
-<TT>LONG</TT>,
-<TT>WORD</TT>,
+</I><TT>LONG</TT><I>,
+</I><TT>WORD</TT><I>,
 and
-<TT>BYTE</TT>.
+</I><TT>BYTE</TT><I>.
 The 960 has only one,
-<TT>LONG</TT>.)
+</I><TT>LONG</TT><I>.)
 </P>
-<P>
+</I><P>
 Placing information in the data section is more painful.
 The pseudo-instruction
 <TT>DATA</TT>
@@ -282,57 +282,57 @@ containing the characters
 <TT>abc</TT>
 and a terminating null:
 <DL><DT><DD><TT><PRE>
-	DATA    array+0(SB)/1, $'a'
-	DATA    array+1(SB)/1, $'b'
-	DATA    array+2(SB)/1, $'c'
-	GLOBL   array(SB), $4
+	DATA    array+0(SB)/1, 'a'
+	DATA    array+1(SB)/1, <I>'b'
+	DATA    array+2(SB)/1, </I>'c'
+	GLOBL   array(SB), <I>4
 </PRE></TT></DL>
 or
 <DL><DT><DD><TT><PRE>
-	DATA    array+0(SB)/4, $"abc\z"
-	GLOBL   array(SB), $4
+	DATA    array+0(SB)/4, </I>"abc\z"
+	GLOBL   array(SB), <I>4
 </PRE></TT></DL>
 The
-<TT>/1</TT>
+</I><TT>/1</TT><I>
 defines the number of bytes to define,
-<TT>GLOBL</TT>
+</I><TT>GLOBL</TT><I>
 makes the symbol global, and the
-<TT>$4</TT>
+</I><TT></TT><I>4</I><TT>
 says how many bytes the symbol occupies.
 Uninitialized data is zeroed automatically.
 The character
-<TT>z</TT>
+</TT><TT>\z</TT><TT>
 is equivalent to the C
-<TT> .</TT>
+</TT><TT>\0.</TT><TT>
 The string in a
-<TT>DATA</TT>
+</TT><TT>DATA</TT><TT>
 statement may contain a maximum of eight bytes;
 build larger strings piecewise.
 Two pseudo-instructions,
-<TT>DYNT</TT>
+</TT><TT>DYNT</TT><TT>
 and
-<TT>INIT</TT>,
+</TT><TT>INIT</TT><TT>,
 allow the (obsolete) Alef compilers to build dynamic type information during the load
 phase.
 The
-<TT>DYNT</TT>
+</TT><TT>DYNT</TT><TT>
 pseudo-instruction has two forms:
 <DL><DT><DD><TT><PRE>
 	DYNT	, ALEF_SI_5+0(SB)
 	DYNT	ALEF_AS+0(SB), ALEF_SI_5+0(SB)
 </PRE></TT></DL>
 In the first form,
-<TT>DYNT</TT>
+</TT><TT>DYNT</TT><TT>
 defines the symbol to be a small unique integer constant, chosen by the loader,
 which is some multiple of the word size.  In the second form,
-<TT>DYNT</TT>
+</TT><TT>DYNT</TT><TT>
 defines the second symbol in the same way,
 places the address of the most recently
 defined text symbol in the array specified by the first symbol at the
 index defined by the value of the second symbol,
 and then adjusts the size of the array accordingly.
 </P>
-<P>
+</TT><P>
 The
 <TT>INIT</TT>
 pseudo-instruction takes the same parameters as a
@@ -363,20 +363,20 @@ and restore instructions, even if the function is not a leaf.
 Here is a complete procedure that returns the sum
 of its two arguments:
 <DL><DT><DD><TT><PRE>
-TEXT	sum(SB), $0
+TEXT	sum(SB), <I>0
 	MOVL	arg1+0(FP), R0
 	ADDL	arg2+4(FP), R0
 	RTS
 </PRE></TT></DL>
 An optional middle argument
 to the
-<TT>TEXT</TT>
+</I><TT>TEXT</TT><I>
 pseudo-op is a bit field of options to the loader.
 Setting the 1 bit suspends profiling the function when profiling is enabled for the rest of
 the program.
 For example,
 <DL><DT><DD><TT><PRE>
-TEXT	sum(SB), 1, $0
+TEXT	sum(SB), 1, </I>0
 	MOVL	arg1+0(FP), R0
 	ADDL	arg2+4(FP), R0
 	RTS
@@ -433,29 +433,29 @@ does not distinguish between the various forms of
 instruction: move quick, move address, etc.  Instead the context
 does the job.  For example,
 <DL><DT><DD><TT><PRE>
-	MOVL	$1, R1
+	MOVL	<I>1, R1
 	MOVL	A0, R2
 	MOVW	SR, R3
 </PRE></TT></DL>
 generates official
-<TT>MOVEQ</TT>,
-<TT>MOVEA</TT>,
+</I><TT>MOVEQ</TT><I>,
+</I><TT>MOVEA</TT><I>,
 and
-<TT>MOVESR</TT>
+</I><TT>MOVESR</TT><I>
 instructions.
 A number of instructions do not have the syntax necessary to specify
 their entire capabilities.  Notable examples are the bitfield
 instructions, the
 multiply and divide instructions, etc.
 For a complete set of generated instruction names (in
-<TT>2a</TT>
+</I><TT>2a</TT><I>
 notation, not Motorola's) see the file
-<TT>/sys/src/cmd/2c/2.out.h</TT>.
+</I><TT>/sys/src/cmd/2c/2.out.h</TT><I>.
 Despite its name, this file contains an enumeration of the
 instructions that appear in the intermediate files generated
 by the compiler, which correspond exactly to lines of assembly language.
 </P>
-<P>
+</I><P>
 The MC68000 assembler,
 <TT>1a</TT>,
 is essentially the same, honoring the appropriate subset of the instructions
@@ -1175,7 +1175,7 @@ For example:
 <DL><DT><DD><TT><PRE>
 	MOVFL	CR(3), CR(0)
 	MOVFL	R3, CR(1)
-	MOVFL	R3, $7, CR
+	MOVFL	R3, 7, CR
 </PRE></TT></DL>
 They are also accepted in
 the conditional branch instruction, for example
@@ -1190,8 +1190,8 @@ in a similar way:
 <DL><DT><DD><TT><PRE>
 	MOVFL	FPSCR, F0
 	MOVFL	F0, FPSCR
-	MOVFL	F0, $7, FPSCR
-	MOVFL	$0, FPSCR(3)
+	MOVFL	F0, <I>7, FPSCR
+	MOVFL	</I>0, FPSCR(3)
 </PRE></TT></DL>
 producing
 <TT>mffs</TT>,
@@ -1282,16 +1282,16 @@ and
 <TT>R14</TT>
 when in another processor mode.
 Shifts and rotates in addressing modes are supported by binary operators
-<TT><<</TT>
+<TT>&lt;&lt;</TT>
 (logical left shift),
-<TT>>></TT>
+<TT>&gt;&gt;</TT>
 (logical right shift),
-<TT>-></TT>
+<TT>-&gt;</TT>
 (arithmetic right shift), and
-<TT>@></TT>
+<TT>@&gt;</TT>
 (rotate right); for example
-<TT>R7>>R2</TT>or
-<TT>R2@>2</TT>.
+<TT>R7&gt;&gt;R2</TT>or
+<TT>R2@&gt;2</TT>.
 The assembler does not support indexing by a shifted expression;
 only names can be doubly indexed.
 </P>
@@ -1351,9 +1351,8 @@ and
 <P>
 For details about this assembly language, which was built for the AMD 29240,
 look at the sources or examine compiler output.
-
 </P>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 2052 - 438
sys/doc/auth.html

@@ -1,46 +1,172 @@
-<HEAD>
-<TITLE>Security in Plan 9</TITLE>
-<META content="text/html; charset=utf-8" http-equiv=Content-Type>
-</HEAD>
-<BODY BGCOLOR=WHITE>
-<h1>Security in Plan 9</h1>
-<EM>Russ Cox, MIT LCS<br>
+<html>
+<br><img src="-.19111510.gif"><br>
+<title>
+-
+</title>
+<body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044">
+<H1>Security in Plan 9
+</H1>
+<DL><DD><I>Russ Cox, MIT LCS<br>
+<br>
 Eric Grosse, Bell Labs<br>
+<br>
 Rob Pike, Bell Labs<br>
+<br>
 Dave Presotto, Avaya Labs and Bell Labs<br>
+<br>
 Sean Quinlan, Bell Labs<br>
-</EM><TT>{rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com<br>
-</TT><h4>ABSTRACT</h4>
-The security architecture of the Plan 9(tm) operating system has recently been redesigned to address some technical shortcomings. This redesign provided an opportunity also to make the system more convenient to use securely. Plan 9 has thus improved in two ways not usually seen together: it has become more secure <EM>and </EM>easier to use.
-  <P>
-The central component of the new architecture is a per-user self-contained agent called <TT>factotum</TT>. <TT>Factotum</TT> securely holds a copy of the user's keys and negotiates authentication protocols, on behalf of the user, with secure services around the network. Concentrating security code in a single program offers several advantages including: ease of update or repair to broken security software and protocols; the ability to run secure services at a lower privilege level; uniform management of keys for all services; and an opportunity to provide single sign on, even to unchanged legacy applications. <TT>Factotum</TT> has an unusual architecture: it is implemented as a Plan 9 file server. [[ To appear, in a slightly different form, in <EM>Proc. of the 2002 Usenix Security Symposium, </EM>San Francisco. ]]
-<H4>1. Introduction
-</H4>
-Secure computing systems face two challenges: first, they must employ sophisticated technology that is difficult to design and prove correct; and second, they must be easy for regular people to use. The question of ease of use is sometimes neglected, but it is essential: weak but easy-to-use security can be more effective than strong but difficult-to-use security if it is more likely to be used. People lock their front doors when they leave the house, knowing full well that a burglar is capable of picking the lock (or avoiding the door altogether); yet few would accept the cost and awkwardness of a bank vault door on the house even though that might reduce the probability of a robbery. A related point is that users need a clear model of how the security operates (if not how it actually provides security) in order to use it well; for example, the clarity of a lock icon on a web browser is offset by the confusing and typically insecure steps for installing X.509 certificates.
-  <P>
-The security architecture of the Plan 9 operating system [Pike95] has recently been redesigned to make it both more secure and easier to use. By <EM>security </EM>we mean three things: first, the business of authenticating users and services; second, the safe handling, deployment, and use of keys and other secret information; and third, the use of encryption and integrity checks to safeguard communications from prying eyes.
-  <P>
-The old security architecture of Plan 9 had several engineering problems in common with other operating systems. First, it had an inadequate notion of security domain. Once a user provided a password to connect to a local file store, the system required that the same password be used to access all the other file stores. That is, the system treated all network services as belonging to the same security domain.
-  <P>
-Second, the algorithms and protocols used in authentication, by nature tricky and difficult to get right, were compiled into the various applications, kernel modules, and file servers. Changes and fixes to a security protocol required that all components using that protocol needed to be recompiled, or at least relinked, and restarted.
-  <P>
-Third, the file transport protocol, 9P [Pike93], that forms the core of the Plan 9 system, had its authentication protocol embedded in its design. This meant that fixing or changing the authentication used by 9P required deep changes to the system. If someone were to find a way to break the protocol, the system would be wide open and very hard to fix.
-  <P>
-These and a number of lesser problems, combined with a desire for more widespread use of encryption in the system, spurred us to rethink the entire security architecture of Plan 9.<br>
-  <P>
-The centerpiece of the new architecture is an agent, called <TT>factotum</TT>, that handles the user's keys and negotiates all security interactions with system services and applications. Like a trusted assistant with a copy of the owner's keys, <TT>factotum</TT> does all the negotiation for security and authentication. Programs no longer need to be compiled with cryptographic code; instead they communicate with <TT>factotum</TT> agents that represent distinct entities in the cryptographic exchange, such as a user and server of a secure service. If a security protocol needs to be added, deleted, or modified, only <TT>factotum</TT> needs to be updated for all system services to be kept secure.
-  <P>
-Building on <TT>factotum</TT>, we modified secure services in the system to move user authentication code into <TT>factotum</TT>; made authentication a separable component of the file server protocol; deployed new security protocols; designed a secure file store, called <TT>secstore</TT>, to protect our keys but make them easy to get when they are needed; designed a new kernel module to support transparent use of Transport Layer Security (TLS) [RFC2246]; and began using encryption for all communications within the system. The overall architecture is illustrated in Figure 1a.
-<DL><DT><DD>
-<br><img src="-.2669382.gif"><br>
+<br>
+<TT>{rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com</TT>
+</I></DL>
+<DL><DD><H4>ABSTRACT</H4>
+The security architecture of the Plan 9(tm)
+operating system has recently been redesigned
+to address some technical shortcomings.
+This redesign provided an opportunity also to make the system more
+convenient to use securely.
+Plan 9 has thus improved in two ways not usually seen together:
+it has become more secure
+<I>and</I>
+easier to use.
+<br>&#32;<br>
+The central component of the new architecture is a per-user
+self-contained agent called
+<TT>factotum</TT>.
+<TT>Factotum</TT>
+securely holds a
+copy of the user's keys and negotiates authentication protocols, on
+behalf of the user, with secure services around the network.
+Concentrating security code in a single program offers several
+advantages including: ease of update or repair to broken security
+software and protocols; the ability to run secure services at a lower
+privilege level; uniform management of keys for all services; and an
+opportunity to provide single sign on, even to unchanged legacy
+applications.
+<TT>Factotum</TT>
+has an unusual architecture: it is implemented
+as a Plan 9 file server.
+<DL>
+<DT><DT>&#32;<DD>
+NOTE:<I> To appear, in a slightly different form, in
+Proc. of the 2002 Usenix Security Symposium,
+San Francisco.
+</I><DT>&#32;<DD></dl>
+<br>
 </DL>
+<H4>1 Introduction
+</H4>
+<br>&#32;<br>
+Secure computing systems face two challenges:
+first, they must employ sophisticated technology that is difficult to design
+and prove correct; and second,
+they must be easy for regular people to use.
+The question of ease of use is sometimes neglected, but it is essential:
+weak but easy-to-use security can be more effective than strong but
+difficult-to-use security if it is more likely to be used.
+People lock their front doors when they leave the house, knowing
+full well that a burglar is capable of picking the lock (or avoiding
+the door altogether); yet few would accept the cost and
+awkwardness of a bank vault door on the
+house even though that might reduce the probability of a robbery.
+A related point is that users need a clear model of how the security
+operates (if not how it actually provides security) in order to use it
+well; for example, the clarity of a lock icon on a web browser
+is offset by the confusing and typically insecure
+steps for installing X.509 certificates.
+<br>&#32;<br>
+The security architecture of the Plan 9
+operating system
+[Pike95]
+has recently been redesigned to make it both more secure
+and easier to use.
+By
+<I>security</I>
+we mean three things:
+first, the business of authenticating users and services;
+second, the safe handling, deployment, and use of keys
+and other secret information; and
+third, the use of encryption and integrity checks
+to safeguard communications
+from prying eyes.
+<br>&#32;<br>
+The old security architecture of Plan 9
+had several engineering problems in common with other operating systems.
+First, it had an inadequate notion of security domain.
+Once a user provided a password to connect to a local file store,
+the system required that the same password be used to access all the other file
+stores.
+That is, the system treated all network services as
+belonging to the same security domain. 
+<br>&#32;<br>
+Second, the algorithms and protocols used in authentication,
+by nature tricky and difficult to get right, were compiled into the
+various applications, kernel modules, and file servers.
+Changes and fixes to a security protocol
+required that all components using that protocol needed to be recompiled,
+or at least relinked, and restarted.
+<br>&#32;<br>
+Third, the file transport protocol, 9P
+[Pike93],
+that forms the core of
+the Plan 9 system, had its authentication protocol embedded in its design.
+This meant that fixing or changing the authentication used by 9P
+required deep changes to the system.
+If someone were to find a way to break the protocol, the system would
+be wide open and very hard to fix.
+<br>&#32;<br>
+These and a number of lesser problems, combined with a desire
+for more widespread use of encryption in the system, spurred us to
+rethink the entire security architecture of Plan 9.
+<br>&#32;<br>
+The centerpiece of the new architecture is an agent,
+called
+<TT>factotum</TT>,
+that handles the user's keys and negotiates all security
+interactions with system services and applications.
+Like a trusted assistant with a copy of the owner's keys,
+<TT>factotum</TT>
+does all the negotiation for security and authentication.
+Programs no longer need to be compiled with cryptographic
+code; instead they communicate with
+<TT>factotum</TT>
+agents
+that represent distinct entities in the cryptographic exchange,
+such as a user and server of a secure service.
+If a security protocol needs to be added, deleted, or modified,
+only
+<TT>factotum</TT>
+needs to be updated for all system services
+to be kept secure.
+<br>&#32;<br>
+Building on
+<TT>factotum</TT>,
+we modified
+secure services in the system to move
+user authentication code into
+<TT>factotum</TT>;
+made authentication a separable component of the file server protocol;
+deployed new security protocols;
+designed a secure file store,
+called
+<TT>secstore</TT>,
+to protect our keys but make them easy to get when they are needed;
+designed a new kernel module to support transparent use of 
+Transport Layer Security (TLS)
+[RFC2246];
+and began using encryption for all communications within the system.
+The overall architecture is illustrated in Figure 1a.
+<br><img src="-.19111511.gif"><br>
+<DL><DT><DD><TT><PRE>
+<br><img src="-.19111512.gif"><br>
+</PRE></TT></DL>
+<br>&#32;<br>
 Figure 1a.  Components of the security architecture.
 Each box is a (typically) separate machine; each ellipse a process.
-The ellipses labeled <I>F</I><I>X</I>
+n(11The ellipses labeled &lt;I&gt;F&lt;/I&gt;&lt;I&gt;X&lt;/I&gt;n(99
 are
 <TT>factotum</TT>
 processes; those labeled
-<I>P</I><I>X</I>
+n(11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;X&lt;/I&gt;n(99
 are the pieces and proxies of a distributed program.
 The authentication server is one of several repositories for users' security information
 that
@@ -50,433 +176,1921 @@ processes consult as required.
 is a shared resource for storing private information such as keys;
 <TT>factotum</TT>
 consults it for the user during bootstrap.
-<P>
-Secure protocols and algorithms are well understood and are usually not the weakest link in a system's security. In practice, most security problems arise from buggy servers, confusing software, or administrative oversights. It is these practical problems that we are addressing. Although this paper describes the algorithms and protocols we are using, they are included mainly for concreteness. Our main intent is to present a simple security architecture built upon a small trusted code base that is easy to verify (whether by manual or automatic means), easy to understand, and easy to use.
-  <P>
-Although it is a subjective assessment, we believe we have achieved our goal of ease of use. That we have achieved our goal of improved security is supported by our plan to move our currently private computing environment onto the Internet outside the corporate firewall. The rest of this paper explains the architecture and how it is used, to explain why a system that is easy to use securely is also safe enough to run in the open network.
-<H4>2. An Agent for Security
-</H4>  <P>
-One of the primary reasons for the redesign of the Plan 9 security infrastructure was to remove the authentication method both from the applications and from the kernel. Cryptographic code is large and intricate, so it should be packaged as a separate component that can be repaired or modified without altering or even relinking applications and services that depend on it. If a security protocol is broken, it should be trivial to repair, disable, or replace it on the fly. Similarly, it should be possible for multiple programs to use a common security protocol without embedding it in each program.
-  <P>
-Some systems use dynamically linked libraries (DLLs) to address these configuration issues. The problem with this approach is that it leaves security code in the same address space as the program using it. The interactions between the program and the DLL can therefore accidentally or deliberately violate the interface, weakening security. Also, a program using a library to implement secure services must run at a privilege level necessary to provide the service; separating the security to a different program makes it possible to run the services at a weaker privilege level, isolating the privileged code to a single, more trustworthy component.
-  <P>
-Following the lead of the SSH agent [Ylon96], we give each user an agent process responsible for holding and using the user's keys. The agent program is called <TT>factotum</TT> because of its similarity to the proverbial servant with the power to act on behalf of his master because he holds the keys to all the master's possessions. It is essential that <TT>factotum</TT> keep the keys secret and use them only in the owner's interest. Later we'll discuss some changes to the kernel to reduce the possibility of <TT>factotum</TT> leaking information inadvertently.
-  <P>
-<TT>Factotum</TT> is implemented, like most Plan 9 services, as a file server. It is conventionally mounted upon the directory <TT>/mnt/factotum</TT>, and the files it serves there are analogous to virtual devices that provide access to, and control of, the services of the <TT>factotum</TT>. The next few sections describe the design of <TT>factotum</TT> and how it operates with the other pieces of Plan 9 to provide security services.
-<H4>2.1. Logging in
+<br>&#32;<br>
+<br><img src="-.19111513.gif"><br>
+<br>&#32;<br>
+Secure protocols and algorithms are well understood
+and are usually not the weakest link in a system's security.
+In practice, most security problems arise from buggy servers,
+confusing software, or administrative oversights.
+It is these practical problems that we are addressing.
+Although this paper describes the algorithms and protocols we are using,
+they are included mainly for concreteness.
+Our main intent is to present a simple security architecture built
+upon a small trusted code base that is easy to verify (whether by manual or
+automatic means), easy to understand, and easy to use.
+<br>&#32;<br>
+Although it is a subjective assessment,
+we believe we have achieved our goal of ease of use.
+That we have achieved
+our goal of improved security is supported by our plan to
+move our currently private computing environment onto the Internet
+outside the corporate firewall.
+The rest of this paper explains the architecture and how it is used,
+to explain why a system that is easy to use securely is also safe
+enough to run in the open network.
+<H4>2 An Agent for Security
 </H4>
-To make the discussions that follow more concrete, we begin with a couple of examples showing how the Plan 9 security architecture appears to the user. These examples both involve a user <TT>gre</TT> logging in after booting a local machine. The user may or may not have a secure store in which all his keys are kept. If he does, <TT>factotum</TT> will prompt him for the password to the secure store and obtain keys from it, prompting only when a key isn't found in the store. Otherwise, <TT>factotum</TT> must prompt for each key.
-  <P>
-In the typescripts, <TT>\n</TT> represents a literal newline character typed to force a default response. User input is in italics, and long lines are folded and indented to fit.<br>
-  <P>
-This first example shows a user logging in without help from the secure store. First, <TT>factotum</TT> prompts for a user name that the local kernel will use:
-<pre>
-    user[none]: <em>gre</em>
-</pre>
-(Default responses appear in square brackets.) The kernel then starts accessing local resources and requests, through <TT>factotum</TT>, a user/password pair to do so:
-<pre>
-    !Adding key: dom=cs.bell-labs.com proto=p9sk1
-    user[gre]: <em>\n</em>
-    password: ****
-</pre>
-Now the user is logged in to the local system, and the mail client starts up:
-<pre>
-    !Adding key: proto=apop server=plan9.bell-labs.com
-    user[gre]: <em>\n</em>
-    password: <em>****</em>
-</pre>
-<TT>Factotum</TT> is doing all the prompting and the applications being started are not even touching the keys. Note that it's always clear which key is being requested.<br>
-  <P>
-Now consider the same login sequence, but in the case where <TT>gre</TT> has a secure store account:
-<pre>
-    user[none]: gre
-    secstore password: <em>*********</em>
-    STA PIN+SecurID: <em>*********</em>
-</pre>
-That's the last <TT>gre </TT>will hear from <TT>factotum </TT>unless an attempt is made to contact a system for which no key is kept in the secure store.<br>
-<H4>2.2. The factotum
+<br>&#32;<br>
+One of the primary reasons for the redesign of the Plan 9
+security infrastructure was to remove the authentication
+method both from the applications and from the kernel.
+Cryptographic code
+is large and intricate, so it should
+be packaged as a separate component that can be repaired or
+modified without altering or even relinking applications
+and services that depend on it.
+If a security protocol is broken, it should be trivial to repair,
+disable, or replace it on the fly.
+Similarly, it should be possible for multiple programs to use
+a common security protocol without embedding it in each program.
+<br>&#32;<br>
+Some systems use dynamically linked libraries (DLLs) to address these configuration issues.
+The problem with this approach is that it leaves
+security code in the same address space as the program using it.
+The interactions between the program and the DLL
+can therefore accidentally or deliberately violate the interface,
+weakening security.
+Also, a program using a library to implement secure services
+must run at a privilege level necessary to provide the service;
+separating the security to a different program makes it possible
+to run the services at a weaker privilege level, isolating the
+privileged code to a single, more trustworthy component.
+<br>&#32;<br>
+Following the lead of the SSH agent
+[Ylon96],
+we give each user
+an agent process responsible
+for holding and using the user's keys.
+The agent program is called
+<TT>factotum</TT>
+because of its similarity to the proverbial servant with the
+power to act on behalf of his master because he holds the
+keys to all the master's possessions.  It is essential that
+<TT>factotum</TT>
+keep the keys secret and use them only in the owner's interest.
+Later we'll discuss some changes to the kernel to reduce the possibility of
+<TT>factotum</TT>
+leaking information inadvertently.
+<br>&#32;<br>
+<TT>Factotum</TT>
+is implemented, like most Plan 9 services, as a file server.
+It is conventionally mounted upon the directory
+<TT>/mnt/factotum</TT>,
+and the files it serves there are analogous to virtual devices that provide access to,
+and control of, the services of the
+<TT>factotum</TT>.
+The next few sections describe the design of
+<TT>factotum</TT>
+and how it operates with the other pieces of Plan 9 to provide
+security services.
+<H4>2.1 Logging in
 </H4>
-Each computer running Plan 9 has one user id that owns all the resources on that system -- the scheduler, local disks, network interfaces, etc. That user, the <EM>host owner</EM>, is the closest analogue in Plan 9 to a Unix <TT>root</TT> account (although it is far weaker; rather than having special powers, as its name implies the host owner is just a regular user that happens to own the resources of the local machine). On a single-user system, which we call a terminal, the host owner is the id of the terminal's user. Shared servers such as CPU servers normally have a pseudo-user that initially owns all resources. At boot time, the Plan 9 kernel starts a <TT>factotum</TT> executing as, and therefore with the privileges of, the host owner.
-  <P>
-New processes run as the same user as the process which created them. When a process must take on the identity of a new user, such as to provide a login shell on a shared CPU server, it does so by proving to the host owner's <TT>factotum</TT> that it is authorized to do so. This is done by running an authentication protocol with <TT>factotum</TT> to prove that the process has access to secret information which only the new user should possess. For example, consider the setup in Figure 1a. If a user on the terminal wants to log in to the CPU server using the Plan 9 <TT>cpu</TT> service [Pike93], then <EM>PT </EM>might be the <TT>cpu</TT> client program and <EM>PC </EM>the <TT>cpu</TT> server. Neither <EM>PC </EM>nor <EM>PT </EM>knows the details of the authentication. They do need to be able to shuttle messages back and forth between the two <TT>factotums</TT>, but this is a generic function easily performed without knowing, or being able to extract, secrets in the messages. <EM>PT </EM>will make a network connection to <EM>PC</EM>. <EM>PT </EM>and <EM>PC </EM>will then relay messages between the <TT>factotum</TT> owned by the user, <EM>FT</EM>, and the one owned by the CPU server, <EM>FC</EM>, until mutual authentication has been established. Later sections describe the RPC between <TT>factotum</TT> and applications and the library functions to support proxy operations.
-  <P>
-The kernel always uses a single local instance of <TT>factotum</TT>, running as the host owner, for its authentication purposes, but a regular user may start other <TT>factotum</TT> agents. In fact, the <TT>factotum</TT> representing the user need not be running on the same machine as its client. For instance, it is easy for a user on a CPU server, through standard Plan 9 operations, to replace the <TT>/mnt/factotum</TT> in the user's private file name space on the server with a connection to the <TT>factotum</TT> running on the terminal. (The usual file system permissions prevent interlopers from doing so maliciously.) This permits secure operations on the CPU server to be transparently validated by the user's own <TT>factotum</TT>, so secrets need never leave the user's terminal. The SSH agent [Ylon96] does much the same with special SSH protocol messages, but an advantage to making our agent a file system is that we need no new mechanism to access our remote agent; remote file access is sufficient.
-  <P>
-Within <TT>factotum</TT>, each protocol is implemented as a state machine with a generic interface, so protocols are in essence pluggable modules, easy to add, modify, or drop. Writing a message to and reading a message from <TT>factotum</TT> each require a separate RPC and result in a single state transition. Therefore <TT>factotum</TT> always runs to completion on every RPC and never blocks waiting for input during any authentication. Moreover, the number of simultaneous authentications is limited only by the amount of memory we're willing to dedicate to representing the state machines.
-  <P>
-Authentication protocols are implemented only within <TT>factotum</TT>, but adding and removing protocols does require relinking the binary, so <TT>factotum</TT> processes (but no others) need to be restarted in order to take advantage of new or repaired protocols.<br>
-  <P>
-At the time of writing, <TT>factotum</TT> contains authentication modules for the Plan 9 shared key protocol (p9sk1), SSH's RSA authentication, passwords in the clear, APOP, CRAM, PPP's CHAP, Microsoft PPP's MSCHAP, and VNC's challenge/response.<br>
-<H4>2.3. Local capabilities
+<br>&#32;<br>
+To make the discussions that follow more concrete,
+we begin with a couple of examples showing how the
+Plan 9 security architecture appears to the user.
+These examples both involve a user
+<TT>gre</TT>
+logging in after booting a local machine.
+The user may or may not have a secure store in which
+all his keys are kept.
+If he does,
+<TT>factotum</TT>
+will prompt him for the password to the secure store
+and obtain keys from it, prompting only when a key
+isn't found in the store.
+Otherwise,
+<TT>factotum</TT>
+must prompt for each key.
+<br>&#32;<br>
+In the typescripts, \n
+represents a literal newline
+character typed to force a default response.
+User input is in italics, and
+long lines are folded and indented to fit.
+<br>&#32;<br>
+This first example shows a user logging in without
+help from the secure store.
+First,
+<TT>factotum</TT>
+prompts for a user name that the local kernel
+will use:
+<DL><DT><DD><TT><PRE>
+user[none]: gre
+</PRE></TT></DL>
+(Default responses appear in square brackets.)
+The kernel then starts accessing local resources
+and requests, through
+<TT>factotum</TT>,
+a user/password pair to do so:
+<DL><DT><DD><TT><PRE>
+!Adding key: dom=cs.bell-labs.com
+    proto=p9sk1
+user[gre]: \n
+password: ****
+</PRE></TT></DL>
+Now the user is logged in to the local system, and
+the mail client starts up:
+<DL><DT><DD><TT><PRE>
+!Adding key: proto=apop
+    server=plan9.bell-labs.com
+user[gre]: \n
+password: ****
+</PRE></TT></DL>
+<TT>Factotum</TT>
+is doing all the prompting and the applications
+being started are not even touching the keys.
+Note that it's always clear which key is being requested.
+<br>&#32;<br>
+Now consider the same login sequence, but in the case where
+<TT>gre</TT>
+has a secure store account:
+<DL><DT><DD><TT><PRE>
+user[none]: gre
+secstore password: *********
+STA PIN+SecurID: *********
+</PRE></TT></DL>
+That's the last
+<TT>gre</TT>
+will hear from
+<TT>factotum</TT>
+unless an attempt is made to contact
+a system for which no key is kept in the secure store.
+<H4>2.2 The factotum
+</H4>
+<br>&#32;<br>
+Each computer running Plan 9 has one user id that owns all the
+resources on that system &#173; the scheduler, local disks,
+network interfaces, etc.
+That user, the
+<I>host owner</I>,
+is the closest analogue in Plan 9 to a Unix
+<TT>root</TT>
+account (although it is far weaker;
+rather than having special powers, as its name implies the host owner
+is just a regular user that happens to own the
+resources of the local machine).
+On a single-user system, which we call a terminal,
+the host owner is the id of the terminal's user.
+Shared servers such as CPU servers normally have a pseudo-user
+that initially owns all resources.
+At boot time, the Plan 9 kernel starts a
+<TT>factotum</TT>
+executing as, and therefore with the privileges of,
+the host owner.
+<br>&#32;<br>
+New processes run as
+the same user as the process which created them.
+When a process must take on the identity of a new user,
+such as to provide a login shell
+on a shared CPU server,
+it does so by proving to the host owner's
+<TT>factotum</TT>
+that it is
+authorized to do so.
+This is done by running an
+authentication protocol with
+<TT>factotum</TT>
+to
+prove that the process has access to secret information
+which only the new user should possess.
+For example, consider the setup in Figure 1a.
+If a user on the terminal
+wants to log in to the CPU server using the
+Plan 9
+<TT>cpu</TT>
+service
+[Pike93],
+then
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
+might be the
+<TT>cpu</TT>
+client program and
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
+the
+<TT>cpu</TT>
+server.
+n(11Neither 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99 nor 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
+knows the details of the authentication.
+They
+do need to be able to shuttle messages back and
+forth between the two
+<TT>factotums</TT>,
+but this is
+a generic function easily performed without
+knowing, or being able to extract, secrets in
+the messages.
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
+n(11will make a network connection to 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99.
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
+and
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
+will then relay messages between
+the
+<TT>factotum</TT>
+n(11owned by the user, 11&lt;I&gt;F&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99,
+n(11and the one owned by the CPU server, 11&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99,
+until mutual authentication has been established.
+Later
+sections describe the RPC between
+<TT>factotum</TT>
+and
+applications and the library functions to support proxy operations.
+<br>&#32;<br>
+The kernel always uses a single local instance of
+<TT>factotum</TT>,
+running as the
+host owner, for
+its authentication purposes, but
+a regular user may start other
+<TT>factotum</TT>
+agents.
+In fact, the
+<TT>factotum</TT>
+representing the user need not be
+running on the same machine as its client.
+For instance, it is easy for a user on a CPU server,
+through standard Plan 9 operations,
+to replace the
+<TT>/mnt/factotum</TT>
+in the user's private file name space on the server
+with a connection to the
+<TT>factotum</TT>
+running on the terminal.
+(The usual file system permissions prevent interlopers
+from doing so maliciously.)
+This permits secure operations on the CPU server to be
+transparently validated by the user's own
+<TT>factotum</TT>,
+so
+secrets need never leave the user's terminal.
+The SSH agent
+[Ylon96]
+does much the
+same with special SSH protocol messages, but
+an advantage to making our agent a file system
+is that we need no new mechanism to access our remote
+agent; remote file access is sufficient.
+<br>&#32;<br>
+Within
+<TT>factotum</TT>,
+each protocol is implemented as a state
+machine with a generic interface, so protocols are in
+essence pluggable modules, easy to add, modify, or drop.
+Writing a message to and reading a message from
+<TT>factotum</TT>
+each require a separate RPC and result in
+a single state transition.
+Therefore
+<TT>factotum</TT>
+always runs to completion on every RPC and never blocks
+waiting for input during any authentication.
+Moreover, the number of simultaneous
+authentications is limited only by the amount of memory we're
+willing to dedicate to representing the state machines.
+<br>&#32;<br>
+Authentication protocols are implemented only
+within
+<TT>factotum</TT>,
+but adding and removing
+protocols does require relinking the binary, so
+<TT>factotum</TT>
+processes (but no others)
+need to be restarted in order to take advantage of
+new or repaired protocols.
+<br>&#32;<br>
+At the time of writing, 
+<TT>factotum</TT>
+contains authentication
+modules for the Plan 9 shared key protocol (p9sk1),
+SSH's RSA authentication, passwords in the clear, APOP, CRAM, PPP's CHAP,
+Microsoft PPP's MSCHAP, and VNC's challenge/response.
+<H4>2.3 Local capabilities
 </H4>
-A capability system, managed by the kernel, is used to empower <TT>factotum</TT> to grant permission to another process to change its user id. A kernel device driver implements two files, <TT>/dev/caphash</TT> and <TT>/dev/capuse</TT>. The write-only file <TT>/dev/caphash</TT> can be opened only by the host owner, and only once. <TT>Factotum</TT> opens this file immediately after booting.
-  <P>
-To use the files, <TT>factotum</TT> creates a string of the form <EM>userid1</EM><TT>@</TT><EM>userid2</EM><TT>@</TT><EM>random-string</EM>, uses SHA1 HMAC to hash <EM>userid1</EM><TT>@</TT><EM>userid2 </EM>with key <EM>random-string</EM>, and writes that hash to <TT>/dev/caphash</TT>. <TT>Factotum</TT> then passes the original string to another process on the same machine, running as user <EM>userid1</EM>, which writes the string to <TT>/dev/capuse</TT>. The kernel hashes the string and looks for a matching hash in its list. If it finds one, the writing process's user id changes from <EM>userid1 </EM>to <EM>userid2</EM>. Once used, or if a timeout expires, the capability is discarded by the kernel.
-  <P>
-The capabilities are local to the machine on which they are created. Hence a <TT>factotum</TT> running on one machine cannot pass capabilities to processes on another and expect them to work.<br>
-<H4>2.4. Keys
+<br>&#32;<br>
+A capability system, managed by the kernel, is used to empower
+<TT>factotum</TT>
+to grant permission to another process to change its user id.
+A
+kernel device driver
+implements two files,
+<TT>/dev/caphash</TT>
+and
+<TT>/dev/capuse</TT>.
+The write-only file
+<TT>/dev/caphash</TT>
+can be opened only by the host owner, and only once.
+<TT>Factotum</TT>
+opens this file immediately after booting.
+<br>&#32;<br>
+To use the files,
+<TT>factotum</TT>
+creates a string of the form
+<I>userid1</I><TT>@</TT><I>userid2</I><TT>@</TT><I>random-string</I><TT>,
+uses SHA1 HMAC to hash
+</TT><I>userid1</I><TT>@</TT><I>userid2</I><TT>
+with key
+</TT><I>random-string</I><TT>,
+and writes that hash to
+</TT><TT>/dev/caphash</TT><TT>.
+</TT><TT>Factotum</TT><TT>
+then passes the original string to another
+process on the same machine, running
+as user
+</TT><I>userid1</I><TT>,
+which
+writes the string to
+</TT><TT>/dev/capuse</TT><TT>.
+The kernel hashes the string and looks for
+a matching hash in its list.
+If it finds one,
+the writing process's user id changes from
+</TT><I>userid1</I><TT>
+to
+</TT><I>userid2</I><TT>.
+Once used, or if a timeout expires,
+the capability is discarded by the kernel.
+</TT><br>&#32;<br>
+The capabilities are local to the machine on which they are created.
+Hence a
+<TT>factotum</TT>
+running on one machine cannot pass capabilities
+to processes on another and expect them to work.
+<H4>2.4 Keys
 </H4>
-We define the word <EM>key </EM>to mean not only a secret, but also a description of the context in which that secret is to be used: the protocol, server, user, etc. to which it applies. That is, a key is a combination of secret and descriptive information used to authenticate the identities of parties transmitting or receiving information. The set of keys used in any authentication depends both on the protocol and on parameters passed by the program requesting the authentication.
-  <P>
-Taking a tip from SDSI [RiLa], which represents security information as textual S-expressions, keys in Plan 9 are represented as plain UTF-8 text. Text is easily understood and manipulated by users. By contrast, a binary or other cryptic format can actually reduce overall security. Binary formats are difficult for users to examine and can only be cracked by special tools, themselves poorly understood by most users. For example, very few people know or understand what's inside their X.509 certificates. Most don't even know where in the system to find them. Therefore, they have no idea what they are trusting, and why, and are powerless to change their trust relationships. Textual, centrally stored and managed keys are easier to use and safer.
-  <P>
-Plan 9 has historically represented databases as attribute/value pairs, since they are a good foundation for selection and projection operations. <TT>Factotum</TT> therefore represents the keys in the format <EM>attribute</EM><TT>=</TT><EM>value</EM>, where <EM>attribute </EM>is an identifier, possibly with a single-character prefix, and <EM>value </EM>is an arbitrary quoted string. The pairs themselves are separated by white space. For example, a Plan 9 key and an APOP key might be represented like this:
-<pre>
-    dom=bell-labs.com proto=p9sk1 user=gre !password='don''t tell'
-    proto=apop server=x.y.com user=gre !password='open sesame'
-</pre>
-If a value is empty or contains white space or single quotes, it must be quoted; quotes are represented by doubled single quotes. Attributes that begin with an exclamation mark (<TT>!</TT>) are considered <EM>secret</EM>. <TT>Factotum</TT> will never let a secret value escape its address space and will suppress keyboard echo when asking the user to type one.
-  <P>
-A program requesting authentication selects a key by providing a <EM>query</EM>, a list of elements to be matched by the key. Each element in the list is either an <EM>attribute</EM><TT>=</TT><EM>value </EM>pair, which is satisfied by keys with exactly that pair; or an attribute followed by a question mark, <EM>attribute</EM><TT>?</TT>, which is satisfied by keys with some pair specifying the attribute. A key matches a query if every element in the list is satisfied. For instance, to select the APOP key in the previous example, an APOP client process might specify the query
-<DL><DT><DD><TT>server=x.y.com proto=apop<br>
-</TT></DL>Internally, <TT>factotum</TT>'s APOP module would add the requirements of having <TT>user </TT>and <TT>!password </TT>attributes, forming the query<br>
-<DL><DT><DD><TT>server=x.y.com proto=apop user? !password?<br>
-</TT></DL>when searching for an appropriate key.<br>
-  <P>
-<TT>Factotum</TT> modules expect keys to have some well-known attributes. For instance, the <TT>proto</TT> attribute specifies the protocol module responsible for using a particular key, and protocol modules may expect other well-known attributes (many expect keys to have <TT>!password</TT> attributes, for example). Additional attributes can be used as comments or for further discrimination without intervention by <TT>factotum</TT>; for example, the APOP and IMAP mail clients conventionally include a <TT>server</TT> attribute to select an appropriate key for authentication.
-  <P>
-Unlike in SDSI, keys in Plan 9 have no nested structure. This design keeps the representation simple and straightforward. If necessary, we could add a nested attribute or, in the manner of relational databases, an attribute that selects another tuple, but so far the simple design has been sufficient.
-  <P>
-A simple common structure for all keys makes them easy for users to administer, but the set of attributes and their interpretation is still protocol-specific and can be subtle. Users may still need to consult a manual to understand all details. Many attributes (<TT>proto</TT>, <TT>user</TT>, <TT>password</TT>, <TT>server</TT>) are self-explanatory and our short experience has not uncovered any particular difficulty in handling keys. Things will likely get messier, however, when we grapple with public keys and their myriad components.
-<H4>2.5. Protecting keys
+<br>&#32;<br>
+We define the word
+<I>key</I>
+to mean not only a secret, but also a description of the
+context in which that secret is to be used: the protocol,
+server, user, etc. to which it applies.
+That is,
+a key is a combination of secret and descriptive information
+used to authenticate the identities of parties
+transmitting or receiving information.
+The set of keys used
+in any authentication depends both on the protocol and on
+parameters passed by the program requesting the authentication.
+<br>&#32;<br>
+Taking a tip from SDSI
+[RiLa],
+which represents security information as textual S-expressions,
+keys in Plan 9 are represented as plain UTF-8 text.
+Text is easily
+understood and manipulated by users.
+By contrast,
+a binary or other cryptic format
+can actually reduce overall security.
+Binary formats are difficult for users to examine and can only be
+cracked by special tools, themselves poorly understood by most users.
+For example, very few people know or understand what's inside
+their X.509 certificates.
+Most don't even know where in the system to
+find them.
+Therefore, they have no idea what they are trusting, and why, and
+are powerless to change their trust relationships.
+Textual, centrally stored and managed keys are easier to use and safer.
+<br>&#32;<br>
+Plan 9 has historically represented databases as attribute/value pairs,
+since they are a good foundation for selection and projection operations.
+<TT>Factotum</TT>
+therefore represents
+the keys in the format
+<I>attribute</I><TT>=</TT><I>value</I><TT>,
+where
+</TT><I>attribute</I><TT>
+is an identifier, possibly with a single-character prefix, and
+</TT><I>value</I><TT>
+is an arbitrary quoted string.
+The pairs themselves are separated by white space.
+For example, a Plan 9 key and an APOP key
+might be represented like this:
+<DL><DT><DD><TT><PRE>
+dom=bell-labs.com proto=p9sk1 user=gre
+	!password='don''t tell'
+proto=apop server=x.y.com user=gre
+	!password='open sesame'
+</PRE></TT></DL>
+If a value is empty or contains white space or single quotes, it must be quoted;
+quotes are represented by doubled single quotes.
+Attributes that begin with an exclamation mark
+(</TT><TT>!</TT><TT>)
+are considered
+</TT><I>secret</I><TT>.
+</TT><TT>Factotum</TT><TT>
+will never let a secret value escape its address space
+and will suppress keyboard echo when asking the user to type one.
+</TT><br>&#32;<br>
+A program requesting authentication selects a key
+by providing a
+<I>query</I>,
+a list of elements to be matched by the key.
+Each element in the list is either an
+<I>attribute</I><TT>=</TT><I>value</I><TT>
+pair, which is satisfied by keys with
+exactly that pair;
+or an attribute followed by a question mark,
+</TT><I>attribute</I><TT>?</TT><I>,
+which is satisfied by keys with some pair specifying
+the attribute.
+A key matches a query if every element in the list
+is satisfied.
+For instance, to select the APOP key in the previous example,
+an APOP client process might specify the query
+<DL><DT><DD><TT><PRE>
+server=x.y.com proto=apop
+</PRE></TT></DL>
+Internally,
+</I><TT>factotum</TT><I>'s
+APOP module would add the requirements of
+having
+</I><TT>user</TT><I>
+and
+</I><TT>!password</TT><I>
+attributes, forming the query
+<DL><DT><DD><TT><PRE>
+server=x.y.com proto=apop user? !password?
+</PRE></TT></DL>
+when searching for an appropriate key.
+</I><br>&#32;<br>
+<TT>Factotum</TT>
+modules expect keys to have some well-known attributes.
+For instance, the
+<TT>proto</TT>
+attribute specifies the protocol module
+responsible for using a particular key,
+and protocol modules may expect other well-known attributes
+(many expect keys to have
+<TT>!password</TT>
+attributes, for example).
+Additional attributes can be used as comments or for
+further discrimination without intervention by 
+<TT>factotum</TT>;
+for example, the APOP and IMAP mail clients conventionally
+include a
+<TT>server</TT>
+attribute to select an appropriate key for authentication.
+<br>&#32;<br>
+Unlike in SDSI,
+keys in Plan 9 have no nested structure.  This design
+keeps the representation simple and straightforward.
+If necessary, we could add a nested attribute
+or, in the manner of relational databases, an attribute that
+selects another tuple, but so far the simple design has been sufficient.
+<br>&#32;<br>
+A simple common structure for all keys makes them easy for users
+to administer,
+but the set of attributes and their interpretation is still
+protocol-specific and can be subtle.
+Users may still
+need to consult a manual to understand all details.
+Many attributes
+(<TT>proto</TT>,
+<TT>user</TT>,
+<TT>password</TT>,
+<TT>server</TT>)
+are self-explanatory and our short experience
+has not uncovered any particular difficulty in handling keys.
+Things
+will likely get messier, however,
+when we grapple with public
+keys and their myriad components.
+<H4>2.5 Protecting keys
 </H4>
-Secrets must be prevented from escaping <TT>factotum</TT>. There are a number of ways they could leak: another process might be able to debug the agent process, the agent might swap out to disk, or the process might willingly disclose the key. The last is the easiest to avoid: secret information in a key is marked as such, and whenever <TT>factotum</TT> prints keys or queries for new ones, it is careful to avoid displaying secret information. (The only exception to this is the ``plaintext password'' protocol, which consists of sending the values of the <TT>user</TT> and <TT>!password</TT> attributes. Only keys tagged with <TT>proto=pass</TT> can have their passwords disclosed by this mechanism.)
-  <P>
-Preventing the first two forms of leakage requires help from the kernel. In Plan 9, every process is represented by a directory in the <TT>/proc</TT> file system. Using the files in this directory, other processes could (with appropriate access permission) examine <TT>factotum</TT>'s memory and registers. <TT>Factotum</TT> is protected from processes of other users by the default access bits of its <TT>/proc</TT> directory. However, we'd also like to protect the agent from other processes owned by the same user, both to avoid honest mistakes and to prevent an unattended terminal being exploited to discover secret passwords. To do this, we added a control message to <TT>/proc</TT> called <TT>private</TT>. Once the <TT>factotum</TT> process has written <TT>private</TT> to its <TT>/proc/</TT><EM>pid</EM><TT>/ctl</TT> file, no process can access <TT>factotum</TT>'s memory through <TT>/proc</TT>. (Plan 9 has no other mechanism, such as <TT>/dev/kmem</TT>, for accessing a process's memory.)
-  <P>
-Similarly, the agent's address space should not be swapped out, to prevent discovering unencrypted keys on the swapping media. The <TT>noswap</TT> control message in <TT>/proc</TT> prevents this scenario. Neither <TT>private</TT> nor <TT>noswap</TT> is specific to <TT>factotum</TT>. User-level file servers such as <TT>dossrv</TT>, which interprets FAT file systems,
-could use <TT>noswap</TT>
+<br>&#32;<br>
+Secrets must be prevented from escaping
+<TT>factotum</TT>.
+There are a number of ways they could leak:
+another process might be able to debug the agent process, the
+agent might swap out to disk, or the process might willingly
+disclose the key.
+The last is the easiest to avoid:
+secret information in a key is marked
+as such, and
+whenever
+<TT>factotum</TT>
+prints keys or queries for new
+ones, it is careful to avoid displaying secret information.
+(The only exception to this is the
+``plaintext password'' protocol, which consists
+of sending the values of the
+<TT>user</TT>
+and
+<TT>!password</TT>
+attributes.
+Only keys tagged with
+<TT>proto=pass</TT>
+can have their passwords disclosed by this mechanism.)
+<br>&#32;<br>
+Preventing the first two forms of leakage
+requires help from the kernel.
+In Plan 9, every process is
+represented by a directory in the
+<TT>/proc</TT>
+file system.
+Using the files in this directory,
+other processes could (with appropriate access permission) examine
+<TT>factotum</TT>'s
+memory and registers.
+<TT>Factotum</TT>
+is protected from processes of other users
+by the default access bits of its
+<TT>/proc</TT>
+directory.
+However, we'd also like to protect the
+agent from other processes owned by the same user,
+both to avoid honest mistakes and to prevent
+an unattended terminal being
+exploited to discover secret passwords.
+To do this, we added a control message to
+<TT>/proc</TT>
+called
+<TT>private</TT>.
+Once the
+<TT>factotum</TT>
+process has written
+<TT>private</TT>
+to its
+<TT>/proc/</TT><I>pid</I><TT>/ctl</TT><I>
+file, no process can access
+</I><TT>factotum</TT><I>'s
+memory
+through
+</I><TT>/proc</TT><I>.
+(Plan 9 has no other mechanism, such as
+</I><TT>/dev/kmem</TT><I>,
+for accessing a process's memory.)
+</I><br>&#32;<br>
+Similarly, the agent's address space should not be
+swapped out, to prevent discovering unencrypted
+keys on the swapping media.
+The
+<TT>noswap</TT>
+control message in
+<TT>/proc</TT>
+prevents this scenario.
+Neither
+<TT>private</TT>
+nor
+<TT>noswap</TT>
+is specific to
+<TT>factotum</TT>.
+User-level file servers such as
+<TT>dossrv</TT>,
+which interprets FAT file systems,
+could use
+<TT>noswap</TT>
 to keep their buffer caches from being
 swapped to disk.
-  <P>
-Despite our precautions, attackers might still find a way to gain access to a process running as the host owner on a machine. Although they could not directly access the keys, attackers could use the local <TT>factotum</TT> to perform authentications for them. In the case of some keys, for example those locking bank accounts, we want a way to disable or at least detect such access. That is the role of the <TT>confirm</TT> attribute in a key. Whenever a key with a <TT>confirm</TT> attribute is accessed, the local user must confirm use of the key via a local GUI. The next section describes the actual mechanism.
-  <P>
-We have not addressed leaks possible as a result of someone rebooting or resetting a machine running <TT>factotum</TT>. For example, someone could reset a machine and reboot it with a debugger instead of a kernel, allowing them to examine the contents of memory and find keys. We have not found a satisfactory solution to this problem.
-<H4>2.6. Factotum transactions
+<br>&#32;<br>
+Despite our precautions, attackers might still
+find a way to gain access to a process running as the host
+owner on a machine.
+Although they could not directly
+access the keys, attackers could use the local
+<TT>factotum</TT>
+to perform authentications for them.
+In the case
+of some keys, for example those locking bank
+accounts, we want a way to disable or at least
+detect such access.
+That is the role of the
+<TT>confirm</TT>
+attribute in a key.
+Whenever a key with a
+<TT>confirm</TT>
+attribute is accessed, the local user must
+confirm use of the key via a local GUI.
+The next section describes the actual mechanism.
+<br>&#32;<br>
+We have not addressed leaks possible as a result of
+someone rebooting or resetting a machine running
+<TT>factotum</TT>.
+For example, someone could reset a machine
+and reboot it with a debugger instead of a kernel,
+allowing them to examine the contents of memory
+and find keys.  We have not found a satisfactory
+solution to this problem.
+<H4>2.6 Factotum transactions
 </H4>
-External programs manage <TT>factotum</TT>'s internal key state through its file interface, writing textual <TT>key</TT> and <TT>delkey</TT> commands to the <TT>/mnt/factotum/ctl</TT> file. Both commands take a list of attributes as an argument. <TT>Key</TT> creates a key with the given attributes, replacing any extant key with an identical set of public attributes. <TT>Delkey</TT> deletes all keys that match the given set of attributes. Reading the <TT>ctl</TT> file returns a list of keys, one per line, displaying only public attributes. The following example illustrates these interactions.
-<pre>
-    % cd /mnt/factotum
-    % ls -l
-    -lrw------- gre gre 0 Jan 30 22:17 confirm
-    --rw------- gre gre 0 Jan 30 22:17 ctl
-    -lr-------- gre gre 0 Jan 30 22:17 log
-    -lrw------- gre gre 0 Jan 30 22:17 needkey
-    --r--r--r-- gre gre 0 Jan 30 22:17 proto
-    --rw-rw-rw- gre gre 0 Jan 30 22:17 rpc
-    % cat &gt;ctl
-    key dom=bell-labs.com proto=p9sk1 user=gre !password='don''t tell'
-    key proto=apop server=x.y.com user=gre !password='bite me'
-    ^D
-    % cat ctl
-    key dom=bell-labs.com proto=p9sk1 user=gre
-    key proto=apop server=x.y.com user=gre
-    % echo 'delkey proto=apop' &gt;ctl
-    % cat ctl
-    key dom=bell-labs.com proto=p9sk1 user=gre
-    % 
-</pre>(A file with the <TT>l</TT> bit set can be opened by only one process at a time.)<br>
-  <P>
-The heart of the interface is the <TT>rpc</TT> file. Programs authenticate with <TT>factotum</TT> by writing a request to the <TT>rpc</TT> file and reading back the reply; this sequence is called an RPC <EM>transaction</EM>. Requests and replies have the same format: a textual verb possibly followed by arguments, which may be textual or binary. The most common reply verb is <TT>ok</TT>, indicating success. An RPC session begins with a <TT>start</TT> transaction; the argument is a key query as described earlier. Once started, an RPC conversation usually consists of a sequence of <TT>read</TT> and <TT>write</TT> transactions. If the conversation is successful, an <TT>authinfo</TT> transaction will return information about the identities learned during the transaction. The <TT>attr</TT> transaction returns a list of attributes for the current conversation; the list includes any attributes given in the <TT>start</TT> query as well as any public attributes from keys being used.
-  <P>
-As an example of the <TT>rpc</TT> file in action, consider a mail client connecting to a mail server and authenticating using the POP3 protocol's APOP challenge-response command. There are four programs involved: the mail client <EM>PC</EM>, the client <TT>factotum</TT> <EM>FC</EM>, the mail server <EM>PS</EM>, and the server <TT>factotum</TT> <EM>FS</EM>. All authentication computations are handled by the <TT>factotum</TT> processes. The mail programs' role is just to relay messages.
-  <P>
-At startup, the mail server at <TT>x.y.com</TT> begins an APOP conversation with its <TT>factotum</TT> to obtain the banner greeting, which includes a challenge:<br>
-<DL><DT><DD><EM>PS->FS</EM><TT>: start proto=apop role=server<br>
-</TT><EM>FS->PS</EM><TT>: ok<br>
-</TT><EM>PS->FS</EM><TT>: read<br>
-</TT><EM>FS->PS</EM><TT>: ok +OK POP3 </TT><EM>challenge<br>
-</EM></DL>Having obtained the challenge, the server greets the client:<br>
-<DL><DT><DD><EM>PS->PC</EM><TT>: +OK POP3 </TT><EM>challenge<br>
-</EM></DL>The client then uses an APOP conversation with its <TT>factotum</TT> to obtain a response:<br>
-<DL><DT><DD><EM>PC->FC</EM><TT>: start proto=apop role=client server=x.y.com<br>
- </TT><DT><DD><DT><DD><DL><DT><DD></DL><EM>FC->PC</EM><TT>: ok<br>
-</TT><EM>PC->FC</EM><TT>: write +OK POP3 </TT><EM>challenge<br>
-FC->PC</EM><TT>: ok<br>
-</TT><EM>PC->FC</EM><TT>: read<br>
-</TT><EM>FC->PC</EM><TT>: ok APOP gre </TT><EM>response<br>
-</EM></DL><TT>Factotum</TT> requires that <TT>start</TT> requests include a <TT>proto</TT> attribute, and the APOP module requires an additional <TT>role</TT> attribute, but the other attributes are optional and only restrict the key space. Before responding to the <TT>start</TT> transaction, the client <TT>factotum</TT> looks for a key to use for the rest of the conversation. Because of the arguments in the <TT>start</TT> request, the key must have public attributes <TT>proto=apop</TT> and <TT>server=x.y.com</TT>; as mentioned earlier, the APOP module additionally requires that the key have <TT>user</TT> and <TT>!password</TT> attributes. Now that the client has obtained a response from its <TT>factotum</TT>, it echoes that response to the server:
-<DL><DT><DD><EM>PC->PS</EM><TT>: APOP gre </TT><EM>response<br>
-</EM></DL>Similarly, the server passes this message to its <TT>factotum </TT>and obtains another to send back.<br>
-<DL><DT><DD><EM>PS->FS</EM><TT>: write APOP gre </TT><EM>response<br>
-FS->PS</EM><TT>: ok<br>
-</TT><EM>PS->FS</EM><TT>: read<br>
-</TT><EM>FS->PS</EM><TT>: ok +OK welcome<br>
-</TT><EM>PS->PC</EM><TT>: +OK welcome<br>
-</TT></DL>Now the authentication protocol is done, and the server can retrieve information about what the protocol established.<br>
-<DL><DT><DD><EM>PS->FS</EM><TT>: authinfo<br>
-</TT><EM>FS->PS</EM><TT>: ok client=gre <TT>capability=</TT><EM>capability
-</EM><br>
-</TT></DL>The <TT>authinfo</TT> data is a list of <EM>attr</EM><TT>=</TT><EM>value </EM>pairs, here a client user name and a capability. (Protocols that establish shared secrets or provide mutual authentication indicate this by adding appropriate <EM>attr</EM><TT>=</TT><EM>value </EM>pairs.) The capability can be used by the server to change its identity to that of the client, as described earlier. Once it has changed its identity, the server can access and serve the client's mailbox.
-  <P>
-Two more files provide hooks for a graphical <TT>factotum</TT> control interface. The first, <TT>confirm</TT>, allows the user detailed control over the use of certain keys. If a key has a <TT>confirm=</TT> attribute, then the user must approve each use of the key. A separate program with a graphical interface reads from the <TT>confirm</TT> file to see when a confirmation is necessary. The read blocks until a key usage needs to be approved, whereupon it will return a line of the form
-<DL><DT><DD><TT>confirm tag=1</TT> <EM>attributes<br>
-</EM></DL>requesting permission to use the key with those public attributes. The graphical interface then prompts the user for approval and writes back<br>
-<DL><DT><DD><TT>tag=1 answer=yes<br>
-</TT></DL>(or <TT>answer=no</TT>).<br>
-  <P>
-The second file, <TT>needkey</TT>, diverts key requests. In the APOP example, if a suitable key had not been found during the <TT>start</TT> transaction, <TT>factotum</TT> would have indicated failure by returning a response indicating what key was needed:
-<pre>
-    <EM>FC->PC</EM>: needkey proto=apop server=x.y.com user? !password?
-</pre>
-A typical client would then prompt the user for the desired key information, create a new key via the <TT>ctl</TT> file, and then reissue the <TT>start</TT> request. If the <TT>needkey</TT> file is open, then instead of failing, the transaction will block, and the next read from the <TT>/mnt/factotum/needkey</TT> file will return a line of the form
-<DL><DT><DD><TT>needkey tag=1</TT> <EM>attributes<br>
-</EM></DL>The graphical interface then prompts the user for the needed key information, creates the key via the <TT>ctl</TT> file, and writes back <TT>tag=1</TT> to resume the transaction.<br>
-  <P>
-The remaining files are informational and used for debugging. The <TT>proto</TT> file contains a list of supported protocols (to see what protocols the system supports, <TT>cat /mnt/factotum/proto</TT>), and the <TT>log</TT> file contains a log of operations and debugging output enabled by a <TT>debug</TT> control message.
-  <P>
-The next few sections explain how <TT>factotum</TT> is used by system services.<br>
-<H4>3. Authentication in 9P
+<br>&#32;<br>
+External programs manage
+<TT>factotum</TT>'s
+internal key state
+through its file interface,
+writing textual
+<TT>key</TT>
+and
+<TT>delkey</TT>
+commands to the
+<TT>/mnt/factotum/ctl</TT>
+file.
+Both commands take a list of attributes as an argument.
+<TT>Key</TT>
+creates a key with the given attributes, replacing any
+extant key with an identical set of public attributes.
+<TT>Delkey</TT>
+deletes all keys that match the given set of attributes.
+Reading the 
+<TT>ctl</TT>
+file returns a list of keys, one per line, displaying only public attributes.
+The following example illustrates these interactions.
+<DL><DT><DD><TT><PRE>
+% cd /mnt/factotum
+% ls -l
+-lrw------- gre gre 0 Jan 30 22:17 confirm
+--rw------- gre gre 0 Jan 30 22:17 ctl
+-lr-------- gre gre 0 Jan 30 22:17 log
+-lrw------- gre gre 0 Jan 30 22:17 needkey
+--r--r--r-- gre gre 0 Jan 30 22:17 proto
+--rw-rw-rw- gre gre 0 Jan 30 22:17 rpc
+% cat &gt;ctl
+key dom=bell-labs.com proto=p9sk1 user=gre
+    !password='don''t tell'
+key proto=apop server=x.y.com user=gre
+    !password='bite me'
+^D
+% cat ctl
+key dom=bell-labs.com proto=p9sk1 user=gre
+key proto=apop server=x.y.com user=gre
+% echo 'delkey proto=apop' &gt;ctl
+% cat ctl
+key dom=bell-labs.com proto=p9sk1 user=gre
+% 
+</PRE></TT></DL>
+(A file with the
+<TT>l</TT>
+bit set can be opened by only one process at a time.)
+<br>&#32;<br>
+The heart of the interface is the
+<TT>rpc</TT>
+file.
+Programs authenticate with
+<TT>factotum</TT>
+by writing a request to the
+<TT>rpc</TT>
+file
+and reading back the reply; this sequence is called an RPC
+<I>transaction</I>.
+Requests and replies have the same format:
+a textual verb possibly followed by arguments,
+which may be textual or binary.
+The most common reply verb is
+<TT>ok</TT>,
+indicating success.
+An RPC session begins with a
+<TT>start</TT>
+transaction; the argument is a key query as described
+earlier.
+Once started, an RPC conversation usually consists of 
+a sequence of
+<TT>read</TT>
+and
+<TT>write</TT>
+transactions.
+If the conversation is successful, an
+<TT>authinfo</TT>
+transaction will return information about
+the identities learned during the transaction.
+The
+<TT>attr</TT>
+transaction returns a list of attributes for the current
+conversation; the list includes any attributes given in
+the 
+<TT>start</TT>
+query as well as any public attributes from keys being used.
+<br>&#32;<br>
+As an example of the
+<TT>rpc</TT>
+file in action, consider a mail client
+connecting to a mail server and authenticating using
+the POP3 protocol's APOP challenge-response command.
+n(11There are four programs involved: the mail client 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99, the client
+<TT>factotum</TT>
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99, the mail server 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99, and the server
+<TT>factotum</TT>
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99.
+All authentication computations are handled by the
+<TT>factotum</TT>
+processes.
+The mail programs' role is just to relay messages.
+<br>&#32;<br>
+At startup, the mail server at
+<TT>x.y.com</TT>
+begins an APOP conversation
+with its
+<TT>factotum</TT>
+to obtain the banner greeting, which
+includes a challenge:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: start proto=apop role=server
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: read
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok +OK POP3 &lt;I&gt;challenge&lt;/I&gt;
+</PRE></TT></DL>
+Having obtained the challenge, the server greets the client:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: +OK POP3 &lt;I&gt;challenge&lt;/I&gt;
+</PRE></TT></DL>
+The client then uses an APOP conversation with its
+<TT>factotum</TT>
+to obtain a response:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: start proto=apop role=client
+            server=x.y.com
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: ok
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: write +OK POP3 &lt;I&gt;challenge&lt;/I&gt;
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: ok
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: read
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: ok APOP gre &lt;I&gt;response&lt;/I&gt;
+</PRE></TT></DL>
+<TT>Factotum</TT>
+requires that
+<TT>start</TT>
+requests include a 
+<TT>proto</TT>
+attribute, and the APOP module requires an additional
+<TT>role</TT>
+attribute, but the other attributes are optional and only
+restrict the key space.
+Before responding to the
+<TT>start</TT>
+transaction, the client
+<TT>factotum</TT>
+looks for a key to
+use for the rest of the conversation.
+Because of the arguments in the
+<TT>start</TT>
+request, the key must have public attributes
+<TT