OSDev.org

Posted: **Thu Dec 27, 2007 2:07 pm**

Hey all,

I've just released a release candidate for version 0.2 of my OS, Exclaim. It'd be great if people could test it on as many machines as possible so I can squish any bugs that might not have come up on the few it has been tested on.

Current features

Preemptive (software) multitasking
Physical and virtual (mmap-based) memory managers
ELF kernel module and application loading
VFS layer
Keyboard driver (i8042)
Some userspace apps (init, shell, ls, mkdir, mount, umount, uname, cat)
ATA read support (via PIO, supports LBA-48 only right now)
EXT2 read support (can mount ext2 partitions, do ls and read files off them)
APIC timer support (used over the PIT if supported)
V8086 mode monitor
Simple TTY driver, supports line buffering and escape codes for colours
Small C library, written from scratch (a lot of stuff missing right now, but there's enough for the moment)

Things that need testing
This is a list of things that need particular testing as they have been flaky for me, or just have not received much testing

VBE driver - doesn't seem to work on some graphics cards - compile with VBE support (or use one of the images on the download page), and run vbetest from the shell
ATA and EXT2 drivers - try mounting ext2 partitions and reading stuff off them, there is a hard disk image provided on the download page for use with QEMU, on which /Devices/ata0d0p0 is an ext2 partition. Also, try reading from the raw devices (use cat)

Also, just general testing is needed, as in prodding around with the shell and apps to see if you can find bugs.

And, if anyone is really, really bored, you could try writing an app and see if you can crash the kernel in any way, because I'm sure it's possible somewhere

. The build system is fairly simple to add another app to, just look inside the apps directory.

Links

Home page - http://exclaim.tuxtalk.org/
Release page (with download) - http://exclaim.tuxtalk.org/index.php?q=releases:02rc1
Bug tracker - https://bugs.launchpad.net/exclaim/

Thanks a lot in advance to anyone who tests, and I hope you like it

- Alex

Posted: **Thu Dec 27, 2007 4:27 pm**

Hi .. still some security problems

elf32.c lines 136 - 142

Code: Select all

 offset = ehdr->e_phoff + (ehdr->e_phentsize * i);
if((offset + sizeof(Elf32_Phdr)) >= get_alloc_size(file)) {
  dprintf("elf: phdr points outside the file, userspace is trying to kill us\n");
  return -EINVAL;

 		
phdr = (Elf32_Phdr *)((ptr_t)file + offset);

because of the "+ sizeof(Elf32_phdr) offset can still be a huge number that wraps back past 0 when when the sizeof is added. This will let you point phdr behind "file". Whether this can be used to crash the kernel I did not investiage, but it would be annoying since you would have to re-create another elf file in memory where you point phdr since you have checks after it.

elf32.c line 190-191

Code: Select all

memcpy((void *)phdr->p_vaddr, file + phdr->p_offset, phdr->p_filesz);
memset((void *)(phdr->p_vaddr + phdr->p_filesz), 0, phdr->p_memsz - phdr->p_filesz);

phdr->p_offset and phdr->p_filesz are not checked letting you crash the kernel in both the memcpy and the memset.

Posted: **Thu Dec 27, 2007 4:43 pm**

onto vmm.c

line 793

Code: Select all

793 		         addr = (unsigned long)start;
794 		        end = addr + length;

If length is controlled then end can be behind addr and its not checked later

in elf32.c

Code: Select all

static int elf32_get_module_sym
...
sym = (Elf32_Sym *)(sect->sh_addr + (sect->sh_entsize * num));
...
 225 	886 	                 strtab = (char *)GET_SECT(data, sect->sh_link)->sh_addr;
226 		                sym_name = strtab + sym->st_name;
227 	873 	
228 		                if(modules_lookup_sym(sym_name, sym_val) != 0) {

Integer problems here...
I looked into modules_lookup_sym and it gets the addresses for a symbol name from your nicely made symbol table. I think the attack vector could be setting up a spoofed symbol table entry in memory somewhere, pointing the symbol your looking for to it. and now the kernel has the wrong address for a valid symbol that the attacker controls.. so when you call kprintf you are really calling my wrapper function that does setuid(0) ( works since the kernel is calling it ) and then execve's /bin/sh for a nice root shell

this is fun x)

Posted: **Thu Dec 27, 2007 5:13 pm**

Hi I tried to compile the kernel:

I got this with 'make' , 'make btest' and 'make qtest'

Code: Select all

LD      build/i386/apps/bin/init
ld:/home/tgo/ex/exclaim-0.2.0-rc1/elibc/app-i386.ld:72: syntax error
make: *** [/home/tgo/ex/exclaim-0.2.0-rc1/build/i386/apps/bin/init] Error 1

ld:

Code: Select all

 ld --version
GNU ld version 2.16.1

I realize its in elibc but maybe you have seen this error before? I tried a bunch of different kernel .config options but nothing fixed it.

Posted: **Thu Dec 27, 2007 5:53 pm**

Was messing with the terminal and found some weird behavior but cannot determine what causes it

The attached image is a screenshot of it in vmware

Posted: **Thu Dec 27, 2007 5:59 pm**

Head shot!
( I think I told you about this already in pm a few weeks ago but meh )

the command typed was "cat "

The attachment shows it... It was the problem where commands assume that if a space follows them that other stuff does also. so it splits the line into chunk1 chunk2 based on space then works with chunk2 which is null

Posted: **Fri Dec 28, 2007 1:47 am**

Ok, I've committed something which I think fixes the ELF and VMM problems. The symbol table cannot be pointed elsewhere, because the only way to make it look in another symbol table is to overwrite some kernel memory, and that code only gets a name for the symbol, looks it up, and puts the address to where it points in sym_val.

The terminal bug is already reported (https://bugs.edge.launchpad.net/exclaim/+bug/178930) - it's caused by the TTY driver not handling certain keys properly, like tab and arrow keys. I'll fix it soon.

And, that panic isn't supposed to happen, even if EShell isn't splitting stuff up properly. I'll fix it now. Edit: Fixed the panic and EShell's splitting

Finally, the compile error is just because your older binutils doesn't particularly like the linker script, which is based on one from 2.17. I can commit a fix, but you should also use the cross-compiler where possible (see the release notes on the site)

Thanks!
Alex

Posted: **Fri Dec 28, 2007 2:15 am**

looks good except in elf32.c line 190 where you have

Code: Select all

if(phdr->p_offset >= get_alloc_size(file) ||
          (phdr->p_offset + phdr->p_filesz) >= get_alloc_size(file)) {

Like you have the explicit check for p_offset add the same thing for p_filesz because the second part ( offset + filesz ) can still wrap ( unless fileze is restricted somewhere else i missed ) letting you pass a negative value to memcpy using a large p_filesz.

EDIT: Also I updated my binutils and everything compiled correctly!

Posted: **Fri Dec 28, 2007 3:17 am**

I tried it QEMU to much success. Bochs, however, didn't go so well. Here are the (I hope) relevant sections of the crashlog

Code: Select all

INIT: Loading /System/Drivers/vbe.mod
exec: matched module /System/Drivers/vbe.mod to type ELF32
paging: created a new address space (0xE010F13D, pdir 0x43F000)
vmm: created free region at address 0x400000, size 3217031168
vmm: created free region at address 0x0, size 4194304
vmm: created used region at address 0x0, size 4096
vmm: inserting region 0xE0110359 into VM space 0xE010F13D
vmm: start region is 0xE010F1A9 (base 0x0, end 0x400000)
vmm: consistency check passed for VM space 0xE010F13D
vmm: created used region at address 0x1000, size 585728
vmm: inserting region 0xE01103B1 into VM space 0xE010F13D
vmm: start region is 0xE010F1A9 (base 0x1000, end 0x400000)
vmm: consistency check passed for VM space 0xE010F13D
vmm: created used region at address 0x90000, size 458752
vmm: inserting region 0xE0110409 into VM space 0xE010F13D
vmm: start region is 0xE010F1A9 (base 0x90000, end 0x400000)
vmm: consistency check passed for VM space 0xE010F13D
vbe: getting VBE info...
vmm: pagefault at 0x2000 caused 0x440000 to be mapped to 0x2000
vmm: pagefault at 0x40 caused 0x0 to be mapped to 0x0
vmm: pagefault at 0x1FFE caused 0x442000 to be mapped to 0x1000
vmm: pagefault at 0xC00E6 caused 0xC0000 to be mapped to 0xC0000
vmm: pagefault at 0xC5DA4 caused 0xC5000 to be mapped to 0xC5000
vbe: VBE is not supported
vmm: destroying VM space 0xE010F13D
exec: module 'vbe' failed init.
init: modload: Operation not supported

Code: Select all

The kernel made a boo-boo and couldn't fix it
Error: Attempted to kill init! (exit status: 1)
Stack trace:
  _panic+403 (addr: c010e323; frame: e0005236)
  process_exit+331 (addr: c010ed07; frame: e0005266)
  sys_exit+33 (addr: c010ed29; frame: e0005296)
  _sc_handle_regs+24 (addr: c0101d98; frame: e00052b6)
  syscall_handler+160 (addr: c0103e8c; frame: e00052d2)
  intr_handle+41 (addr: c01032c9; frame: e0005302)
  isr_common+63 (addr: c0101d03; frame: e0005322)

Posted: **Fri Dec 28, 2007 3:51 am**

Yep, I've just fixed that in the source tree, I'll upload a new build in a minute. The problem was init exiting when it fails to load a module, and the VBE module wasn't loading because your bochs is compiled without VBE support.

Posted: **Fri Dec 28, 2007 3:58 am**

Odd... Not according to my bochs log

Code: Select all

00000000000i[     ]   VGA extension support: vbe cirrus
...
00000000000i[CLVGA] VBE Bochs Display Extension Enabled

Posted: **Fri Dec 28, 2007 4:04 am**

That's... interesting. I'll look into it - the VBE driver is a bit dodgy anyway. Anyway, here's a new build that doesn't die if a module fails to load, and has a few bugs fixed:

http://www.alex-smith.me.uk/files/excla ... om-dbg.iso

If you were building from the source, just grab the latest code from bzr (you might need to install it):

Code: Select all

bzr branch http://bazaar.launchpad.net/~exclaim-dev/exclaim/trunk

Thanks!
Alex

Posted: **Fri Dec 28, 2007 8:16 am**

The VBE bug currently happens on all NVIDIA systems, and Bochs regardless of BIOS and VGA Extension, so i'm guessing it might be a v8086 bug. Still, thats not my dept

This bug can be tracked in the bugtracker at:
https://bugs.launchpad.net/exclaim/trun ... editstatus

Sadly I know no way to bypass this right now other than to make a non-vbe build

(btw, i'm the Exclaim webmaster and also do stuff like bugs

)

Posted: **Fri Dec 28, 2007 8:27 am**

No, it's a different bug. It's not even detecting VBE on Bochs

Posted: **Fri Dec 28, 2007 8:28 am**

Oh.

I can has recorrecting

Ill open a new ticket for this - Actually, dont need to as the title of 178787 is too vague

OSDev.org

Test request: Exclaim 0.2.0-rc1

Test request: Exclaim 0.2.0-rc1