Callum's Code Blog

Bug Blog: execing a shell

Thu, 01 Apr 2010 22:30:50 +0100

I just spent an hour tracking down a bug involving the exec syscall. I was trying to implement a "shell" function for my programming language project. Something like this:

exitcode = shell("ls -l");

On UNIX-like systems, this involves forking off a child process that will exec the command. The parent process then waits for the child to finish and returns the exit status. Simple.

However, unlike CreateProcess under Windows, the UNIX style exec syscall requires the caller to parse the command line arguments for the new image. Since I want the user of my shell function to be able to pass anything they could type on the command line, parsing the command line arguments is not a trivial matter.

The bug

Not to worry though, I can use the sh command to do the parsing for me. I simply transform the argument to the shell function into "/bin/sh -c '<command>'". Now the problem is reduced to execing /bin/sh with 2 arguments.

But it didn't work. I got mysterious errors of the form "-c: can't open <command>".

Why?

The execve syscall (the low level exec syscall on Linux) takes as one of it's parameters an array of arguments for the new image. I was passing the array ["-c", "<command>"]. Wrong!

The command line arguments array on UNIX always starts with the name under which the binary was invoked, as any C programmer will tell you. So the shell was being invoked under the name "-c" with the single argument "<command>" which it tried to interpret as a shell script. Hence the error "-c: can't open <command>". The "-c" shell couldn't run the "shell script" called "<command>".

x86-64 assembly on Linux - syscalls

Thu, 21 Jan 2010 03:56:49 +0000

There are plenty of tutorials showing how write Linux programs in x86 assembler, a good resource is http://asm.sourceforge.net. However, there is very little on 64bit x86 assembler (x86-64). x86-64 is very similar to its 32bit counterpart. The main difference is that the registers are wider and there are more of them. You might think this would make it easy to adapt 32bit code to run in 64ibt mode under Linux.

Of course, there are a few gotchas. Linux has a completely different system call ABI under 64bit mode. The syscalls have different numbers and are called in a completely different way. Depending on how your kernel was compiled though, the 32bit interface may be present and usable as well (lkml).

In ignorance of this situation, I wrote a whole lot of code making simple 32bit syscalls from 64bit mode. It worked just fine on my Ubuntu system. Then I tried it under 64bit ttyLinux, a minimalist Linux distribution. My programs crashed as soon as they hit the first syscall.

If you want your assembler programs to work reliably across different kernels and distributions, you ought to use the correct ABI.

So, how does it work? It's based on the x86-64 UNIX C ABI which goes like this: arguments 1-6 are passed in the registers RDI, RSI, RDX, RCX, R8, R9. The result comes back in the RAX register, if 64bits isn't enough the high bits are in RDX. The parameter registers plus R10 and R11 are clobbered, the rest are saved. C's int type is 32bits, C's long type is 64bits. It's all described in this document.

For the 64bit syscalls, parameter 4 is passed in R10 instead of RCX. RCX is still clobbered. The syscall number is passed in RAX, as in 32bit mode, but instead of the "int 0x80" used in 32bit mode, 64bit syscalls are made with the "syscall" instruction. The syscall numbers can be found in the Linux source code under arch/x86/include/asm/unistd_64.h.

I'll finish this off with an example:

[bits 64]

section .text
global _start
_start:                ; ELF entry point
mov rax, 1             ; sys_write
mov rdi, 1             ; STDOUT
mov rsi, message       ; buffer
mov rdx, [messageLen]  ; length of buffer
syscall

mov rax, 60            ; sys_exit
mov rdi, 0             ; 0
syscall

section .data
messageLen: dq message.end-message
message: db 'Hello World', 10
  .end:

compile with "nasm -felf64 filename" followed by "ld filename.o". No libraries needed, this code stands alone.

Happy Hacking

GTKSourceView language definition for NASM

Tue, 25 Nov 2008 03:43:41 +0000

Update 22/7/2010: high register/hex number confusion cured

Although I generally like gedit (GNOME Editor), I was disappointed to discover that it doesn't have syntax highlighting for x86 assembler. It turns out that adding a new syntax highlighter is as simple as writing a little xml file and putting it in GTKSourceView's directory. On my Ubuntu system this is /usr/share/gtksourceview-2.0/language-specs/.

Here's the file in case you're interested.

Centering a div in the window

Thu, 10 Jul 2008 04:55:21 +0100

Ever wanted to center a panel in the middle of the browser window? There's a lot of code out there that claims to do this, but it isn't standards compliant and doesn't work on all browsers. But never fear, there is an easy way to do it without any browser specific hacks.

First, you need a couple of styles:

body {
  background-color: #000000;
}

.reference {
  background-color: transparent;
  position: absolute;
  top: 50%;left: 50%;
  width: 1px;height: 1px;
}

#panel {
  position:absolute;
  left:-485px;top:-256px;
  width:970px;height:512px;
  background-color:#FFFFFF;
}

Now the html:

<div class="reference">
  <div id="panel">
    Your content here
  </div>
</div>

The reference style creates a 1px by 1px div centered in the middle of the window. Inside this div is the panel. Normally this would place the upper left hand corner of the panel in the center of the window. To correct for this, the left and top properties are set to -(width/2) and -(height/2) respectively. Since the width and height of the panel is known these can be hard coded into the styles.

Happy Hacking