- l4-hackers - example.com Site

Help with C++ and ide bus (oskit related, really stuck)
by Predrag Balorda 29 Feb '04

29 Feb '04

Ok here goes... I apologise if this may be slightly offtopic for l4-hackers but I seem to be stuck with something you people should have lot of experience with. Namely I'm trying to use OSKit (both official and DROP versions) to write a kernel in C++. I'm sure you're all aware of OSKit's unfriendliness toward C++ but there is one main thing that's preventing me from getting any work done. I'm starting off by creating some fairly thin wrappers around some structures and functions of oskit and once I've done that I'll go on and strip code out of oskit and re-write it in c++. But right now, there's a problem.... oskit_linux_init_osenv(environment); oskit_linux_init_devs(); oskit_linux_init_devs() hangs when the partition check kicks-in, somewhere in genhd.c, when doing msdos_partition(). If I compile one of the examples, x86/linux_fs_com.c with gcc everything works fine. However if I compile a c++ version of the same code, using same calls in the same order the linux genhd.c hangs when it tries to check partitions. And I get osenv_process_release with a hex dump. Anyone care to help me out here? funny how freebsd drivers work flawlessly though, isn't it? Thanks a lot and best regards! Pele P.S. I've tried with oskit10 from DROP but as soon as my kernel starts booting I get VGA garbage (vertical red lines) and the machine hangs. Actually it's not a machine, it's VMWare 4.0.5 but that shouldn't be a problem anyway. Note: all examples work fine so VMWare is not the problem.

1 0

Using hard disk as root filesystem
by tbisson＠soe.ucsc.edu 18 Feb '04

18 Feb '04

Hi, Thank you Adam for helping me solve the l4linux booting issue - adding modname "vmlinuz" module to the rmgr grub.conf linux fixed the rmgr error. As for, L4linux hanging, I had a bad configuration, which must have caused a race condition to pop up because after I changed my .config file around the kernel stopped hanging. I have another question. Rather than using a ramdisk as the root filesystem, I'd like to use my filesystem on /dev/hda3. So, I used this grub.conf, which I believe will use /dev/hda3 as the root fileystem: title L4Linux-2.4 kernel (hd0,0)/boot/drops/rmgr -sigma0 modaddr 0x2000000 module (hd0,0)/boot/drops/main -nokdb -nowait -serial_esc -comspeed 115200 -comport 1 115200 -comport 1 module (hd0,0)/boot/drops/sigma0 module (hd0,0)/boot/drops/vmlinuz.V2 root=/dev/hda3 The results are a standard boot (until kernel talks to disk) and dmesg displaying: ..... ide1 at 0x170-0x177,0x376 on irq15 hda: ide-disk driver hda: lost interrupt hda: host protected area => 1 hda: lost interrupt hda: 234441648 sectors (120034 MB) w/ 8192KiB Cache, CHS= 14593/255/63, UDMA(33) hda: lost interrupt hda: lost interrupt hdc: attached ide-cdrom driver hdc: lost interrupt hdc: lost interrupt hdc: ATAPI 52X CD-ROM CD-R/RW drive, 2048 Cache UDMA(33) Uniform CD-ROM driver Revision: 3.12 Partition check hda:<4>hda: dma_timer_expiry: dma status == 0x24 hda: DMA interrupt recovery hda: lost interrupt hda1 hda2 hda3 hda4 <<4>hda: dma_timer_expiry: dma status == 0x24 .... ds: no scocke drivers loaded! hda: DMA interrupt recovery hda: lost interrupt hda: dma_timer_expiry: dma status == 0x24 hda: DMA interrupt recovery hda: lost interrupt hda: dma_timer_expiry: dma status == 0x24 hda: DMA interrupt recovery hda: lost interrupt resiserfs: found format "3.6" with standard journal error wile mapping vm_allocated pages @ 10000002, error: e0, res: 40e0, fpage=80000033 KDB: pingpong no mapping --pingpong no mapping--------------------------------------------------------EIP: 00580c01 hard reboot time ---------------------------------------------------------------------------------------------------------------------------------------------------------- Additionally, I tried to boot up with regular ramdisk as the filesytems and mounting /dev/hda3 and then chrooting over, but that fails with a : FATAL: kernel too old message. _________________________________________________________________________________________ My questions: 1. Have you guys had success in using root=/dev/hda(x) in grub? If so, are there any tricks? 2. Is it typical for keyboard mappings to be wrong with l4linux? For example, my forward slash is now shift-7 and my dash is forward slash. 3. Has anyone seen the FATAl: kernel too old message before? Who is the kernel to old for, the filesystem? I apologize if these questions are inappropriate, Tim

2 1

Getting L4Linux2.4 to boot
by tim bisson 15 Feb '04

15 Feb '04

Hello, My research group has decided to experiment with the DROPS operating system and I have been designated as the guinea pig to get it running and see what we have been missing out on. I'm currently trying to get fiasco to work with L4linux-2.4. However, I am unfortunately failing in my task. I can't seem to get l4linux to fully load with fiasco; it hangs at the boot-up command: .... Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket starting kswapd Journalled Block device driver loaded <-system hangs here (with every grub.conf I try) ------------------------------------------------------------------------- With these two grub confs: title L4Linux-2.4 kernel (hd0,0)/boot/drops/rmgr -sigma0 modaddr 0x2000000 module (hd0,0)/boot/drops/main -nokdb -nowait -serial_esc -comspeed 115200 -comport 1 module (hd0,0)/boot/drops/sigma0 #modaddr 0x0080000 module (hd0,0)/boot/drops/vmlinuz.V2 no-scroll no-hlt l4irqack=linux load_ramdisk=1 ramdisk_size=16384 root=/dev/ram0 module (hd0,0)/boot/drops/drops.rd title L4Linux-2.4 kernel (hd0,0)/boot/drops/rmgr -sigma0 modaddr 0x2000000 module (hd0,0)/boot/drops/main -nokdb -nowait -serial_esc -comspeed 115200 -comport 1 module (hd0,0)/boot/drops/sigma0 #modaddr 0x0080000 module (hd0,0)/boot/drops/vmlinuz.V2 no-scroll devfs=mount ramdisk_size=16384 root=/dev/ram0 console=tty module (hd0,0)/boot/drops/drops.rd I get this error after it says it is trying to load the ramdisk: RMGR: #05: loading "/boot/drops/vmlinuz.V2 no-scroll no-hlt l4irqack=linux load_ramdisk=1 ramdisk_size=16384 root=/dev/ram0 " from 02057000-022d0d80 to [ 003ff000-00606b20 00607000-00654984 00656000-0067e00 00672000-006d66500 ] at entry 003ff000 via trampoline page code 0005e1ac RMGR: #06: loading "(hd0,0)/boot/drops/drops.rd" from 0022d1000-062d1000 to [ ] ERROR: exec_load() failed with code 6000 RMGR: boot error. Return continues, Esc panics, "m" shows memory map So I press enter and it linux loads until the "Journalled Block Device driver loaded" line. ------------------------------------------------------------------------------------------------------------------------ However, when I try this conf: title L4Linux-2.4 kernel (hd0,0)/boot/drops/rmgr -sigma0 modaddr 0x2000000 module (hd0,0)/boot/drops/main -nokdb -nowait -serial_esc -comspeed 115200 -comport 1 module (hd0,0)/boot/drops/sigma0 #modaddr 0x0080000 module (hd0,0)/boot/drops/vmlinuz.V2 root=/dev/hda3 no-scroll I don't get the load the ramdisk error (for obvious reasons), but my system still hangs at the same point. ---------------------------------------------------------------------------------------------------------------- I suspect the reason my system stalls at the line "Journalled Block Device driver loaded" is that there is no file system for which linux to run on? I hope that one of the l4-hackers has experienced something similar and can enlighten me as to why loading the ramdisk is causing an error and a suggestion of how get the ramdisk to load properly with RMGR so that booting l4linux doesn't hang. Thank you, Tim -------------------------------------------------------------------------------------------------------------------- For completeness, I've included my .config file I've been using: # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # L4Linux options # CONFIG_L4=y CONFIG_L4_V2=y # CONFIG_L4_VX0 is not set # CONFIG_L4_VX2 is not set # CONFIG_L4_L4ENV is not set CONFIG_L4_MK_FIASCO=y # CONFIG_L4_SMALL is not set # CONFIG_L4_CALL_SYSCALLS is not set # CONFIG_L4_IPC_SYSENTER is not set # CONFIG_L4_TAMED is not set CONFIG_L4_SUPERCLAN=y # CONFIG_L4_DROPSCON is not set # CONFIG_L4_TRACING is not set # CONFIG_L4_IRQ_OMEGA0 is not set # CONFIG_L4_USERPRIV_ONLY is not set # CONFIG_L4_DBG is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_HAS_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_F00F_WORKS_OK=y # CONFIG_X86_MCE is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_HIGHMEM is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # CONFIG_X86_TSC_DISABLE is not set CONFIG_X86_TSC=y # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_ISA=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_TCIC is not set # CONFIG_I82092 is not set # CONFIG_I82365 is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_APM is not set # # ACPI Support # # CONFIG_ACPI is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_CISS_MONITOR_THREAD is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=67072 CONFIG_BLK_DEV_INITRD=y # CONFIG_BLK_STATS is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_VLAN_8021Q is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # # Appletalk devices # # CONFIG_DEV_APPLETALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_IDEDISK_STROKE is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_BLK_DEV_GENERIC is not set CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_BLK_DEV_ADMA100 is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set CONFIG_BLK_DEV_RZ1000=y # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # CONFIG_BLK_DEV_ATARAID_SII is not set # # SCSI support # CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_MEGARAID2 is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_NCR53C8XX is not set CONFIG_SCSI_SYM53C8XX=y CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=20 # CONFIG_SCSI_NCR53C8XX_PROFILE is not set # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set # CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # # PCMCIA SCSI adapter support # # CONFIG_SCSI_PCMCIA is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y CONFIG_PCNET32=y # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_CS89x0 is not set CONFIG_TULIP=y # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set CONFIG_EEPRO100=y # CONFIG_EEPRO100_PIO is not set # CONFIG_E100 is not set # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_SUNDANCE_MMIO is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # CONFIG_NET_PCMCIA=y # CONFIG_PCMCIA_3C589 is not set # CONFIG_PCMCIA_3C574 is not set # CONFIG_PCMCIA_FMVJ18X is not set CONFIG_PCMCIA_PCNET=y # CONFIG_PCMCIA_AXNET is not set # CONFIG_PCMCIA_NMCLAN is not set # CONFIG_PCMCIA_SMC91C92 is not set # CONFIG_PCMCIA_XIRC2PS is not set # CONFIG_ARCNET_COM20020_CS is not set # CONFIG_PCMCIA_IBMTR is not set # CONFIG_PCMCIA_XIRCOM is not set # CONFIG_PCMCIA_XIRTULIP is not set CONFIG_NET_PCMCIA_RADIO=y CONFIG_PCMCIA_RAYCS=y # CONFIG_PCMCIA_NETWAVE is not set # CONFIG_PCMCIA_WAVELAN is not set # CONFIG_AIRONET4500_CS is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # CONFIG_INPUT=y CONFIG_INPUT_KEYBDEV=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=y CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # CONFIG_MK712_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # CONFIG_INPUT_NS558 is not set # CONFIG_INPUT_LIGHTNING is not set # CONFIG_INPUT_PCIGAME is not set # CONFIG_INPUT_CS461X is not set # CONFIG_INPUT_EMU10K1 is not set # CONFIG_INPUT_SERIO is not set # CONFIG_INPUT_SERPORT is not set # CONFIG_INPUT_ANALOG is not set # CONFIG_INPUT_A3D is not set # CONFIG_INPUT_ADI is not set # CONFIG_INPUT_COBRA is not set # CONFIG_INPUT_GF2K is not set # CONFIG_INPUT_GRIP is not set # CONFIG_INPUT_INTERACT is not set # CONFIG_INPUT_TMDC is not set # CONFIG_INPUT_SIDEWINDER is not set # CONFIG_INPUT_IFORCE_USB is not set # CONFIG_INPUT_IFORCE_232 is not set # CONFIG_INPUT_WARRIOR is not set # CONFIG_INPUT_MAGELLAN is not set # CONFIG_INPUT_SPACEORB is not set # CONFIG_INPUT_SPACEBALL is not set # CONFIG_INPUT_STINGER is not set # CONFIG_INPUT_DB9 is not set # CONFIG_INPUT_GAMECON is not set # CONFIG_INPUT_TURBOGRAFX is not set # CONFIG_QIC02_TAPE is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_IPMI_PANIC_EVENT is not set # CONFIG_IPMI_DEVICE_INTERFACE is not set # CONFIG_IPMI_KCS is not set # CONFIG_IPMI_WATCHDOG is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_SCx200_GPIO is not set # CONFIG_AMD_RNG is not set # CONFIG_INTEL_RNG is not set # CONFIG_HW_RANDOM is not set # CONFIG_AMD_PM768 is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # # Direct Rendering Manager (XFree86 DRI support) # # CONFIG_DRM is not set # # PCMCIA character devices # # CONFIG_PCMCIA_SERIAL_CS is not set # CONFIG_SYNCLINK_CS is not set # CONFIG_MWAVE is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_QFMT_V2 is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BEFS_DEBUG is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_UMSDOS_FS=y CONFIG_VFAT_FS=y # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=y # CONFIG_JOLIET is not set # CONFIG_ZISOFS is not set # CONFIG_JFS_FS is not set # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_MINIX_FS=y # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set CONFIG_ROMFS_FS=y CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set # CONFIG_NFS_DIRECTIO is not set # CONFIG_ROOT_NFS is not set CONFIG_NFSD=y # CONFIG_NFSD_V3 is not set # CONFIG_NFSD_TCP is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # # Sound # # CONFIG_SOUND is not set # # USB support # # CONFIG_USB is not set # # Support for USB gadgets # # CONFIG_USB_GADGET is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set CONFIG_FRAME_POINTER=y CONFIG_LOG_BUF_SHIFT=0 # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # # CONFIG_CRC32 is not set CONFIG_ZLIB_INFLATE=y # CONFIG_ZLIB_DEFLATE is not set

2 1

Linux on Pistachio
by Chad Russell 14 Feb '04

14 Feb '04

Has anyone successfully built Linux on L4 Pistachio?

1 0

L4Linux 2.4
by Ronald Aigner 07 Feb '04

07 Feb '04

Hi, I have some feature requests for L4Linux 2.4(L4Env): My kernel paniced, because I didn't read the Howto on the webpage correctly and the I couldn't do anything with my computer, except pressing the reset button. Could it by possible to enter ther kernel debugger when panicing? On the webpages: A description on how to use L4Linux with DOpE would be helpful. Ron. -- Mit freundlichen Gruessen / with regards ra3 @ inf.tu-dresden.de http://os.inf.tu-dresden.de/~ra3/

2 3

task creation in l4ka
by Jan Doerrenbaecher 29 Jan '04

29 Jan '04

Hi List! I have a some trouble with the task creation in l4ka. What I want/should do, is creating a task within the root task without using the rmgr. That means, I have to copy the text area of the new task in some memory region and I also have to allocate some memory for the stack. After this, I want to create the new task with the `l4_new_task` call. The problem now is, that I only have pointers dependent on the local address space of root task which I can give as input. Since the newly created task has its own address space these pointers are not useful. Anyhow, if I use them, the new task is created and running but while executing its code a page fault occurs, founded in the fact, that the new task is trying to get a page allocated by the root task. Am I barking up the wrong tree? Are there any simple solutions for that? Hoping for helpful hints.... Best regards, Jan

2 1

Build DROPS on debian testing
by Frank Matthieß 21 Jan '04

21 Jan '04

i want to take a look on fiasko, drops, dope and get via cvs -d :pserver:guest@os.inf.tu-dresden.de:/home/remote-cvs checkout oskit oskit10 l4env linux22 l4 the latest source. With the "Building DROPS HOWTO" from may 2003 i startup. The "make" run described in "1 Quickstart - 3." failed, because the dependency to automake wasn't mentioned in "3.2 OS requirements". Now make breaks with: ... Making all in dce make[7]: Entering directory `/usr/local/src/drops/l4/tool/dice/src/parser/dce' byacc -pdce -d -v parser.yy && mv y.tab.c parser.cc byacc: e - line 114 of "parser.yy", syntax error %pure_parser ^ make[7]: *** [parser.cc] Error 1 make[7]: Leaving directory `/usr/local/src/drops/l4/tool/dice/src/parser/dce' make[6]: *** [all-recursive] Error 1 ... ii gcc 3.3.2-2 The GNU C compiler ii make 3.80-4 The GNU version of the "make" utility. ii binutils 2.14.90.0.7-3 The GNU assembler, linker and binary utiliti ii bash 2.05b-12 The GNU Bourne Again SHell ii mawk 1.3.3-11 a pattern scanning and text processing langu ii sed 4.0.7-3 The GNU sed stream editor ii perl 5.8.2-2 Larry Wall's Practical Extraction and Report ii flex 2.5.31-21 A fast lexical analyzer generator. ii byacc 1.9.1-1 The Berkeley LALR parser generator ii doxygen 1.3.4-0.1 Documentation system for C, C++ and IDL. The full make log is available here: http://lug-owl.de/~frankm/drops/make.log.l4.20040117-2115 Is their any fix available? Frank. -- Frank Matthieß "Perl looks the same before and after rsa." -- unknown author

3 4

Some question about l4, l4ka
by Frank Matthieß 20 Jan '04

20 Jan '04

Hi, i want to evaluate l4. The first problem i have is to chose the 'right' l4 version. * There is a Dresden version "l4 v2" There is a Karlsruhe version "l4 x.2" * L4Linux is available from Dresden als 2.2.x L4Linux is available from Karlsruhe als 2.4.x Both seems to run on both l4 ipc protocolversion. * At Dresden they have basic parts of os specific components, called DROPS. Also a implementation of an windowmanager (DOpE). At Karlsruhe i don't see any additional os specific components at all. * The L4Ka seems to be the base for ports to other hardwareplatforms, like PowerPC, MIPS etc developed at UNSW. My problem is, to understand the difference/commons in - priority of development of this parts on Dresden and Karlsruhe. - collaboration between Dresden, Karlsruhe and UNSW. If a newbie like want to start, which is the 'right' l4 version and why is it the 'right' version. Frank. -- Frank Matthieß [x] Nail here for new monitor.

1 0

ANNOUNCE: L4Linux 2.4
by Volkmar Uhlig 13 Jan '04

13 Jan '04

The L4Ka team is pleased to announce the availability of L4Linux 2.4, which is a deprivileged Linux kernel running on an L4 microkernel. The release contains support for the L4Ka::Pistachio and Fiasco kernels. It supports the IA32 architecture and features multi-processor support on L4Ka::Pistachio. L4Linux is available via anonymous CVS. L4Linux is for the L4 developer community, and operating systems researchers and developers at large. L4Linux offers a great environment in which to develop and research with L4 microkernels. It offers the support infrastructure of Linux, yet the advantages of the L4 microkernel. This release should not be used in production environments nor for performance evaluations. For more information about L4Linux go to o http://l4linux.org/2.4/ o http://l4ka.org/projects/l4linux/ The L4Ka team

1 0

RE: L4, High Assurance, and Protection
by Volkmar Uhlig 07 Jan '04

07 Jan '04

> -----Original Message----- > From: Hermann Härtig [mailto:haertig@os.inf.tu-dresden.de] > Sent: Tuesday, January 06, 2004 11:07 AM > > BTW, the perception that Jochen Liedtke considered speed to dominate > everything else (see some earlier email) is simply rubbish. > Jonathan's statement "that performance cannot be used to justify > fundamental insecurity" could as well originate from Jochen Liedtke. The hitserver is an example where this perception is not rubbish (as you phrased it). The point I tried to make is that if you want generality of the kernel you have to look at a wide area of applications. As I stated in previous emails, I'm aware of the insufficiencies of the security model in L4 and I believe that this is well taken care of by many people looking at. The same is not true for the performance aspects and my feeling is that "all these important security features" are used to fatten and to slow the kernel unreasonably. Since you referred to Jochen here a quote from "Improving IPC by kernel design": "IPC performance is the Master. Anything which may lead to higher IPC performance has to be discussed. In case of doubt, decisions in favor of IPC have to be taken. But the performance and security qualities of other components must not be seriously impacted." So far there is no sound model proposed which doesn't add significant overhead and which has the same elegance as L4 today. - Volkmar

4 3

RE: L4, High Assurance, and Protection
by Volkmar Uhlig 06 Jan '04

06 Jan '04

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Monday, January 05, 2004 9:31 PM > > I believe that I have now asked twice for a URL to this specification. > Can you send me a URL? Otherwise we will continue to waste > each other's > time. Please accept my apologies that, in the absence of this > document, I may have done so. > > If it was on one of the L4 web sites, I failed to see it. On the l4ka.org homepage is a link to the latest snap shot (right now rev. 5), or use that link: http://l4ka.org/projects/pistachio/l4-x2-r4.pdf. The V4 spec is solely maintained in Karlsruhe. > > You immediately run into replacement policy issues. > > If there is a faster way, great! But protection is not merely > a desire. It is a hard requirement. *Every* mechanism I know > about for achieving a protected interface carries a fundamental > cost somewhere. You can do it with address space traversal, or > you can accept the need for a replacement policy, or you can do > something else, but you are going to pay *somewhere*. Or you are able to selectively choose to pay for it. > My problem is that performance cannot be used to justify fundamental > insecurity. Speed at the cost of correctness is simply unacceptable. Agree in general, however there are application domains which don't want to give up speed for an unused security model. And you have to accept that those apps exist, even if _you_ are not interested in those. > > Here the argument is around IPC redirection (which is arguably > > expensive). By sticking an interceptor in between you know which > > mappings go in and out. That way you can control it. But I suspect > > that fine-grain control over mapping privileges makes sense. The > > question is what this granularity should be--page or mapping in general. > > From a security perspective, the problem is with the > presence of mapping operations at all. Mapping establishes a > high-speed, mutable channel, so it tends to undermine reference > monitors. Of course you can't allow to permanently establish a page mapping but have to interpose it. However, nobody promised to have a protocol-transparent reference monitor using page mappings.... > My preferred model is that performing a send with a mapping on a > disabled descriptor would be treated as an access violation, and a > suitable exception would be delivered to fault handler. I > don't want to pay any indirection cost for the legal (non-mapping) IPCs. See above. > > You can transparently drop the mapping if it is not > allowed. Since the > > guarantees whether a page is mapped or not come from the > pager hierarchy > > it is only as strong as all combined pagers. By adding a > > non-guaranteeing pager in the hierarchiy you are set. > > >From a security perspective, failing silently is *always* a > mistake. It > also makes virtualization difficult if somebody wishes to be backward > compatible with the interface later. You are describing a situation in > which a sender has done a known-illegal operation, but no fault is > generated? This doesn't seem like a good design. Why? You fault again--the client broke the protocol. You can define a protocol which does not allow page mappings. If anybody tries--too bad. Why do you care about virtualization and what virtualization do you have in mind? (I think it is more a Q of transparency.) > It is a big problem for the pager to be settable by the thread. There > are some systems in which this can be permitted, and other systems in > which it **must not** be permitted. Because there exists systems in > which this must not be permitted, the operation must (at a minimum) > involve invocation of a trusted party. > > Perhaps there is some third design possibility that I have not > considered carefully enough, but it appears to me that a > high-assurance system constructed on top of L4 must be built > exclusively using trusted pagers. While it is possible, in abstract, > to use untrusted pagers in a descriptor-based system (as EROS does), > the L4 map/grant operations don't appear to provide enough book-keeping > controls to be trusted. I guess you have to give a little more information about that--maybe on a whiteboard. It is neither clear to me why this is a *must* nor why an untrusted pager causes a problem. A Q regarding your hash/cache suggestion: how do you ensure that you can't use the cache as a covert channel without major performance losses? - Volkmar

2 1

L4 and EROS
by David Denny 05 Jan '04

05 Jan '04

I have been wondering why "Eros" has invaded this list. This user's pov: L4 is a solid product which works well. I want to experiment with OS building and L4 has a robust base structure, as well as a friendly community and all the tools I need to stick my own silly things on top of it. I support L4. [ I'd support Eros if it had been built to the same level, never mind whatever "angels on pinhead" theoretical issues might occasionally surface. However, from my assessment of the website and some googled papers, Eros is still (shall we say) alpha.] I'm concerned that this side debate might end up destabilising the L4 Team's motivation. [ Actually, I think I meant to include the word "angry" somwhere in there but that would have been out of keeping ] I'm sure that one day there will be viable alternative u-kernels but for the next year or so I can't see anything toppling L4. Please keep at it, Team, and don't allow yourselves to get tr*lled into distractions. And for the moment Happy New Year L4Hackers and please persevere. You are Doing The Right Thing. best wishes David Denny

3 4

RE: L4, High Assurance, and Protection
by Volkmar Uhlig 05 Jan '04

05 Jan '04

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Monday, January 05, 2004 4:56 PM > To: Volkmar Uhlig > Cc: rudykoot(a)mithrill.org; L4 Hackers List > Subject: L4, High Assurance, and Protection > > Issue 1: Need for Protected IPC > > On Thu, 2004-01-01 at 18:09, Volkmar Uhlig wrote: > > If it does not matter where the check code is executed > > (client/kernel/server) but only who gets accounted for the used > > resources (CPU, cache, whatever) this is not the case. (I'm not > > claiming L4 can do that (yet).) > > In answer to Volkmar's question: it matters very > fundamentally where the > check is performed. It is the difference between mandatory and > discretionary controls. > > The current L4 IPC is discretionary: the sender can invoke anyone, and > the recipient checks the sender identity and decides whether to accept > the IPC. > > In such systems, it is a fundamental requirement that the reference > monitor be able to PREVENT (absolutely) communication between > processes that are under its control. If a sender S is not > permitted to send to a recipient R, the behavior must be exactly > as if the send was performed to a non-existent ID. Ok, I see that point. > The main change that is needed in L4 to resolve this is to define the > recipient-id and sender-id fields as opaque fields. Under > high-assurance requirements, the sender is not entitled to know how > many threads execute within the recipient. The sender-id and > recipient-id therefore must not encode "thread within process". > Similarly, it must not encode "process ID". I think there is some misconception around about L4's thread ids. In L4 V4 (X.2 is going to become V4 after maturing) threads and address spaces are completely independent of each other. Threads execute in an address spaces, but they can migrate. A thread ID is a communication-endpoint place holder. If you have, say, 100 threads in an address space and you want to hide that fact you can use a single thread serving as a distributer. Since we have local IPC the distribution can completely take place in user land without a kernel invocation. The worker can impersonate the distributer for the reply. > While I do not advocate any particular implementation strategy, let me > give an *example* of one that might suffice: a simple hash table. > Instead of using the PCB address as the process ID, the > kernel could use > H(sender kernel ID, requested-recipient-ID) as an index into a hash > table and perform a single indirection (and possible hash bucket > chasing) to find the process address. This is fundamentally the design > proposed by Trent several years ago. You immediately run into replacement policy issues. > 2: Restricted Mapping > > This is a very small issue, and there may be some way around it. > > In general, I like the map/grant model very much, but in some > systems it is necessary for the manager to know who has what mappings. > In these systems, having applications perform mappings directly to each > other creates a consistency problem. Here the argument is around IPC redirection (which is arguably expensive). By sticking an interceptor in between you know which mappings go in and out. That way you can control it. But I suspect that fine-grain control over mapping privileges makes sense. The question is what this granularity should be--page or mapping in general. > My preference would be to have *both* controls, because they serve > slightly different purposes. The first lets me virtualize the > map/grant operations (in order to keep manager metadata updated), > while the second prevents map recursion. > > The problem with the first method is that it requires protected > recipient descriptors. You can transparently drop the mapping if it is not allowed. Since the guarantees whether a page is mapped or not come from the pager hierarchy it is only as strong as all combined pagers. By adding a non-guaranteeing pager in the hierarchiy you are set. > The problem with implementing only the second method is: what > thread id should a page fault handler receive from a faulting thread? > Restricted or non-restricted? I can argue for either depending on what > kind of system I am trying to build. That raises the question whether the pager is privileged or not. Since the pager can be set by the thread the pager can be changed and the thread could elevate its privileges. Or did I misunderstand you? - Volkmar

2 1

RE: IPC/Capabilities Overview
by Rudy Koot 05 Jan '04

05 Jan '04

>That is wrong. The direct lookup drastically reduces cache and TLB >footprint. For a full IPC we have to access two TCBs (which are >virtually mapped and have the stack in the same page) which costs two >TLB entries. The complete lookup is therefore a simple mask (plus maybe >a shift), a relative mov (e.g. mov 0xe0000000(%eax), %ebx) and a >compare. Overall costs therefore (on IA32): >- 2 TLB entries (but we need them anyway for the stack, they could be >reduced to one TLB entry when using 4M pages for all TCBs, but that >would add an indirection table and therefore a cache line); refetch >costs ~80 cycles/entry >- shift and move (~3 cycles) >- 1 cache line for the thread id (which is shared with thread state >etc). > >Assume you add 2 more TLB entries and 5 more L2 cache lines--your >aftercosts for IPC go up by 2*80 + 5*80 = 560 cycles. >Considering overall IPC costs of 1000 cycles on a P4 with all those >nasty cache and TLB flushes you add an overhead of >50%. The "but we need them anyway for the stack, they could be reduced to one TLB entry when using 4M pages for all TCBs, but that would add an indirection table and therefore a cache line" part seems very interesting, I've seen something about it in your microkernel presentations, so I guess you have done some speed measurements. Now if you would give each address space it's own indirection table, you would have a thread space. Have you done measurements? What does this methode cost? -- Rudy Koot _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl

2 1

RE: IPC/Capabilities Overview
by Volkmar Uhlig 05 Jan '04

05 Jan '04

Similar to Rudy I try to answer multiple mails at once. (Sorry for the long post!!!) First a general statement. It appears to me that goals are very different. As Rudy pointed out one of the main goals of L4 (at least pursued in Karlsruhe) is to have a universal and high performance uK. Universal here means that it is applicable to any domain. That also answers Rudy's question who is going to use a microkernel without a security model--anybody who does not require a security model. And that may be your wrist watch, cell phone, or a medical appliance. Jonathan wrote: > Please consider that "clever" is a four letter word (a curse). All of > these optimizations are, in my opinion, justifiable reasons to fire a > programmer with a strongly negative recommendation. The resulting > systems are unmaintainable. > > Speed is not the primary goal. Efficient robustness (measured end to > end) is the primary goal. That maybe true for your research agenda. However, to investigate the limits of uK based systems I would be very disappointed if you wouldn't even consider these optimization. Then we are back to the good old MACH problem: uKs are inherently slow by nature, full stop. And, we are talking research here, not business (btw, I would fire those guys too). We may also simply not have the right tools to do that robust and efficiently today, but then we should look into better tools. > Excuse me, but this is utter nonsense. You are making a quantitative > argument using qualitative and unsubstantiated arguments. You (and I) > need numbers in order to evaluate this issue. > > The correct way to approach this is to ask: > > 1. What percentage of invocations dynamically incur the cost of > checking? > 2. What is the respective cost of this checking at user and at > supervisor level? > 3. Given that the supervisor-mode implementation *is* incurred by > all cases, what is the weighted cost of the mechanism in both > cases (user and supervisor). > > Once you have this calculation, you have a correct > engineering basis for making a decision. Good that we are on common ground now. We also have to agree on what system you and I have in mind and from that we can derive the overall costs. To me it seems you are implying a system design and claim that L4's lack of certain features makes it perform as good/bad or worse. However, by not having the feature in the kernel but in user land allows to modify it. Now the question changes to how efficiently can we implement it in user land compared to the in-kernel version. In the case it is part of the kernel you can't change it anymore which means you will always pay the cost whether you want or not. And here you also have to evaluate _all_ potential systems, even those without security requirements. > And I should acknowledge that I disagree with Volkmar very > fundamentally about the "performance uber alles" assumption. > Performance is important, but from a research perspective it > is *more* important to understand what the fundamental architectural > issues are. Once we do, we can step back and decide what to take > out. At the moment, we have no common base on which direct comparison > is possible. I think Jonathan misunderstood me on that. I think we have a set of core requirements for a kernel which are probably almost identical for EROS and L4. However, we have a different focus. And performance is still one of the main reasons why monolithic kernels are preferred over uKs. That does not mean that security is less important. > I don't think that the L4 kernel has all the answers, but I also think > that the EROS kernel does not have all the answers. Each, I think, has > important strengths. EROS lacks a certain elegance of minimality. L4 > (as I understand it today) lacks a credible story about security, access > control and denial of service. Perhaps it is time for both groups to > step back and make a serious attempt to learn from each other. I agree that one of the current weaknesses of L4 is its very rudimentary security model. And each L4 group seems to have its own perspective on how this should be solved. > From the conversations on this list, however, it appears to > me that the L4 research groups do not agree universally on what the > IPC control mechanism is, and this may be contributing to some > difficulty in the discussion. One group clearly advocates thread spaces. > Volkmar (if I understand him) currently advocates IPC indirection. The > two designs have very different implications for performance, implementation, > and security. No, I'm not advocating this. So far nobody has a reasonable cost-benefit analysis of the thread mappings and as long as that is the case I'm not in favor of anything. However, considering complexity and elegance of the different alternatives and the performance impact on a wide variety of hardware architectures (specifically MP and NUMA systems), I'm very skeptical about proposals which bind security principals on address spaces. That will just open another can of worms. The redirection model has the disadvantage of fundamentally changing the semantics of IPC. With a purely synchronous IPC model timing is a fundamental part of the communication protocol. Transparent interception is not possible since the message gets successfully delivered to the redirector, which, however, may discard it. This alters guarantees usually given by the kernel. > Volkmar's technique is quite elegant. The only problem I see > is that it places the burden of verification on the wrong party > -- it should be on the client. That is, the design invites DoS > attacks. If it does not matter where the check code is executed (client/kernel/server) but only who gets accounted for the used resources (CPU, cache, whatever) this is not the case. (I'm not claiming L4 can do that (yet).) > However, Volkmar is making an assumption that is problematic. He is > assuming that the passed ID is a pointer. From a security perspective > this is VERY bad. First, it invites memory attacks. Second, > it discloses information about the internal implementation of the server. > Third, it makes selective rescind of authority very hard to do. No, it can be an object handle which can be translated in some/any way (e.g. cryptographically modified, or a hash). The fundamental difference is that it is not a first class kernel object. This means you have the freedom to choose the appropriate encoding (which could be a pointer of course). > As a backwards compatibility matter, and as a validation of the L4 > nucleus, running Linux on an L4 is interesting. As a matter of future > research, and as a matter of forward-looking system > architecture, it is boring. Yes, I agree. However, a gradually decomposed Linux can answer many research questions without re-implementing a fully fledged OS. > The right forward-looking research question is: > > *Given* a fast nucleus in the style of L4, what is the most > effective way to structure a native operating environment? > What fundamental and novel leverage do such kernels provide? That was one of the goals of SawMill. ==== Rudy wrote: > Sorry, but I do not see how the version part could be used as > the server defined word. You can't have multiple versions > (read server defined words) of the same thread-id at the > same time. Correct. I had a different usage scenario in mind--sorry for confusions. > I believe these costs are exagerated. To convert a capability into > sender-id a simple table lookup can be used. This requires a single > TLB entry and a single L2 cache line (worst case). If IPC is frequent, > which is the case in which you want high performance, the TLB entry > is very likely to be present and probably even the L2 cache line. This assumes that you have a small TLB working set and small cache working set. However, if communication is frequent that also means that you are probably communicating to _many_ partners. And then you probably need a TLB entry per table which again increases the TLB footprint. That means the likelihood that you replace user-TLB entries goes up--the problem is the user's active working set you replace. ==== Jonathan wrote: > Volkmar is combining two things in one, and seems to be > forgetting that he does so. You are correct. Once you have the > capability, obtaining the target thread id is quite fast. No table > lookup is required. The capability is kernel-protected state, and can > simply contain a direct pointer to the recipient PCB. > > I think that the costs that Volkmar is identifying come from > the need to lookup the thread-id or capability in the thread mapping > space. That is, these are the costs of the address space traversal. > The costs are the same in either case (thread-id or capability). If you add a level of indirection (thread id or cap) that is the case. However, if you pay for a level of indirection anyhow, then it does not matter whether the name specifies a capability or a thread. I have the (maybe unreasonable) feeling that it should be possible to express both in one model with the same costs associated. > One of the features of EROS is an indirection object. This object can > stand in front of a start capability transparently. The client invokes > the indirection object capability rather than the start capability. > Given this construction, a service can selectively rescind that client > capability by destroying the indirection object. > > This is something that L4 presently has no means to do. Of course, L4 > does not need it, because it makes no assumption about controlling > client invocations at all. In the current L4 model this would be a proxy thread assuming that IPC is cheap and it happens infrequently. In the case of frequent redirection you would extend the IPC protocol to take the reconfiguration into account. This boils down to how much transparency do we want. Jonathan mentioned on the EROS list that transparent persistency is something which is not feasible. The same question can be asked in this case: is transparent redirection something we want/need? And are we willing to pay the overhead? One could construct a system, where communication can only be restricted (for enforcement) and apps must be able to dynamically re-configure. ==== Jonathan > In practice, I would use a cache for an L1 software probe > first in order to avoid all marginal TLB and cache misses > in the usual case, but this would result in high variance > of IPC times. Which means you add a new policy to the kernel, something we strictly try to avoid with L4. - Volkmar

2 2

RE: IPC/Capabilities Overview
by Volkmar Uhlig 04 Jan '04

04 Jan '04

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Wednesday, December 31, 2003 6:32 AM > > First, some corrections on specific statements that you made, because > they are potentially distracting from the real issues. Then I will try > to answer your questions. > > Corrections: > > 1. L4 IPC speed has relatively little to do with the "direct lookup" > aspect of thread ids. Any indirect encoding will carry a cost, but in > terms of the overall performance of IPC this cost is quite small. That is wrong. The direct lookup drastically reduces cache and TLB footprint. For a full IPC we have to access two TCBs (which are virtually mapped and have the stack in the same page) which costs two TLB entries. The complete lookup is therefore a simple mask (plus maybe a shift), a relative mov (e.g. mov 0xe0000000(%eax), %ebx) and a compare. Overall costs therefore (on IA32): - 2 TLB entries (but we need them anyway for the stack, they could be reduced to one TLB entry when using 4M pages for all TCBs, but that would add an indirection table and therefore a cache line); refetch costs ~80 cycles/entry - shift and move (~3 cycles) - 1 cache line for the thread id (which is shared with thread state etc). Assume you add 2 more TLB entries and 5 more L2 cache lines--your aftercosts for IPC go up by 2*80 + 5*80 = 560 cycles. Considering overall IPC costs of 1000 cycles on a P4 with all those nasty cache and TLB flushes you add an overhead of >50%. > 2. Security checks done in the server vs. the kernel are not > necessarily slower or faster. It depends greatly on what security > checks you wish to do. I argue that: > > a) *many* (not all) of the security checks currently done in L4 > servers could be eliminated if kernel-protected bits existed > in each descriptor > > b) For some types of systems (capability systems), disclosure of > the sender id is an absolute violation of design requirements, > so any microkernel that relies exclusively on server-side > security checks based on sender-id is not a universal > microkernel. > > c) More specifically, any microkernel that requires checks based > on sender-id is entirely unsuitable as a platform for EROS-NG. And as you stated this is _also_ a limited view, because you only look from the EROS and capability point of view. By throwing away one register for an identifier you reduce your register real estate by 33%. That can be particularly hurtful in the local case, where a very simple check (or none) is sufficient. And the argument that everything should go in memory (one of your last emails) is not convincing--register-based IPC is still much faster, it is mostly a question of a reasonable IDL compiler. And we are all aware that IA32 is crippled from that perspective. Take any other architecture (worst case: IA64) and the argument becomes complete bogus. > Ignoring clans and chiefs (which we all agree is too expensive and > inflexible), here is how the three schemes break down: > > Thread IDs: > No restriction who can send. > Server makes decisions based on sender-id You forgot sender restriction and redirection. > Hybrid: > Sender can only invoke a thread descriptor that is mapped in their > thread descriptor space (thread space) > Server makes decisions based on either (a) a field that is encoded > within the descriptor, or (b) the sender-id. > > ** Sender-id is software controlled by the thread manager, and can > be set to zero for all threads to simulate capability behavior. A possibility you did not mention is a hybrid thread id which has an thread and a descriptor part. The descriptor is kernel enforced. That is what we currently have in V4 (please not that V2 and X.0 are completely outdated!!!)--the version part of the thread id. > In the thread-IDs design, there are two distinguished phases in the > server-side security checks: > > 1. Object resolution. Based on sender-id and arguments, determines > the identity and permissions of the server-implemented object > that has been invoked. This phase may conclude that no such > object exists. > > 2. Permissions check. Given the object identity and permissions, > make a decision about whether the particular operation is to be > permitted. > > All of the bits needed for phase 2 can be encoded in the > descriptor. All of the expensive parts of the current L4 protocol > lie in phase 1 (object resolution). See above. Furthermore, your suggestion is to move that part into the kernel... Then the overhead is on _every_ invocation, not just for the once where you need it. > > Now I want to make clear why capablities are much better > than virtual thread > > objects: > > > > * The extra word does not seem to decrease performance in > any way (is this > > true?) so it a free feature, that can be used but doesn't have to. > > I believe that this is true, and the evidence of the EROS > implementation seems to support this view. Where are benchmarks with cold caches? Do you have a detailed analysis of the cache and TLB footprint? > This is a possible usage. In our experience, the more common > behavior is > to have a pointer to some data structure that describes a server > implemented object (i.e. has nothing to do with any > particular client), > and reuse the low bits for permissions. For example, the pointer might > point to a file metadata structure, and the low bits might > indicate read and write permissions. In our case we use an object identifier in the message, which is a handle to an object descriptor and do a reverse check (i.e. if the thread is allowed to invoke that object). Costs: boundary check (can be a simple AND) one MOV and a CMP. The permissions can go into the same cache line. Happy new year!!! - Volkmar

4 3

Re: IPC/Capabilities Overview
by Jonathan S. Shapiro 02 Jan '04

02 Jan '04

On Thu, 2004-01-01 at 02:56, Rudy Koot wrote: > Some comments and questions to about 5 different e-mails: Some answers, as best I can. :-) > ===== Rudy > > Some of Volkmar's arguments are based on the fact that L4 is a general > purpose microkernel, I think the discussion would be more useful if we look > at how a microkernel with the purpose of running a capability based system > on top, should be design. Leaving the question wheter those capabilities > should be implemented at kernel-level or user-level open. We already have that kernel. It's called EROS. While I do know how to build a variant that is much closer in spirit to L4 (i.e. smaller -- we designed such a nucleus at IBM) I do not believe that its end to end performance will be any better. However, I have been very carefully avoiding the direction you identify for three reasons. The first is that I deeply respect the L4 work. The second is that I attempted a successor to L4 after Jochen left IBM and it became a bit sensitive. The third is that the L4 group has not chosen to pursue capability-based design, and I am not interested in redirecting their work. At this time, what I am trying to achieve is a common nucleus on which both teams can pursue their research. This will facilitate cross-fertilization of ideas, and I believe that this will benefit both groups. The plain fact is that the L4 and EROS communities can successfully proceed in independent directions, each lacking a critical mass of people. I do not believe that this is the most productive way to proceed. And I should acknowledge that I disagree with Volkmar very fundamentally about the "performance uber alles" assumption. Performance is important, but from a research perspective it is *more* important to understand what the fundamental architectural issues are. Once we do, we can step back and decide what to take out. At the moment, we have no common base on which direct comparison is possible. I don't think that the L4 kernel has all the answers, but I also think that the EROS kernel does not have all the answers. Each, I think, has important strengths. EROS lacks a certain elegance of minimality. L4 (as I understand it today) lacks a credible story about security, access control and denial of service. Perhaps it is time for both groups to step back and make a serious attempt to learn from each other. > ===== Rudy > > Any form of IPC in which the decission to allow or disallow a thread to send > a message to another thread is vulnerable to a DoS attack. If the decission > is mad by the kernel the IPC can be canceled immediately, but if it is made > at user level another thread is blocked for a small amount of time. This is exactly true, but it fails to take into account the fact that IPC indirection can possibly suppress this behavior. I do not understand the current IPC indirection proposal, and trying to reason without understanding it is very slippery. Also impolite. Something I am known for, but I do try not to do it on purpose. :-) >From the conversations on this list, however, it appears to me that the L4 research groups do not agree universally on what the IPC control mechanism is, and this may be contributing to some difficulty in the discussion. One group clearly advocates thread spaces. Volkmar (if I understand him) currently advocates IPC indirection. The two designs have very different implications for performance, implementation, and security. > ===== Shap > > > b) For some types of systems (capability systems), disclosure of > > the sender id is an absolute violation of design requirements, > > so any microkernel that relies exclusively on server-side > > security checks based on sender-id is not a universal microkernel. > > Sorry, but you still owe me an example of a situation in which revealing the > sender-id actually breaks the security of the system. The only thing I could > think of was that it might reveal some details about the internal structure > of an application, but if the system is secure that information hasn't got > much use to a malicious program or user. >From the perspective of security you are reasoning backwards. There is never a mandate to justify withholding information. The mandate is always the other way: if you wish to argue that a sender-id is desirable, you must justify why its disclosure is safe and also why it is required. Observation: it is not, and it is not. In answer to your question, here are some problems with disclosing sender ID: 1. The one you mentioned: it discloses client structure, which is something that the server is not entitled to know. 2. It mandates a client structure, because using the sender-id as a credential strongly discourages the application developer from breaking their applications into multiple address spaces and separate threads. This defeats robustness and security both. 3. It is inaccurate. The server can NEVER rely on the sender-id, because it cannot know if the immediate sender is acting in proxy for someone else. That is, sender-id can only provide false security. Personally, I find (2) very ironic. Ultimately, the main justification for fast IPC is that it makes decomposed applications easier. I find it curious, given this, that L4 adopts an access checking model that defeats decomposition. I also find it very curious that no L4-based system (at least, none that I know about) has really pushed for fine-grain decomposition. Perhaps Mungi did and I do not understand it well enough. As a backwards compatibility matter, and as a validation of the L4 nucleus, running Linux on an L4 is interesting. As a matter of future research, and as a matter of forward-looking system architecture, it is boring. The right forward-looking research question is: *Given* a fast nucleus in the style of L4, what is the most effective way to structure a native operating environment? What fundamental and novel leverage do such kernels provide? That is: do fast IPC and microkernels provide anything that is architecturally important, or are they just clever tricks that are good only for conference papers? Obviously, I believe that they are useful. The problem I see is that *none* of our groups are big enough to successfully evaluate this question of "what native environment?" It requires a truly awesome amount of work. > I really think this is an important point. If revealing the sender-id is > indeed a violation of security, there wouldn't be a need to discuss wheter > or not thread-spaces need to be implemented. They just have to. > > > c) More specifically, any microkernel that requires checks based > > on sender-id is entirely unsuitable as a platform for EROS-NG. Because (a) revealing sender-id is a security hole, and (b) EROS is a capability system. The latter is a matter of definition. > >Assume you add 2 more TLB entries and 5 more L2 cache lines--your > >aftercosts for IPC go up by 2*80 + 5*80 = 560 cycles. > >Considering overall IPC costs of 1000 cycles on a P4 with all those > >nasty cache and TLB flushes you add an overhead of >50%. > > I believe these costs are exagerated. To convert a capability into sender-id > a simple table lookup can be used. This requires a single TLB entry and a > single L2 cache line (worst case). If IPC is frequent, which is the case in > which you want high performance, the TLB entry is very likely to be present > and probably even the L2 cache line. Volkmar is combining two things in one, and seems to be forgetting that he does so. You are correct. Once you have the capability, obtaining the target thread id is quite fast. No table lookup is required. The capability is kernel-protected state, and can simply contain a direct pointer to the recipient PCB. I think that the costs that Volkmar is identifying come from the need to lookup the thread-id or capability in the thread mapping space. That is, these are the costs of the address space traversal. The costs are the same in either case (thread-id or capability). If the kernel implementation uses flexpages, then I believe that in the usual case the reality will be only one TLB miss, but the number of L2 references seems plausible and problematic. In practice, I would use a cache for an L1 software probe first in order to avoid all marginal TLB and cache misses in the usual case, but this would result in high variance of IPC times. > >In our case we use an object identifier in the message, which is a > >handle to an object descriptor and do a reverse check (i.e. if the > >thread is allowed to invoke that object). Costs: boundary check (can be > >a simple AND) one MOV and a CMP. The permissions can go into the same > >cache line. Volkmar's technique is quite elegant. The only problem I see is that it places the burden of verification on the wrong party -- it should be on the client. That is, the design invites DoS attacks. However, Volkmar is making an assumption that is problematic. He is assuming that the passed ID is a pointer. From a security perspective this is VERY bad. First, it invites memory attacks. Second, it discloses information about the internal implementation of the server. Third, it makes selective rescind of authority very hard to do. One of the features of EROS is an indirection object. This object can stand in front of a start capability transparently. The client invokes the indirection object capability rather than the start capability. Given this construction, a service can selectively rescind that client capability by destroying the indirection object. This is something that L4 presently has no means to do. Of course, L4 does not need it, because it makes no assumption about controlling client invocations at all. > >A possibility you did not mention is a hybrid thread id which has an > >thread and a descriptor part. The descriptor is kernel enforced. That > >is what we currently have in V4 (please not that V2 and X.0 are > >completely outdated!!!)--the version part of the thread id. > > Sorry, but I do not see how the version part could be used as the server > defined word. You can't have multiple versions (read server defined words) > of the same thread-id at the same time. I don't either, but I don't understand what Volkmar is proposing enough to comment intelligently. I would like to, and I hope he will respond with a pointer to a specification or more detail about where these references are occuring. I am not sure that I have understood him correctly. shap

2 2

Re: IPC/Capabilities Overview
by Rudy Koot 01 Jan '04

01 Jan '04

>Corrections: > >1. L4 IPC speed has relatively little to do with the "direct lookup" >aspect of thread ids. Any indirect encoding will carry a cost, but in >terms of the overall performance of IPC this cost is quite small. While this is indeed also my believe, it unfortunately isn't that of the L4 team. If you look at their presentation their two main points are: "IPC needs to be infinitly fast". The problem is that they only look at direct costs of cycles spend on entering the kernel, doing IPC and exiting tthe kernel. They also look at indirect costs of TLB and cache misses caused by IPC, but strangely enough won't look at the cost of checking access rights (probalby because access checks are no longer part of the microkernel, but of operating system policy). If you want to convince them, you have to make sure they eiter count those costs also OR make sure they believe the added IPC costs of capabilities are indeed neglectable. As far as I could reason these added (compared to the thread-id methode) costs would be: - One extra register spilled on the receiver side (to store the server defined word) - One extra memory access (to convert the capability into the server thread id) [VTO] - One extra memory access (to load the server defined word) - One or more extra memory accesses (to locate the server defined word and server thread id in the Thread Object Space) [VTO] This goes in against their believe that "A computers get faster memory acess get relativly slower, therefore memory access should be avoided during IPC". I believe only 2 memory accesses are needed on RISC machines with large register sets, so the 3+ extra accesses are quit a burden (through the L4 developer's eyes). However they are considering Virtual Thread Objects and compared to that only 1 extra memory access is required (this isn't a lost comparing against the 4+ that already need to be done), because the steps marked with [VTO] needs to bee done in that model also. > b) For some types of systems (capability systems), disclosure of > the sender id is an absolute violation of design requirements, > so any microkernel that relies exclusively on server-side > security checks based on sender-id is not a universal microkernel. I never realised this, and I still don't see why this a design requirement, but if there is one this would again be a major argument in favor of capabilities. Could you give me an example of when not reveiling sender-id is useful? >Hybrid: > Sender can only invoke a thread descriptor that is mapped in their > thread descriptor space (thread space) > Server makes decisions based on either (a) a field that is encoded > within the descriptor, or (b) the sender-id. > > ** Sender-id is software controlled by the thread manager, and can > be set to zero for all threads to simulate capability behavior. Could you explain a bit more about this thread manager. It seems to solve a problem in which the sender id does needs to be know. For example if a thread tries to write to a file, which it hasn't got write access for, it may be a system requirement that this is logged into the security log. Now you also want to log which thread actualy made the violation. If the sender-id isn't reveiled to the file server it can only log the thread-id (no not thread-id, something else but what?) to which it originally mapped the capability. Maybe if a thread manager is used the true sender-id can be logged withour reveiling it so the file server itself? > > * The server defined word will probably be used to store a pointer to >some > > client specific data structure containing important information that >needs > > to be access often. You might say, yeah well mbut you can calculate this > > address from the sender ID, but this no longer works when clients start >to > > grant and map server objects/capabilites to eachother, because the >server > > doesn't know about these actions, unless some complex, slow protocol is >used > > to update the serves information. > >This is a possible usage. In our experience, the more common behavior is >to have a pointer to some data structure that describes a server >implemented object (i.e. has nothing to do with any particular client), >and reuse the low bits for permissions. For example, the pointer might >point to a file metadata structure, and the low bits might indicate read >and write permissions. I used some strange wording in my explanation but a meant what you just said. > > The size of the > > capability should be equal to the pointer/word size of the machine. > >This can't be true, since the capability must encode both the >destination thread id and also the extra word. Minimum practical size is >two machine words. Sorry this was a typo, I Actually meant to say the size of the server defined word inside the capability shouls be aqeual to the machine word size, making the total capability size, indeed, at least 2 machine words in size. -- Rudy Koot _________________________________________________________________ MSN Zoeken helpt je om de gekste dingen te vinden! http://search.msn.nl

3 3

Re: IPC/Capabilities Overview
by Rudy Koot 01 Jan '04

01 Jan '04

Some comments and questions to about 5 different e-mails: ===== Rudy Some of Volkmar's arguments are based on the fact that L4 is a general purpose microkernel, I think the discussion would be more useful if we look at how a microkernel with the purpose of running a capability based system on top, should be design. Leaving the question wheter those capabilities should be implemented at kernel-level or user-level open. ===== Rudy Any form of IPC in which the decission to allow or disallow a thread to send a message to another thread is vulnerable to a DoS attack. If the decission is mad by the kernel the IPC can be canceled immediately, but if it is made at user level another thread is blocked for a small amount of time. ===== Shap > b) For some types of systems (capability systems), disclosure of > the sender id is an absolute violation of design requirements, > so any microkernel that relies exclusively on server-side > security checks based on sender-id is not a universal microkernel. Sorry, but you still owe me an example of a situation in which revealing the sender-id actually breaks the security of the system. The only thing I could think of was that it might reveal some details about the internal structure of an application, but if the system is secure that information hasn't got much use to a malicious program or user. I really think this is an important point. If revealing the sender-id is indeed a violation of security, there wouldn't be a need to discuss wheter or not thread-spaces need to be implemented. They just have to. > c) More specifically, any microkernel that requires checks based > on sender-id is entirely unsuitable as a platform for EROS-NG. Why? ===== Volkmar >Assume you add 2 more TLB entries and 5 more L2 cache lines--your >aftercosts for IPC go up by 2*80 + 5*80 = 560 cycles. >Considering overall IPC costs of 1000 cycles on a P4 with all those >nasty cache and TLB flushes you add an overhead of >50%. I believe these costs are exagerated. To convert a capability into sender-id a simple table lookup can be used. This requires a single TLB entry and a single L2 cache line (worst case). If IPC is frequent, which is the case in which you want high performance, the TLB entry is very likely to be present and probably even the L2 cache line. This is supported by your own description how access checks are done at user level (although this is actually the reverse as you point out, the methode stays the same): >In our case we use an object identifier in the message, which is a >handle to an object descriptor and do a reverse check (i.e. if the >thread is allowed to invoke that object). Costs: boundary check (can be >a simple AND) one MOV and a CMP. The permissions can go into the same >cache line. ===== Volkmar >A possibility you did not mention is a hybrid thread id which has an >thread and a descriptor part. The descriptor is kernel enforced. That >is what we currently have in V4 (please not that V2 and X.0 are >completely outdated!!!)--the version part of the thread id. Sorry, but I do not see how the version part could be used as the server defined word. You can't have multiple versions (read server defined words) of the same thread-id at the same time. ===== Volkmar >- local data structures--or do you want to share your cap-tables on NUMA >systems between processors? How do you plan to memory-manage those? I generaly don't worry too much about performance as long as it scales wth processor speed/count. This argument is indeed a sane one. However I do believe it is possible to use the techiques to gain better performance used at user-level can also be applied to a kernel-level methode. This does bring up another question. How do you memory manage TCBs in L4 on NUMA systems? ===== Volkmar >That is exactly the point. If you add that feature to the kernel you >pay on _every_ system, even if it does not need any security mechansims >at all (or only very rudimentary). Hence, moving it to user land >eliminates it from the critical path and makes other scenarios faster >(without, from my perspective, massively hurting systems which need and >want such security models). Whoch person with a sane mind would want to implement an unsecure operating system on top of a microkernel? That's just not a smart thing to do. The only reason microkernels still exists is because they offermore security and are more flexible. And unsecure systems are also systems that wnat maximum performance (so they don't want to run on top of a microkernel) and for that same reson don't need the flexibility. Unsecure operating systems no longer run on servers, workstations and dektops. They are only used for embedded systems, and those are unlikely to run ontop of L4. -- Rudy Koot _________________________________________________________________ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/

1 0

RE: IPC/Capabilities Overview
by Volkmar Uhlig 01 Jan '04

01 Jan '04

> -----Original Message----- > From: Rudy Koot [mailto:rudykoot@hotmail.com] > Sent: Wednesday, December 31, 2003 11:39 AM > The problem is that they only look at direct > costs of cycles spend on entering the kernel, doing IPC and > exiting tthe kernel. They also look at indirect costs of > TLB and cache misses caused by IPC, but strangely enough won't > look at the cost of checking access rights (probalby because > access checks are no longer part of the microkernel, but > of operating system policy). That is exactly the point. If you add that feature to the kernel you pay on _every_ system, even if it does not need any security mechansims at all (or only very rudimentary). Hence, moving it to user land eliminates it from the critical path and makes other scenarios faster (without, from my perspective, massively hurting systems which need and want such security models). > If you want to convince them, you have to make sure they eiter > count those costs also OR make sure they believe the added > IPC costs of capabilities are indeed neglectable. As far as I > could reason these added (compared to the thread-id methode) costs > would be: > > - One extra register spilled on the receiver side (to store > the server defined word) > - One extra memory access (to convert the capability into the > server thread id) [VTO] > - One extra memory access (to load the server defined word) > - One or more extra memory accesses (to locate the server > defined word and server thread id in the Thread Object Space) [VTO] And you forgot all the TLB entries you need. When moving it to user land you are able to optimize the lookups by: - clever choosing identifiers (your identifier space is unlimited and can be as small as zero bits) - efficient and combined lookup strategies (e.g. a file descriptor can contain the filepos and security identifiers) - combined calls, i.e. accessing multiple identifiers at once (write to n files at a time, multicast) - local data structures--or do you want to share your cap-tables on NUMA systems between processors? How do you plan to memory-manage those? - Volkmar

2 1

IPC/Capabilities Overview
by Rudy Koot 31 Dec '03

31 Dec '03

Just to avoid any confusion. Can you tell me if I got this right: There are three possible ways to restict/allow communication between threads, using * Thread IDs (current L4 v4 implementation) Any thread can communicate to any thread and send any message. Access checks need to be done by the server, that might need to verify some things using another 'security' server, requiring another IPC. The IPCs itself are very fast because no table lookups are necessary to verify if the communication is allows. However suity holes are much easier to created by buggy code that forgets to verify some accesses. Additionally the security checks are executed even slower than if they where done inside the kernel as in the other two methodes. These security checks can be done automatically using IPC redirection. This still requires an additional IPC, had some strange (unclean) quircks associated with it and I still doubt wether this methode is secure especially when used by buggy programs. * Virtual Thread Objects (possible L4 v5 implementation) Each thread has a kernel table attached to it (1) which lists the threads it can communicate to. These virtual thread objects can be grranted, mapped and unmapped just like flexpages. So when a message is received the server can be sure it is send by a thread that is mapped it's thread ID to. (1) Threads in the same address space might share the same table. * Capabilities (current EROS implementation) Capabilities are similar to Virtual Thread Objects except that they have a server defined word attached to them. I first want to make clear why the second and third methode are much better than the first: * Methode 1 is insecured when used with buggy programs. The fact simply is that most, if not all, programs are buggy. I agree with shap that the cost of a program should be measured in total resources used (dollars or additional programming time for example) and not just computational resources. * In a system that requires security the 2nd and 3rd methodes are actually faster because only a single, cimple kernel check needs to be made agisnt several complex user checks for methode 1 (is this realy true? comments please). L4 is designed to be secure anyway and is therefore already to slow for systems that don't require security, so the penalty the insecure systems woudl suffer does not apply. * Additional security benefits are that the internal thread structure is not revealed to every program running on the system and some protection against DoS attacks is offered. Now I want to make clear why capablities are much better than virtual thread objects: * The extra word does not seem to decrease performance in any way (is this true?) so it a free feature, that can be used but doesn't have to. * The server defined word will probably be used to store a pointer to some client specific data structure containing important information that needs to be access often. You might say, yeah well mbut you can calculate this address from the sender ID, but this no longer works when clients start to grant and map server objects/capabilites to eachother, because the server doesn't know about these actions, unless some complex, slow protocol is used to update the serves information. My conclusion is that Virtual Thread Objects/Capabilities are far supiror than just using Thread IDs and that the server defined word of Capabilities are very important to manage information of a server. The size of the capability should be equal to the pointer/word size of the machine. Constructive criticism is very much appreciated, Rudy Koot _________________________________________________________________ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/

2 1

Object descriptors vs sender id
by Einar Karttunen 23 Dec '03

23 Dec '03

Hello I would like to make few notes on the recent discussion on Eros object descriptors vs the L4 sender id. Sorry if I have misunderstood parts of the discussion. The main problem is imho how can the sender know the client is entitled to use the service? Eros: - The sender just marks this information inside the descriptor. - Access check is done with a simple comparison - The state is not visible to the client - ipc is a little bit slower L4: - The state is either - visible to the client - the client can mutate it -> expensive checking - the client can pass it to others without supervision - stored inside a non-related thread - instead of two ipc operations we need three (C->S->C becomes C->store-thread->S->C) - stored inside server (more complexity, granting permissions is hard) - All servers need to store client state. - Upon each request we typically need a hash lookup - Clients need to communicate passing descriptors to the server - The pager adds a prefix scheme does not really help as the server does not necessarily trust the clients pager. The following come into mind as problem cases: - A client using thread pool - A permission for all children of a thread (or capabilities in general) Also the Eros model seems to map better to a distributed enviroment. In L4 one would need to allocate one thread per remote client/thread/set of permissions while in the Eros model just hold different capabilities. Modelling L4 with Eros - The server uses a word of data in the descriptor - The kernel fills it with the caller-id (needs hacking) Modelling Eros with L4 - This seems quite difficult to archive without additional lookups. - How can one build a *safe* mechanism on top of L4? - All API based approaches fail because malicious clients can send handcrafted messages. - Einar Karttunen

3 2

RE: Comparing IPC and capability invocation
by Volkmar Uhlig 22 Dec '03

22 Dec '03

> -----Original Message----- > From: Jonathan S. Shapiro [mailto:shap@eros-os.org] > Sent: Thursday, December 11, 2003 9:57 AM > > By all means we should discuss, but let me attempt to clarify. > > ALL communications are invocations on objects. The only questions that > exist in principle are: > > 1. What restrictions are imposed on the TYPE of object that can be > invoked? > > 2. Is the object namespace extensible by user-mode code. That is, > can user-mode servers present objects or interfaces that appear > to the invoker to be "first class" in the same sense that kernel > supported objects are first class. > > L4 imposes the restriction that the only invocable object type is > "process" (or in some cases thread). We only have threads, there is no notion of processes (I'm talking about V4/X.2). > L4 does *not* (today) provide means to allow a server to extend the > object name space. There is no reason, "objects" are user-managed things. Allowing extension doesn't bring you any benefit. Transparency can be implemented in a user-level library (without any overhead). How I understood your description is that you cache information about what user object types you have in the kernel. That costs you another check on the critical path. You argue that single method of invocation is a good thing--yes. We have that, it is called IPC. For all kernel objects (we have threads, AS, and memory) I don't see a benefit of a unified interface. That leads to IOCTL and that is a mess. If you want to use a generic interface (i.e. IPC) to _all_ kernel objects you can always place a protocol translation layer in between at almost no cost (threads and AS are manipulated very infrequently). This allows for optimizations you can't perform otherwise. > My first point is probably self-explanatory, so I will expand only on > the second. > > In L4, if a client wishes to perform an operation on a file, > the "name" > of the file must be passed as an argument to an IPC. The invocation is > something like: > > file_server->invoke(file-id, operation-id, ... other args ...) > > Because "file" is not a kernel-supported object, the protocol mandates > that the sender provide an additional argument in the IPC > invocation. In > the EROS philosophy, we would argue that these objects are therefore > "second class" and that this is bad for several reasons: > > 1. The invoker should not know the server identity. That should > be known only to the file object. > 2. It is difficult to transparently virtualize objects when their > invocation patterns are different. 1) Assume threads have zero costs. That means you can have one thread per object and the thread id is your identifier. 2) Assume you want to share a thread for multiple object invocations (and threads have costs > 0). The additional check you have to perform on _every_ object invocation (code for checking, table access, I and D-cache footprint etc) in EROS has probably a higher overhead than the additional parameter on the invocation which is untouched by the kernel. For concurrency (multiple worker threads) you can use LIPC in L4 so you can perform load distribution in user land. 3) Virtualizing objects is only a question of protocols. That is something _userland_ defines. So why should virtualization be difficult??? (I'm puzzled). Furthermore, how do you deal with situation where your object space is full? Is the object space local or global? We can dynamically extend and shrinl the object space (e.g. use a single bit if we have only 2 object types). > Next problem: > > The server must then run some function: > > get_permissions(sender-id, file-id) -> permissions > > to determine what operations are permitted. Note that if this > operation > is performed faithfully and correctly, it is impossible to emulate > correctly the behavior of the UNIX I_SENDFD socket operation without > many additional calls to a shared service -- the design of > the operation > makes descriptor transfer an inherently expensive operation. I would say that is a weak argument considering all the shortcomings of the POSIX API. Implementing fork within a distributed system is very expensive--so what? We know for more than 10 years that fork is broken. I will look into I_SENDFD into more detail and try to give you a satisfactory answer. > Descriptors, which *can* be used as a foundation for certain kinds of > security, suddenly become extremely inefficient because they cannot be > passed without consulting a third party. You can cache that information in user land after validation or use shared memory with the authentication server. That is what you basically do in the kernel. > The server-defined-bits portion cannot be examined by the > client. It is > provided to the server during invocation. The server can > interpret these > bits in any way desired: as an object id, as a facet id, as permission > bits, as some mix of these. > > The presence of these bits does not preclude invocation of the server > qua server; the server merely assigns to itself an arbitrarily chosen > value of "server-defined-bits" to name the server itself. So you provide an in-kernel cache for some identifiers (call it bits) which are unforgeable. How much of your register real estate do you give up for that? What when the size is exceeded? > Because these are architecturally insufficient to implement an > efficient, secure, object-based operating system. Hmm, actually that is a question of what you try to implement. What if you don't want an object-based OS? Do you incur a significant overhead with your model? I'm curious how a Linux kernel would perform on top of EROS--I could imagine that your security model has a measurable overhead. And then we have to start a discussion on generality of uKs. > Our experience has been that relying on such clients to specify the > intended operation is not robust. The flow of permissions in complex > programs is not well localized, and it is very easy to write a > subroutine designed for one purpose that does some mildly dangerous > thing and then call it (by programmer error) in the middle of some > sequence of code where care is required. > > Tying permissions to the object descriptor does not prevent the > programmer from passing the wrong descriptor, but it does help a great > deal in localizing the scope of programmer attention that is > required to resolve these problems. This sounds like you are suggesting kernel design based on bad programming habits. Are you willing to pay the overhead? We don't. - Volkmar

4 3

Comparing IPC and capability invocation
by Jonathan S. Shapiro 21 Dec '03

21 Dec '03

[I apologize in advance for both the length and the depth of this note.] One of the long-term design differences between L4 and EROS is something I think of as the "threads vs. objects" distinction. In L4, all invocations are IPC invocations performed on thread ids. In EROS, all invocations are capability invocations performed on capability indexes. In the current EROS implementation, the capability indexes are an offset into a per-process capability table. In my opinion, the original "name by thread-id" design in L3/L4 had two architectural issues: 1. It exposed the location of the target thread within the thread table. Because of the tight relationship between threads and tasks, this had the side effect of exposing potentially significant information about the internal structure of the recipient. It also made relocating a thread within the table challenging, because the thread's "address" was sitting in data space in every client, where one could not update it. My opinion was that the thread-id was effectively an absolute address, and that it should have been a virtual address that was decoded w.r.t. a sender-defined name space. 2. Because the thread id's and task ids were inter-related, there seemed to be a number of awkward restrictions on allocation of task structures. In particular, it was necessary to know in advance how many threads (max) were going to be required, and it was possible for fragmentation to prevent successful allocation even when the necessary number of thread entries was available. This seemed unnecessary. In addition, I thought it would be better if an address space could exist without any threads at all, and conversely if a thread could exist (though not execute) without any address space. From the EROS experience, I felt that non-process address spaces were useful. I'm not sure that threads without address spaces are useful, but I do believe that threads and address spaces are separable abstractions, and that it is good to keep them so. >From various conversations, I believe that the L4 team has addressed the second issue, and is considering a number of solutions to the first, most notably "thread address spaces". In this approach, the current thread id is replaced by an offset (or address) into the thread address space, and an application supplies this thread address instead of the thread id of the previous design. If I understand matters correctly, this idea has not yet been incorporated into the current L4 implementation but there seems to be agreement that someday it should be. I may have misunderstood, but I also believe that the power of two restriction on task allocation has been removed, and that any thread can now be associated with any task. As long as there is no operation allowing a sender to *read* the real thread id out of the thread address space, then the current plan for L4+thread-spaces would implement something very close to the future EROS design. There are two differences: 1. The current EROS design is currently expressed in terms of capability registers. We have decided that this should be replaced with a capability address space. Conceptually, this capability address space serves the same role in our architecture that the thread address space serves in Ln. 2. The elements indexed by this address space are capabilities in EROS, but thread-ids in L4. This is the heart of why I think of this as the "threads vs. objects" distinction. One way to think about this [the motivation will become clear in a moment] is that the L4 thread address space is actually a descriptor address space, but that all of the descriptors in this space are restricted to be thread descriptors. Since this appears to be the *only* remaining difference in this area of the Ln and EROS designs, I'ld like to make a case based on the EROS experience for why descriptors should be considered seriously in a future system. First, switching to descriptors should not significantly change IPC performance. A descriptor is probably a larger data structure than a thread id, but in both cases there is a load instruction at the end to place the target thread address into a register. This is true in both a thread-id design and a descriptor design. The difference would be only that the thread structure pointer might live at a different offset. Second -- and here I must draw for a moment from the EROS experience -- unifying all invocations behind a single descriptor abstraction has been incredibly useful in the EROS system. As with L4, we have a generalized invocation mechanism, but we can apply this mechanism to arbitrary objects. Introducing a generalized descriptor notion into the architecture does NOT necessarily imply a large increase in kernel size. When Leendert van Dorn and I were considering kernel design at IBM, we concluded that most of the resulting kernel descriptor types can be served by well-known user mode servers if desired. The decision about whether or not to put support in the kernel for these object types becomes purely an engineering decision. The EROS implementation chose to place these implementations in the kernel, and in one or two cases this is probably essential, but in general it is NOT necessary. The difference between a thread-id and a descriptor is that a descriptor takes the form (resource-type-code, resource-name, type-specific-data-word) where a resource-type-code is assigned for each kernel resource that is exported by means of a descriptor. Borrowing from EROS, the descriptor types that seem likely to be useful are: void -- descriptor that responds with "unknown" to all requests flexpage -- name of a flexpage thread -- a thread-id (interface to the process abstraction) object -- a particular object served by some thread In flexpages, the type-specific field holds permissions. In objects, it holds an object id. In threads, it might be unused. The EROS implementation also includes linked list pointers so that outstanding descriptors can be efficiently revoked when a resource is destroyed, but this is a detail of implementation -- other representations are possible. On revocation, outstanding descriptors become void, but we have sometimes thought that it would be better to mark change them from "type X descriptor" to "type INVALID X descriptor". This would facilitate debugging. An added word about the 'object' type may be useful, since it reflects a significant philosophical difference between L4 and EROS. In EROS, a client invokes an object. This object may be an entire server (a process) or it may be a particular object that is served by that server. In L4, the "particular object" case is customarily handled by passing an object id as an argument to the IPC operation. One problem with this is that the object id can be forged by the client. It is not entirely clear to me whether forged object ids are a serious problem in the absence of persistence, but my instinct is that they are *sometimes* a problem, and that including them is therefore desirable. The "IPC indirection" design proposed by Trent Jaeger et al. many years ago included a similar uninterpreted word. shap -- Jonathan S. Shapiro <shap(a)eros-os.org>

5 11

Re: Comparing IPC and capability invocation
by Rudy Koot 12 Dec '03

12 Dec '03

I've been following this discussion and I first want to say that I agree that threads should be virtual objects. The cuse of thread IDs on L4 now requires eiter the receiver to check if the sender had the rights to send to it or the use of IPC redirection. Both methodes make it easy for security holes to creep into the code and are (as you correctly pointed out) even slower than using virtual objects. And if the map, grant and unmap operations can be used on them they are even more flexible than the current implementaion. I'm however still doubting wherer EROS capabilities are necessary, because I believe the arguments you have given are entierly correct >In L4, if a client wishes to perform an operation on a file, the "name" >of the file must be passed as an argument to an IPC. The invocation is >something like: > > file_server->invoke(file-id, operation-id, ... other args ...) >In EROS, the corresponding invocation would be: > > file_capability->invoke(operation-id, ... other args ...) While this might be true at the lowest level, high level abstactions will geneally hide this fact from you, making this only an aestatic argument unless you can tell me why one of them is technically better/safer. And I think the examples you give here have been given in a form that is more favorable for de EROS case. The true inkovations would normally look more like this: L4: invoke(file_server_thread, file_id, operation_id, other_args) EROS: invoke(file_capability, operation_id, other_args) Again I want to stress that this is normally hidden by the high level language interface. Some interessting thing can also be done with alternative designs. For example the open call op the file_server creates a new thread that handles the calls to that file. The calls would now look like this: L4: invoke(file_thread, operation_id, other_args) EROS: invoke(file_capability, operation_id, other_args) Looks pretty similar doesn't it. The difference is now that in L4 the messages are send to a collection of threads while in EROS it is only one thread. -- Rudy Koot _________________________________________________________________ Play online games with your friends with MSN Messenger http://messenger.msn.nl/

1 0