Problems with l4linux

[Adam Lackorzynski]

On Thu Oct 23, 2008 at 21:54:08 +1300, Valery V. Sedletski wrote:
> On Wed, 22 Oct 2008 19:12:59 +0200, Adam Lackorzynski wrote:
> 
> >
> ...skipped...
> >
> >Ok. There's an option in the Fiasco configuration to let you set IOPL3
> >(and thus lets you do cli/sti). This is an extra option because if you
> >enable it Linux can stop the machine. Anyway, that sould fix the X
> >problem. 
> 
> Now I switched on Fiasco option about IOPL 3 and an error with cli disappeared,
> but another problem -- GPF somewhere in Fiasco. The serial log is like this:
> 
> loader  | vmlinuz26: Starting application using libld-l4.s.so
> loader  | vmlinuz26,#f: Loading binary
> rtc     | Date:23.10.2008 Time:08:17:15
> loader  | vmlinuz26,#f: Loading ldso
> loader  | vmlinuz26,#f: Starting libld-l4.s.so at 000138e0 via 0000cbe8
> l4lx    | ======> L4Linux 2.6 starting... <========
> l4lx    | Linux version 2.6.26-l4-svn120-dirty2 (root at localhost) (gcc version 4
> l4lx    : .2.2 20071128 (prerelease) (4.2.2-3mdv2008.0)) #7 Thu Oct 23 21:07:12
> l4lx    :  PETST 2008
> l4lx    | Binary name: vmlinuz26
> l4lx    | Linux kernel command line (8 args): mem=100M video=l4fb:refreshsleep:
> l4lx    : 200 l4fb.nograb=1 load_ramdisk=1 ramdisk_size=40960 root=/dev/ram l4e
> l4lx    : nv_rd=(nd)/tftpboot/drops/ramdisk/drops-fp.rd panicblink=0
> l4lx    | Image: 00400000 - 007b9000 [3812 KiB].
> l4lx    | Areas: Text:     00400000 - 006c3000 [2828kB] (a bit longer)
> l4lx    |        Data:     006c3000 - 006e46d8 [133kB]
> l4lx    |        Initdata: 006e8000 - 00726000 [248kB]
> l4lx    |        BSS:      00728000 - 007b8bb0 [578kB]
> l4lx    | l4lx_thread_create: Created thread 0f.03 (tamer0)
> l4lx    | Tamer0 is 0f.03
> l4lx    | Using tamed mode.
> ROOT: Sending all ports (for cli/sti) to task #0d
> l4lx    | Got 65536 out of 65536 I/O ports
> l4lx    | Running at IOPL 3
> l4lx    | Connecting to l4io server.
> l4lx    | l4lx_thread_create: Created thread 0f.04 (cpu0)
> l4lx    | main thread will be 0f.04
> l4lx    | l4env_register_pointer_section: addr = 006e6000 size = 266240
> l4lx    |      sec-w-init: virt: 0x006e6000 to 0x00726fff [260 KiB]
> l4lx    |      sec-w-init: Number of physical regions: 1, 266240 Bytes
> l4lx    |      sec-w-init: 1: Phys: 0x012a0000 to 0x012e1000, Size:   266240
> l4lx    | l4env_linux_startup thread 4.
> l4lx    | main thread: received startup message.
> l4lx    | Main thread running, waiting...
> l4lx    | setup_l4env_memory: Forcing superpages for main memory
> l4lx    | Main memory size: 100MB
> l4lx    |     Main memory: virt: 0x00800000 to 0x06bfffff [102400 KiB]
> l4lx    |     Main memory: Number of physical regions: 1, 104857600 Bytes
> l4lx    |     Main memory: 1: Phys: 0x06400000 to 0x0c800000, Size: 104857600
> l4lx    | Filling lower ptabs...
> l4lx    | mainmem = 800000
> l4lx    | Done (1060 entries).
> l4lx    | l4env_register_pointer_section: addr = 00728000 size = 593920
> l4lx    |             end: virt: 0x00728000 to 0x007b8fff [580 KiB]
> l4lx    |             end: Number of physical regions: 1, 593920 Bytes
> l4lx    |             end: 1: Phys: 0x006f2000 to 0x00783000, Size:   593920
> l4lx    | l4env_rd_path: (nd)/tftpboot/drops/ramdisk/drops-fp.rd
> l4lx    | Loading: (nd)/tftpboot/drops/ramdisk/drops-fp.rd
> l4lx    | INITRD: Size of RAMdisk is 40960KiB
> l4lx    | RAMdisk from 10000000 to 12800000 [40960KiB]
> l4lx    | l4lx_thread_create: Created thread 0f.05 (timer.i0)
> 
>     ---------------------------------------------------------IP: f003622b      
>     --General Protection
> [l4lx.main] (f.02) jdb: 
> 
> So, this is iret instruction somewhere on return from a syscall, if I understood correctly.
> Maybe, my Fiasco config is wrong?

Rather not. Can you tell me at which position the f.2 is in user-land?
That would be interesting.
 
> >(My X version also tries to get ports 0-1024 (or similar)
> >before doing the iopl thing but AFAIK this has only been added shortly.)
> >
> 
> -- so, in normal situation, it should not be (requesting access to some ports before doing iopl(3)), 
> but if it takes the place, then for it to work, the Fiasco option mentioned must be enabled. But in
> normal situation, this option is not needed?

X is very demanding wrt permissions. More recent version should behave
better though.

> And the question: what does cli instruction do? I guess this must trigger an I/O page fault for I/O
> pages to be mapped? Am I right? 

CLI disables interrupts. Allowing this in user-land is a major security
breach.

> >> >> PS: When I did "modprobe serial_cs" udev created ttyS0..ttyS3 devices but still no comm port access. So, access to video
> >> >> and comm-ports don't work but network and disks are working. Why could it be?
> >> >
> >> >Sorry, no idea with the card. It doesn't say anything strange in dmesg?
> >> >
> >> 
> >> Only that serial_cs module prints the message that it could not access
> >> high memory. I hope this error disappear after linux will get I/O
> >> privileges
> >
> >I guess not. Which address? Anyway, I guess it should ioremap those...
> >
> 
> According to scanpci, Cardbus controller and serial (modem) card use these addresses:
> 
> pci bus 0x0006 cardnum 0x09 function 0x00: vendor 0x104c device 0x8031
>  Texas Instruments PCIxx21/x515 Cardbus Controller
>   STATUS    0x0210  COMMAND 0x0007
>   CLASS     0x06 0x07 0x00  REVISION 0x00
>   BIST      0x00  HEADER 0x82  LATENCY 0xa8  CACHE 0x08
>   BASE0     0xb8008000  addr 0xb8008000  MEM
>   BASE1     0x020000a0  addr 0x020000a0  MEM
>   BASE2     0xb00a0706  addr 0xb00a0700  MEM
>   BASE3     0x88000000  addr 0x88000000  MEM
>   BASE4     0x8bfff000  addr 0x8bfff000  MEM
>   BASE5     0x90000000  addr 0x90000000  MEM
>   BASEROM   0x000044fc  addr 0x00000000  not-decode-enabled
>   MAX_LAT   0x05  MIN_GNT 0xc0  INT_PIN 0x01  INT_LINE 0x0a
>   BYTE_0    0xc0  BYTE_1  0x17  BYTE_2  0x07  BYTE_3  0x30
> 
> according to /proc/iomem:
> 
>   88000000-8bffffff : PCI CardBus #07
> 90000000-93ffffff : PCI CardBus #07
>     b8008000-b8008fff : yenta_socket
>   b8010000-b8010fff : pcmcia_socket0
> 
> And also it uses these I/O ports (according /proc/ioport):
> 
> 03f8-0407 : pcmcia_socket0
>   03f8-03ff : serial
>   0400-0407 : serial
>   4400-44ff : PCI CardBus #07
>   4800-48ff : PCI CardBus #07
> 
> here
> 0x3f8-0x3ff is /dev/ttyS0
> and
> 0x400-0x407 is /dev/ttyS1

Some of those addresses are quite low but unfortunately I don't have an
idea what they're used for.



Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/