RSS | technovelty home | page of ian | ian@wienand.org
Anyone who works with building something with a few libraries will quickly become familiar with rpath's; that is the ability to store a path inside a binary for finding dependencies at runtime. Slightly less well known is that the dynamic linker provides some options for this path specification; one in particular is a path with the special variable $ORIGIN. ld.so man page has the following to say about the an $ORIGIN appearing in the rpath:
ld.so understands the string $ORIGIN (or equivalently ${ORIGIN})
in an rpath specification to mean the directory containing the
application executable. Thus, an application located in
somedir/app could be compiled with gcc -Wl,-rpath,'$ORI‐
GIN/../lib' so that it finds an associated shared library in
somedir/lib no matter where somedir is located in the directory
hierarchy.
As a way of a small example, consider the following:
$ cat Makefile
main: main.c lib/libfoo.so
gcc -g -Wall -o main -Wl,-rpath='$$ORIGIN/lib' -L ./lib -lfoo main.c
lib/libfoo.so: lib/foo.c
gcc -g -Wall -fPIC -shared -o lib/libfoo.so lib/foo.c
$ cat main.c
void function(void);
int main(void)
{
function();
return 0;
}
$ cat lib/foo.c
#include <stdio.h>
void function(void)
{
printf("called!\n");
}
$ make
gcc -g -Wall -fPIC -shared -o lib/libfoo.so lib/foo.c
gcc -g -Wall -o main -Wl,-rpath='$ORIGIN/lib' -L ./lib -lfoo main.c
$ ./main
called!
Now, wherever you should choose to locate main, as long as the library is in the right relative location it will be found correctly. If you are wondering how this works, examining the back-trace from the linker function that expands it is helpful:
$ gdb ./main
(gdb) break _dl_get_origin
Function "_dl_get_origin" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_dl_get_origin) pending.
(gdb) r
Starting program: /tmp/test-origin/main
Breakpoint 1, _dl_get_origin () at ../sysdeps/unix/sysv/linux/dl-origin.c:37
37 ../sysdeps/unix/sysv/linux/dl-origin.c: No such file or directory.
in ../sysdeps/unix/sysv/linux/dl-origin.c
(gdb) bt
#0 _dl_get_origin () at ../sysdeps/unix/sysv/linux/dl-origin.c:37
#1 0x00007ffff7de61f4 in expand_dynamic_string_token (l=0x7ffff7ffe128,
s=<value optimized out>) at dl-load.c:331
#2 0x00007ffff7de62ea in decompose_rpath (sps=0x7ffff7ffe440,
rpath=0xffffffc0 <Address 0xffffffc0 out of bounds>, l=0x0,
what=0x7ffff7df780a "RPATH") at dl-load.c:554
#3 0x00007ffff7de7051 in _dl_init_paths (llp=0x0) at dl-load.c:722
#4 0x00007ffff7de2124 in dl_main (phdr=0x7ffff7ffe6b8,
phnum=<value optimized out>, user_entry=0x7ffff7ffeb28) at rtld.c:1391
#5 0x00007ffff7df3647 in _dl_sysdep_start (
start_argptr=<value optimized out>, dl_main=0x7ffff7de14e0 <dl_main>)
at ../elf/dl-sysdep.c:243
#6 0x00007ffff7de0423 in _dl_start_final (arg=0x7fffffffe7c0) at rtld.c:338
#7 _dl_start (arg=0x7fffffffe7c0) at rtld.c:564
#8 0x00007ffff7ddfaf8 in _start () from /lib64/ld-linux-x86-64.so.2
Just from a first look we can divine that this has found the RPATH header in the dynamic section and has decided to expand the string $ORIGIN.
$ readelf --dynamic ./main Dynamic section at offset 0x7d8 contains 23 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libfoo.so] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/lib] 0x000000000000000c (INIT) 0x4004d8 0x000000000000000d (FINI) 0x4006f8
At this point it proceeds to do a readlink on /proc/self/exe to get the path to the currently running binary, effectively does a basename on it and replaces the value of $ORIGIN. Interestingly, if this should fail, it will fall back on the environment variable LD_ORIGIN_PATH for unknown reasons. This might be useful if you were in a bad situation where /proc was not mounted and you still had to run your binary, although you could probably achieve the same thing via the use of LD_LIBRARY_PATH just as well.
This feature should be used with some caution to avoid turning your application in a mess that can't be packaged in any standard manner. One common example of use is probably your java virtual machine to find its implementation libraries.
$ readelf --dynamic /usr/lib/jvm/java-6-sun/bin/java Dynamic section at offset 0x9a28 contains 25 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libjli.so] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [lib.so] 0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli] ...
There is a small but interesting security issue. If an attacker can hardlink to your binary that is using $ORIGIN then any path expansion is now relative to the attackers directory. Hence it is possible to make the linker read in arbitrary libraries and hence run arbitrary code. Clearly if your program is running setuid as someone else, such as root, you've just given up the keys to the house!
Luckily, the dynamic linker will not let you shoot yourself in the foot like this, and prevents expansion of the $ORIGIN field if the program is running setuid.
$ sudo chown root ./main $ sudo chmod +s ./main $ ./main ./main: error while loading shared libraries: libfoo.so: cannot open shared object file: No such file or directory
However, this is a good example of why you might want to keep users home and temp directories on separate file systems away from where binaries live.
There is also a similar variable $PLATFORM, which describes the current running system. This is gained via the auxiliary vector, which I have written about here and here. Setting LD_SHOW_AUXV=1 will allow you to examine this value.
$ LD_SHOW_AUXV=1 ls ... AT_PLATFORM: x86_64 ...
posted at: Wed, 21 Sep 2011 22:16 | in /linux | permalink | add comment (1 others)
I think the old-fashioned coredump is a little under-appreciated these days. I'm not sure when it changed, but I even had to add myself to /etc/security/limits.conf to raise my ulimit to even create one.
Anyway, debugging __thread variables from coredumps is a bit of a pain. For the uninitiated, the __thread identifier specifies a thread-local variable, i.e. every thread gets its own copy of the variable automatically.
The implementation of this is highly architecture specific. The reason is that TLS entries need to be accessed via a register kept as part of the thread state, and thus every architecture chooses their own register and builds their own ABI. On x86-32, which is very register-limited, you certainly don't want to dedicate a register to a pointer to TLS variables and take it out of operation. Luckily there is the hang-over from the 70's (60's? 50's?) — segmentation. Without going into real detail, segment registers can be used to offset into a region of memory based on a look-up of a region descriptor stored in a table.
Above, you see a simplified example of the %gs register loaded with the index value 2, and thus when you access %gs:20 what you are saying is "find entry 2 in the global descriptor table (GDT), follow it and offset 20 into that region.
The kernel gives each thread its own GDT (i.e. the GDT register is part of the thread-state). Thus __thread variables are stored based on segment offsets and — voila — thread-local storage. Now, there's a few tricks here. For various reasons, a process can not setup entries in the GDT; this is a privileged operation that must be done by the kernel. There is actually a special system call for threads to setup their TLS areas in the GDT — set_thread_area. When a new thread starts, the thread-library and dynamic linker conspire to allocate and load any static TLS data (i.e. if you have a global __thread variable initialised to some value, then every thread must see that value when it starts) and then calls this to make sure the variables are ready to go. After that, the gs register is filled with the index of that GDT entry, and all TLS access goes via it. That, in a nut-shell, is TLS for x86-32.
Now, to the problem. Take, for example, the following short program:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
int __thread foo;
void* thread(void *in) {
foo = (int)in;
printf("foo is %d\n", foo);
while (1) {
sleep(10);
}
}
int main(void) {
pthread_t threads[5];
int i;
for (i=0; i<5; i++) {
pthread_create(&threads[i], NULL,
thread, (void*)i);
}
sleep(5);
abort();
}
We start a few threads and then abort to make it dump core. But, if you try and examine foo:
$ gdb ./thread core GNU gdb (GDB) 7.2-debian Reading symbols from /home/ianw/tmp/thread/thread...done. [New Thread 4970] [New Thread 4975] [New Thread 4974] [New Thread 4973] [New Thread 4972] [New Thread 4971] Core was generated by `./thread'. Program terminated with signal 6, Aborted. #0 0xffffe424 in __kernel_vsyscall () (gdb) print foo Cannot find thread-local variables on this target
It seems that gdb doesn't know how to find the value of foo because its not a variable in the usual sense ("this target", in this case, means a coredump). It relies on accessing via the gs register, which relies on the current processes' GDT state, which has since been destroyed. If you care to consult the canonical source of TLS info, you can find out exactly why this is so hard to figure out generically. However, with some work, we can start to figure out the value by hand.
A coredump is really a ELF file full of just two things: a bunch of LOAD segments that are just dumps of the process memory regions, and a NOTE section that includes a bunch of notes that the kernel dumps out for us such as the current register state, the process id, the signal that killed us, etc. Here's an example of a core file under readelf
$ readelf --headers ./core ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 ... OS/ABI: UNIX - System V ... Type: CORE (Core file) ... There are no sections in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align NOTE 0x0003d4 0x00000000 0x00000000 0x006b4 0x00000 0 LOAD 0x001000 0x08048000 0x00000000 0x00000 0x01000 R E 0x1000 LOAD 0x001000 0x08049000 0x00000000 0x01000 0x01000 RW 0x1000 LOAD 0x002000 0x0804a000 0x00000000 0x21000 0x21000 RW 0x1000 LOAD 0x023000 0x46015000 0x00000000 0x00000 0x1b000 R E 0x1000 LOAD 0x023000 0x46030000 0x00000000 0x01000 0x01000 R 0x1000 LOAD 0x024000 0x46031000 0x00000000 0x01000 0x01000 RW 0x1000 ...
You can examine the notes; with readelf we see:
$ readelf --notes ./core Notes at offset 0x000003d4 with length 0x000006b4: Owner Data size Description CORE 0x00000090 NT_PRSTATUS (prstatus structure) CORE 0x0000007c NT_PRPSINFO (prpsinfo structure) CORE 0x000000a0 NT_AUXV (auxiliary vector) LINUX 0x00000030 Unknown note type: (0x00000200) CORE 0x00000090 NT_PRSTATUS (prstatus structure) LINUX 0x00000030 Unknown note type: (0x00000200) CORE 0x00000090 NT_PRSTATUS (prstatus structure) LINUX 0x00000030 Unknown note type: (0x00000200) CORE 0x00000090 NT_PRSTATUS (prstatus structure) LINUX 0x00000030 Unknown note type: (0x00000200) CORE 0x00000090 NT_PRSTATUS (prstatus structure) LINUX 0x00000030 Unknown note type: (0x00000200) CORE 0x00000090 NT_PRSTATUS (prstatus structure) LINUX 0x00000030 Unknown note type: (0x00000200)
This shows 5 notes of type NT_PRSTATUS; it should be little surprise that each of these notes describes the process status of one running thread. When gdb pops up [New Thread 4973] that's because it just hit another note that describes the new thread.
To actually make sense of the note, however, we need some other tools that look deeper. The elfutils based tools give us a better description of the various notes in the coredump; more akin to what GDB is interpreting them as. Below I've extracted one thread's info:
$ eu-readelf --notes core
...
CORE 144 PRSTATUS
info.si_signo: 6, info.si_code: 0, info.si_errno: 0, cursig: 6
sigpend: <>
sighold: <>
pid: 4970, ppid: 4960, pgrp: 4970, sid: 4960
utime: 0.000000, stime: 0.000000, cutime: 0.000000, cstime: 0.000000
orig_eax: 270, fpvalid: 0
ebx: 4970 ecx: 4970 edx: 6
esi: 0 edi: 1176018932 ebp: 0xbfa5b710
eax: 0 eip: 0xffffe424 eflags: 0x00000206
esp: 0xbfa5b6f8
ds: 0x007b es: 0x007b fs: 0x0000 gs: 0x0033 cs: 0x0073 ss: 0x007b
LINUX 48 386_TLS
index: 6, base: 0xb6043b70, limit: 0x000fffff, flags: 0x00000051
index: 7, base: 0x00000000, limit: 0x00000000, flags: 0x00000028
index: 8, base: 0x00000000, limit: 0x00000000, flags: 0x00000028
What's particularly interesting here is that the note type that was previously unknown (Unknown note type: (0x00000200)) has been resolved for us — it is in fact of type NT_386_TLS and is a dump of the GDT entries for the thread.
So, if we examine how our function is accessing our TLS variable by disassembling the thread function:
(gdb) disassemble thread Dump of assembler code for function thread: 0x08048514 <+0>: push %ebp 0x08048515 <+1>: mov %esp,%ebp 0x08048517 <+3>: sub $0x18,%esp 0x0804851a <+6>: mov 0x8(%ebp),%eax 0x0804851d <+9>: mov %eax,%gs:0xfffffffc 0x08048523 <+15>: mov %gs:0xfffffffc,%edx 0x0804852a <+22>: mov $0x8048670,%eax 0x0804852f <+27>: mov %edx,0x4(%esp) 0x08048533 <+31>: mov %eax,(%esp) 0x08048536 <+34>: call 0x80483f4 <printf@plt> 0x0804853b <+39>: movl $0xa,(%esp) 0x08048542 <+46>: call 0x8048404 <sleep@plt> 0x08048547 <+51>: jmp 0x804853b <thread+39>
Examining the disassembly we can see that foo is accessed via an offset of -4 from %gs (this is OK, as our limit value is maxed out. See the TLS ABI doc for more info). Now, we can examine gs and see which selector it is telling us to use:
(gdb) print $gs >> 3 $31 = 6
Above we shift out the last 3 bits, as these refer to the privilege level (bits 0 and 1) and if this is a GDT or LDT reference (bit 2). Thus, looking at the GDT descriptor for index 6:
LINUX 48 386_TLS
index: 6, base: 0xb6043b70, limit: 0x000fffff, flags: 0x00000051
we can finally do some maths from the base-address to figure out the value:
(gdb) print *(int*)(0xb6043b70 - 4) $34 = 3
Thus we have found our TLS value; in this case for thread 3 the value is indeed 3. I caution this is the simplest possible case; other "models" (see the TLS doc, again) may not be so simple to work out by hand, but this would certainly be how you would start.
posted at: Fri, 01 Jul 2011 22:41 | in /linux | permalink | add comment (1 others)
(this post was going to be about something else, but after getting this far, I think it stands on its own as an introduction to dynamic linking)
The shared library is an integral part of a modern system, but often the mechanisms behind the implementation are less well understood. There are, of course, many guides to this sort of thing. Hopefully this adds another perspective that resonates with someone.
Let's start at the beginning — - relocations are entries in binaries that are left to be filled in later -- at link time by the toolchain linker or at runtime by the dynamic linker. A relocation in a binary is a descriptor which essentially says "determine the value of X, and put that value into the binary at offset Y" — each relocation has a specific type, defined in the ABI documentation, which describes exactly how "determine the value of" is actually determined.
Here's the simplest example:
$ cat a.c
extern int foo;
int function(void) {
return foo;
}
$ gcc -c a.c
$ readelf --relocs ./a.o
Relocation section '.rel.text' at offset 0x2dc contains 1 entries:
Offset Info Type Sym.Value Sym. Name
00000004 00000801 R_386_32 00000000 foo
The value of foo is not known at the time you make a.o, so the compiler leaves behind a relocation (of type R_386_32) which is saying "in the final binary, patch the value at offset 0x4 in this object file with the address of symbol foo". If you take a look at the output, you can see at offset 0x4 there are 4-bytes of zeros just waiting for a real address:
$ objdump --disassemble ./a.o ./a.o: file format elf32-i386 Disassembly of section .text: 00000000 <function>: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: a1 00 00 00 00 mov 0x0,%eax 8: 5d pop %ebp 9: c3 ret
That's link time; if you build another object file with a value of foo and build that into a final executable, the relocation can go away. But there is a whole bunch of stuff for a fully linked executable or shared-library that just can't be resolved until runtime. The major reason, as I shall try to explain, is position-independent code (PIC). When you look at an executable file, you'll notice it has a fixed load address
$ readelf --headers /bin/ls [...] ELF Header: [...] Entry point address: 0x8049bb0 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align [...] LOAD 0x000000 0x08048000 0x08048000 0x16f88 0x16f88 R E 0x1000 LOAD 0x016f88 0x0805ff88 0x0805ff88 0x01543 0x01543 RW 0x1000
This is not position-independent. The code section (with permissions R E; i.e. read and execute) must be loaded at virtual address 0x08048000, and the data section (RW) must be loaded above that at exactly 0x0805ff88.
This is fine for an executable, because each time you start a new process (fork and exec) you have your own fresh address space. Thus it is a considerable time saving to pre-calculate addresses from and have them fixed in the final output (you can make position-independent executables, but that's another story).
This is not fine for a shared library (.so). The whole point of a shared library is that applications pick-and-choose random permutations of libraries to achieve what they want. If your shared library is built to only work when loaded at one particular address everything may be fine — until another library comes along that was built also using that address. The problem is actually somewhat tractable — you can just enumerate every single shared library on the system and assign them all unique address ranges, ensuring that whatever combinations of library are loaded they never overlap. This is essentially what prelinking does (although that is a hint, rather than a fixed, required address base). Apart from being a maintenance nightmare, with 32-bit systems you rapidly start to run out of address-space if you try to give every possible library a unique location. Thus when you examine a shared library, they do not specify a particular base address to be loaded at:
$ readelf --headers /lib/libc.so.6 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align [...] LOAD 0x000000 0x00000000 0x00000000 0x236ac 0x236ac R E 0x1000 LOAD 0x023edc 0x00024edc 0x00024edc 0x0015c 0x001a4 RW 0x1000
Shared libraries also have a second goal — code sharing. If a hundred processes use a shared library, it makes no sense to have 100 copies of the code in memory taking up space. If the code is completely read-only, and hence never, ever, modified, then every process can share the same code. However, we have the constraint that the shared library must still have a unqiue data instance in each process. While it would be possible to put the library data anywhere we want at runtime, this would require leaving behind relocations to patch the code and inform it where to actually find the data — destroying the always read-only property of the code and thus sharability. As you can see from the above headers, the solution is that the read-write data section is always put at a known offset from the code section of the library. This way, via the magic of virtual-memory, every process sees its own data section but can share the unmodified code. All that is needed to access data is some simple maths; address of thing I want = my current address + known fixed offset.
Well, simple maths is all relative! "My current address" may or may not be easy to find. Consider the following:
$ cat test.c
static int foo = 100;
int function(void) {
return foo;
}
$ gcc -fPIC -shared -o libtest.so test.c
So foo will be in data, at a fixed offset from the code in function, and all we need to do is find it! On amd64, this is quite easy, check the disassembly:
000000000000056c <function>: 56c: 55 push %rbp 56d: 48 89 e5 mov %rsp,%rbp 570: 8b 05 b2 02 20 00 mov 0x2002b2(%rip),%eax # 200828 <foo> 576: 5d pop %rbp
This says "put the value at offset 0x2002b2 from the current instruction pointer (%rip) into %eax. That's it — we know the data is at that fixed offset so we're done. i386, on the other hand, doesn't have the ability to offset from the current instruction pointer. Some trickery is required there:
0000040c <function>: 40c: 55 push %ebp 40d: 89 e5 mov %esp,%ebp 40f: e8 0e 00 00 00 call 422 <__i686.get_pc_thunk.cx> 414: 81 c1 5c 11 00 00 add $0x115c,%ecx 41a: 8b 81 18 00 00 00 mov 0x18(%ecx),%eax 420: 5d pop %ebp 421: c3 ret 00000422 <__i686.get_pc_thunk.cx>: 422: 8b 0c 24 mov (%esp),%ecx 425: c3 ret
The magic here is __i686.get_pc_thunk.cx. The architecture does not let us get the current instruction address, but we can get a known fixed address — the value __i686.get_pc_thunk.cx pushes into cx is the return value from the call, i.e in this case 0x414. Then we can do the maths for the add instruction; 0x115c + 0x414 = 0x1570, the final move goes 0x18 bytes past that to 0x1588 ... checking the disassembly
00001588 <global>:
1588: 64 00 00 add %al,%fs:(%eax)
i.e., the value 100 in decimal, stored in the data section.
We are getting closer, but there are still some issues to deal with. If a shared library can be loaded at any address, then how does an executable, or other shared library, know how to access data or call functions in it? We could, theoretically, load the library and patch up any data references or calls into that library; however as just described this would destroy code-sharability. As we know, all problems can be solved with a layer of indirection, in this case called global offset table or GOT.
Consider the following library:
$ cat test.c
extern int foo;
int function(void) {
return foo;
}
$ gcc -shared -fPIC -o libtest.so test.c
Note this looks exactly like before, but in this case the foo is extern; presumably provided by some other library. Let's take a closer look at how this works, on amd64:
$ objdump --disassemble libtest.so
[...]
00000000000005ac <function>:
5ac: 55 push %rbp
5ad: 48 89 e5 mov %rsp,%rbp
5b0: 48 8b 05 71 02 20 00 mov 0x200271(%rip),%rax # 200828 <_DYNAMIC+0x1a0>
5b7: 8b 00 mov (%rax),%eax
5b9: 5d pop %rbp
5ba: c3 retq
$ readelf --sections libtest.so
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[...]
[20] .got PROGBITS 0000000000200818 00000818
0000000000000020 0000000000000008 WA 0 0 8
$ readelf --relocs libtest.so
Relocation section '.rela.dyn' at offset 0x418 contains 5 entries:
Offset Info Type Sym. Value Sym. Name + Addend
[...]
000000200828 000400000006 R_X86_64_GLOB_DAT 0000000000000000 foo + 0
The disassembly shows that the value to be returned is loaded from an offset of 0x200271 from the current %rip; i.e. 0x0200828. Looking at the section headers, we see that this is part of the .got section. When we examine the relocations, we see a R_X86_64_GLOB_DAT relocation that says "find the value of symbol foo and put it into address 0x200828.
So, when this library is loaded, the dynamic loader will examine the relocation, go and find the value of foo and patch the .got entry as required. When it comes time for the code loads to load that value, it will point to the right place and everything just works; without having to modify any code values and thus destroy code sharability.
This handles data, but what about function calls? The indirection used here is called a procedure linkage table or PLT. Code does not call an external function directly, but only via a PLT stub. Let's examine this:
$ cat test.c
int foo(void);
int function(void) {
return foo();
}
$ gcc -shared -fPIC -o libtest.so test.c
$ objdump --disassemble libtest.so
[...]
00000000000005bc <function>:
5bc: 55 push %rbp
5bd: 48 89 e5 mov %rsp,%rbp
5c0: e8 0b ff ff ff callq 4d0 <foo@plt>
5c5: 5d pop %rbp
$ objdump --disassemble-all libtest.so
00000000000004d0 <foo@plt>:
4d0: ff 25 82 03 20 00 jmpq *0x200382(%rip) # 200858 <_GLOBAL_OFFSET_TABLE_+0x18>
4d6: 68 00 00 00 00 pushq $0x0
4db: e9 e0 ff ff ff jmpq 4c0 <_init+0x18>
$ readelf --relocs libtest.so
Relocation section '.rela.plt' at offset 0x478 contains 2 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000200858 000400000007 R_X86_64_JUMP_SLO 0000000000000000 foo + 0
So, we see that function makes a call to code at 0x4d0. Disassembling this, we see an interesting call, we jump to the value stored in 0x200382 past the current %rip (i.e. 0x200858), which we can then see the relocation for — the symbol foo.
It is interesting to keep following this through; let's look at the initial value that is jumped to:
$ objdump --disassemble-all libtest.so
Disassembly of section .got.plt:
0000000000200840 <.got.plt>:
200840: 98 cwtl
200841: 06 (bad)
200842: 20 00 and %al,(%rax)
...
200858: d6 (bad)
200859: 04 00 add $0x0,%al
20085b: 00 00 add %al,(%rax)
20085d: 00 00 add %al,(%rax)
20085f: 00 e6 add %ah,%dh
200861: 04 00 add $0x0,%al
200863: 00 00 add %al,(%rax)
200865: 00 00 add %al,(%rax)
...
Unscrambling 0x200858 we see its initial value is 0x4d6 — i.e. the next instruction! Which then pushes the value 0 and jumps to 0x4c0. Looking at that code we can see it pushes a value from the GOT, and then jumps to a second value in the GOT:
00000000000004c0 <foo@plt-0x10>: 4c0: ff 35 82 03 20 00 pushq 0x200382(%rip) # 200848 <_GLOBAL_OFFSET_TABLE_+0x8> 4c6: ff 25 84 03 20 00 jmpq *0x200384(%rip) # 200850 <_GLOBAL_OFFSET_TABLE_+0x10> 4cc: 0f 1f 40 00 nopl 0x0(%rax)
What's going on here? What's actually happening is lazy binding — by convention when the dynamic linker loads a library, it will put an identifier and resolution function into known places in the GOT. Therefore, what happens is roughly this: on the first call of a function, it falls through to call the default stub, which loads the identifier and calls into the dynamic linker, which at that point has enough information to figure out "hey, this libtest.so is trying to find the function foo". It will go ahead and find it, and then patch the address into the GOT such that the next time the original PLT entry is called, it will load the actual address of the function, rather than the lookup stub. Ingenious!
Out of this indirection falls another handy thing — the ability to modify the symbol binding order. LD_PRELOAD, for example, simply tells the dynamic loader it should insert a library as first to be looked-up for symbols; therefore when the above binding happens if the preloaded library declares a foo, it will be chosen over any other one provided.
In summary — code should be read-only always, and to make it so that you can still access data from other libraries and call external functions these accesses are indirected through a GOT and PLT which live at compile-time known offsets.
In a future post I'll discuss some of the security issues around this implementation, but that post won't make sense unless I can refer back to this one :)
posted at: Tue, 10 May 2011 16:15 | in /linux | permalink | add comment (3 others)
When building a user space binary, the -lc that gcc inserts into the final link seems pretty straight forward — link the C library. As with all things system-library related there is more to investigate.
If you look at /usr/lib/libc.so; the "library" that gets linked when you specify -lc, it is not a library as such, but a link script which specifies the libraries to link, which also includes the dynamic linker itself:
$ cat /usr/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux-x86-64.so.2 ) )
On very old glibc's the AS_NEEDED didn't appear; so every binary really did have a DT_NEEDED entry for the dynamic linker itself. This can be somewhat confusing if you're ever doing forensics on an old binary which seems to have these entries for not apparent reason. However, we can see that that /lib/libc.so itself does actually require symbols from the dynamic linker:
$ readelf --dynamic /lib/libc.so.6 | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]
Although you're unlikely to encounter it, a broken toolchain can cause havoc if it gets the link order wrong here, because the glibc dynamic linker defines minimal versions of malloc and friends -- you've got a chicken-and-egg problem using libc's malloc before you've loaded it! You can simulate this havoc with something like:
$ cat foo.c
#include <stdio.h>
#include <syslog.h>
int main(void)
{
syslog(LOG_DEBUG, "hello, world!");
return 0;
}
$ cat libbroken.so
GROUP ( /lib/ld-linux-x86-64.so.2 )
$ gcc -o -Wall -Wl,-rpath=. -L. -lbroken -g -o foo foo.c
$ ./foo
Inconsistency detected by ld.so: dl-minimal.c: 138: realloc: Assertion `ptr == alloc_last_block' failed!
Depending on various versions of things, you might see that assert or possibly just strange, corrupt output in your logs as syslog calls the wrong malloc. You could debug something like this by asking the dynamic linker to show you its bindings as it resolves them:
$ LD_DEBUG_OUTPUT=foo.txt LD_DEBUG=bindings ./foo
Inconsistency detected by ld.so: dl-minimal.c: 138: realloc: Assertion `ptr == alloc_last_block' failed!
$ cat foo.txt.11360 | grep "\`malloc'"
11360: binding file /lib/libc.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol `malloc' [GLIBC_2.2.5]
11360: binding file /lib64/ld-linux-x86-64.so.2 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol `malloc' [GLIBC_2.2.5]
11360: binding file /lib/libc.so.6 [0] to /lib64/ld-linux-x86-64.so.2 [0]: normal symbol `malloc' [GLIBC_2.2.5]
Above, because the dynamic loader comes first in the link order, libc.so.6's malloc has bound to the minimal implementation it provides, rather the full-featured one it provides internally.
As an aside, AFAICT, there is really only one reason why a normal library will link against the dynamic loader -- for the thread-local storage support function __tls_get_addr. You can try this yourself:
$ cat tls.c
char __thread *foo;
char* moo(void) {
return foo;
}
$ gcc -fPIC -o libtls.so -shared tls.c
$ readelf -d ./libtls.so | grep NEED
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x00000001 (NEEDED) Shared library: [ld-linux.so.2]
0x6ffffffe (VERNEED) 0x314
0x6fffffff (VERNEEDNUM) 2
Thread-local storage is worthy of a book of its own, but the gist is that this support function says "hey, give me an address of foo in libtls.so", the magic being that if the current thread has never accessed foo then it may not actually have any storage for foo yet, so the dynamic linker can allocate some memory for it lazily and then return the right thing. Otherwise, every thread that started would need to reserve room for foo "just in case", even if it never cares about moo.
But looking a little closer at the symbols of libc.so is also interesting. libc.so doesn't actually have many functions you can override. You can see what it is possible to override by checking the relocations against the procdure-lookup table (PLT).
Relocation section '.rela.plt' at offset 0x1e770 contains 8 entries: Offset Info Type Sym. Value Sym. Name + Addend 00000035b000 084600000007 R_X86_64_JUMP_SLO 00000000000a2100 sysconf + 0 00000035b008 02e000000007 R_X86_64_JUMP_SLO 0000000000075e50 calloc + 0 00000035b010 01dd00000007 R_X86_64_JUMP_SLO 0000000000077910 realloc + 0 00000035b018 029300000007 R_X86_64_JUMP_SLO 00000000000661c0 feof + 0 00000035b020 046f00000007 R_X86_64_JUMP_SLO 00000000000768c0 malloc + 0 00000035b028 000400000007 R_X86_64_JUMP_SLO 0000000000000000 __tls_get_addr + 0 00000035b030 01b400000007 R_X86_64_JUMP_SLO 0000000000076dd0 memalign + 0 00000035b038 086000000007 R_X86_64_JUMP_SLO 00000000000767e0 free + 0
i.e. instead of jumping directly to the malloc defined in the libc code section, any internal calls will jump to this stub which, the first time, asks the dynamic linker to go out and find the address of malloc (it then saves it, so the second time the stub just jumps to the saved location).
This is an interesting list, seemingly without much order. feof, for example, stands out as worth checking out a bit closer — why would that be there when fopen isn't, say? We can track down where it comes from with a bit of detective work; knowing that the value of the symbol feof will be placed into 0x35b018 we can disassemble libc.so to see that this address is used by the feof PLT stub at 0x1e870 (luckily, objdump has done the math to offest from the rip for us; i.e. 0x1e876 + 0x33c7a2 = 0x35b018)
000000000001e870 <feof@plt>: 1e870: ff 25 a2 c7 33 00 jmpq *0x33c7a2(%rip) # 35b018 <_IO_file_jumps+0xb18> 1e876: 68 03 00 00 00 pushq $0x3 1e87b: e9 b0 ff ff ff jmpq 1e830 <h_errno+0x1e7dc>
From there we can search for anyone jumping to that address, and find out the caller:
$ objdump --disassemble-all /lib/libc.so.6 | grep 1e870 000000000001e870 <feof@plt>: 1e870: ff 25 a2 c7 33 00 jmpq *0x33c7a2(%rip) # 35b018 <_IO_file_jumps+0xb18> f19f7: e8 74 ce f2 ff callq 1e870 <feof@plt> $ addr2line -e /lib/libc.so.6 f19f7 /home/aurel32/eglibc/eglibc-2.11.2/sunrpc/bindrsvprt.c:70
Which turns out to be part of a local patch which probably gets things a little wrong, as described below. The sysconf relocation is from a similar add-on patch (being used to find the page size, it seems).
libc, like all sensible libraries, uses the hidden attribute on symbols to restrict what is exported by the library. The benefit of this is that when the linker knows you are referencing a hidden symbol it knows that the value can never be overridden, and thus does not need to emit extra code to do indirection just in case you ever wish to redirect the symbols. In the above, it appears that feof has never been marked as hidden, probably because no internal glibc functions used it until that add-on patch, and since it is not considered an internal function the linker must allow for the possibility that it will be overridden at run time and provide a PLT slot for it. There are consequences; if this was on a fast-path then the extra jumps required to go via the PLT may matter for performance and it may also cause strange behaviour if somebody had preloaded something that took over feof.
Note, this is different from saying that your library can override symbols provided by libc.so; such as when you LD_PRELOAD a library to wrap an open call. What you can not override is the open call that say, the internal libc.so function getusershell does to read /etc/shells.
Having the malloc related calls as preemptable seems intentional and sane; although I can not find a comment to the effect of "we deliberately leave these like this so that users may use alternative malloc implementations", it makes sense so that libc.so is internally using the same malloc as everything else if you choose to use something such as tc-malloc.
tl;dr? Digging into your system libraries is always interesting. Be careful with your link order when creating toolchains, and be careful about symbol visibility when you're working with libraries.
posted at: Thu, 28 Apr 2011 16:13 | in /linux | permalink | add comment (1 others)
In a previous post I discussed converting medical images. I tried again today and hit another issue which could do with some google help.
If you see the following:
$ dcm2pnm --all-frames input.dcm E: can't change to unencapsulated representation for pixel data E: can't determine 'PhotometricInterpretation' of decompressed image E: can't decompress frame 0: Illegal call, perhaps wrong parameters E: can't convert input pixel data, probably unsupported compression F: Invalid DICOM image
and dcmdump reports somewhere:
# Dicom-Data-Set # Used TransferSyntax: JPEG Baseline
Try the dcmj2pnm program, rather than dcm2pnm. The man page does mention this, but that assumes that you know you have a JPEG encoded image :) It works the same, can extract multiple frames and can be converted to a movie as discussed in the previous post. Easy when you know how!
posted at: Mon, 14 Mar 2011 23:02 | in /linux/tips | permalink | add comment (0 others)
I'd wager probably more people today don't know what the TERM environment variable really does than do (yes, everyone who used to use ed over a 300-baud acoustic-coupler is laughing, but times have changed!).
I recently got hit by what was, at the time, a strange bug. Consider the following trivial Python program, that uses curses and issues the "hide the cursor" command.
$ cat curses.py import curses curses.initscr() curses.curs_set(0) curses.nocbreak() curses.echo() curses.endwin()
If you run it in your xterm or linux console, nothing should happen. But change your TERM to vt102 and it won't work:
$ TERM=vt102 python ./test.py
Traceback (most recent call last):test-curses.py
File "./test-curses.py", line 5, in <module>
curses.curs_set(0)
_curses.error: curs_set() returned ERR
(obvious when you explicitly reset the term, no so obvious when some script is doing it behind your back -- as I can attest!) So, what really happened there? The curs_set man page gives us the first clue:
curs_set returns the previous cursor state, or ERR if the requested visibility is not supported.
How do we know if visibility is supported? For that, curses consults the terminfo library. This is a giant database streching back to the dawn of time that says what certain terminals are capable of, and how to get them to do whatever it is you want them to do. So the TERM environment variable tells the terminfo libraries what database to use (see /usr/share/terminfo/*) when reporting features to people who ask, such as ncurses. man 5 terminfo tells us:
cursor_invisible | civis | vi | make cursor invisible
So curses is asking terminfo how to make the cursor invisible, and getting back "that's not possible here", and hence throwing our error.
But how can a person tell if their current terminal supports this feature? infocmp will echo out the features and what escape codes are used to access them. So we can check easily:
$ echo $TERM xterm $ infocmp | grep civis bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l, $ TERM=vt102 infocmp | grep civis $
So we can now clearly see that the vt102 terminal doesn't support civis, and hence has no way to make the cursor invisible; hence the error code.
If you're ever looking for a good read, check out the termcap/terminfo master file. The comments are like a little slice of the history of computing!
posted at: Tue, 11 May 2010 15:58 | in /linux | permalink | add comment (1 others)
Mark this one down as another in the long list of "duh" — once you realise what is going on!
Bug report comes in about a long running daemon that has stopped logging. lsof reports the log file is now named logfile~ and further more is deleted! This happens after a system upgrade scenario, so of course I go off digging through a multitude of scripts and what-not to find the culprit...
Have you got it yet?
Try this...
# lsof | grep syslogd | grep messages syslogd 1376 root 15w REG 3,1 99851 4605625 /var/log/messages
# cd /var/log/ # vi messages (and save the file)
root@jj:/var/log# lsof | grep syslogd | grep messages syslogd 1376 root 15w REG 3,1 99851 4605625 /var/log/messages~ (deleted)
vi is very careful and renames your existing file, so that if anything goes wrong when writing the new version you can get something back. It's a shame the daemon doesn't know about this! The kernel is happy to deal with the rename, but when the backup file is unlinked you're out of luck. Confusingly to a casual inspection your log file looks like it's there ... just that nothing is going into it. (oh, and if you tried that, you might like to restart syslogd now :)
Moral of the story -- overcome that finger-memory and never use vi on a live file; you're asking for trouble!
posted at: Fri, 08 Jan 2010 16:15 | in /linux/tips | permalink | add comment (6 others)
So, how to strip a shared library?
--strip-unneeded states that it removes all symbols that are not needed for relocation processing. This is a little cryptic, because one might reasonably assume that a shared library can be "relocated", in that it can be loaded anywhere. However, what this really refers to is object files that are usually built and bundled into a .a archive for static linking. For an object in an static library archive to still be useful, global symbols must be kept, although static symbols can be removed. Take the following small example:
$ cat libtest.c
static int static_var = 100;
int global_var = 100;
static int static_function(void) {
return static_var;
}
int global_function(int i) {
return static_function() + global_var + i;
}
Before stripping:
$ gcc -c -fPIC -o libtest.o libtest.c
$ readelf --symbols ./libtest.o
Symbol table '.symtab' contains 18 entries:
Num: Value Size Type Bind Vis Ndx Name
...
5: 00000000 4 OBJECT LOCAL DEFAULT 5 static_var
6: 00000000 22 FUNC LOCAL DEFAULT 3 static_function
13: 00000004 4 OBJECT GLOBAL DEFAULT 5 global_var
16: 00000016 36 FUNC GLOBAL DEFAULT 3 global_function
After stripping:
$ strip --strip-unneeded libtest.o
$ readelf --symbols ./libtest.o
Symbol table '.symtab' contains 15 entries:
Num: Value Size Type Bind Vis Ndx Name
...
10: 00000004 4 OBJECT GLOBAL DEFAULT 5 global_var
13: 00000016 36 FUNC GLOBAL DEFAULT 3 global_function
If you --strip-all from this object file, it will remove the entire .symtab section and will be useless for further linking, because you'll never be able to find global_function to call it!.
Shared libraries are different, however. Shared libraries keep global symbols in a separate ELF section called .dynsym. --strip-all will not touch the dynamic symbol entires, and thus it is therefore safe to remove all the "standard" symbols from the output file, without affecting the usability of the shared library. For example, readelf will still show the .dynsym symbols even after stripping:
$ gcc -shared -fPIC -o libtest.so libtest.c
$ strip --strip-all ./libtest.so
$ readelf --syms ./libtest.so
Symbol table '.dynsym' contains 11 entries:
Num: Value Size Type Bind Vis Ndx Name
...
6: 00000452 36 FUNC GLOBAL DEFAULT 12 global_function
10: 000015e0 4 OBJECT GLOBAL DEFAULT 21 global_var
However, --strip-unneeded is smart enough to realise that a shared-object library doesn't need the .symtab section as well and remove it.
So, conclusions? --strip-all is safe on shared libraries, because global symbols remain in a separate section, but not on objects for inclusion in static libraries (relocatable objects). --strip-unneeded is safe for both, and automatically understands shared objects do not need any .symtab entries to function and removes them; effectively doing the same work as --strip-all. So, --strip-unneeded is essentially the only tool you need for standard stripping needs!
See also
posted at: Wed, 23 Dec 2009 16:39 | in /linux | permalink | add comment (4 others)
Although Django is well packaged for Debian, I've recently come to the conculsion that the packages are really not what I want. The problem is that my server runs Debian stable, while my development laptop runs unstable, and Django revisions definitely fall into the "unstable" category. There really is no way to use a system Django 1.1 on one side, and a system Django 1.0 on the other.
After a bit of work, I think I've got something together that works, and I post it here in the hope it is useful for someone else. This info has been gleaned from similar references such as this and this.
This is aimed at running a server using Debian stable (5.0) for production and an unstable environment for development. You actually need both to get this running. This is based on a project called "project" that lives in /var/www
$ virtualenv --no-site-packages project New python executable in project/bin/python Installing setuptools............done.
/var/www$ cd project /var/www/project$ . bin/activate (project) /var/www/project$
(project) /var/www/project$ easy_install pip Searching for pip Reading http://pypi.python.org/simple/pip/ Reading http://pip.openplans.org Best match: pip 0.4 Downloading http://pypi.python.org/packages/source/p/pip/pip-0.4.tar.gz#md5=b45714d04f8fd38fe8e3d4c7600b91a2 Processing pip-0.4.tar.gz Running pip-0.4/setup.py -q bdist_egg --dist-dir /tmp/easy_install-Wu9O-U/pip-0.4/egg-dist-tmp-xjSdxq warning: no previously-included files matching '*.txt' found under directory 'docs/_build' no previously-included directories found matching 'docs/_build/_sources' zip_safe flag not set; analyzing archive contents... pip: module references __file__ Adding pip 0.4 to easy-install.pth file Installing pip script to /var/www/project/bin Installed /var/www/project/lib/python2.5/site-packages/pip-0.4-py2.5.egg Processing dependencies for pip Finished processing dependencies for pip
(project) /var/www/project$ easy_install setuptools==0.6c9 Searching for setuptools==0.6c9 Reading http://pypi.python.org/simple/setuptools/ Best match: setuptools 0.6c9 Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c9-py2.5.egg#md5=fe67c3e5a17b12c0e7c541b7ea43a8e6 Processing setuptools-0.6c9-py2.5.egg Moving setuptools-0.6c9-py2.5.egg to /var/www/project/lib/python2.5/site-packages Removing setuptools 0.6c8 from easy-install.pth file Adding setuptools 0.6c9 to easy-install.pth file Installing easy_install script to /var/www/project/bin Installing easy_install-2.5 script to /var/www/project/bin Installed /var/www/project/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg Processing dependencies for setuptools==0.6c9 Finished processing dependencies for setuptools==0.6c9
(project) /var/www/project$ cat requirements.txt -e svn+http://code.djangoproject.com/svn/django/tags/releases/1.0.3/#egg=Django (project) /var/www/project$ pip install -r requirements.txt Obtaining Django from svn+http://code.djangoproject.com/svn/django/tags/releases/1.0.3/#egg=Django (from -r requirements.txt (line 1)) Checking out http://code.djangoproject.com/svn/django/tags/releases/1.0.3/ to ./src/django (project) /var/www/project$ pip install -r requirements.txt Obtaining Django from svn+http://code.djangoproject.com/svn/django/tags/releases/1.0.3/#egg=Django (from -r requirements.txt (line 1)) Checking out http://code.djangoproject.com/svn/django/tags/releases/1.0.3/ to ./src/django ... so on ...
activate_this = "/var/www/project/bin/activate_this.py" execfile(activate_this, dict(__file__=activate_this)) from django.core.handlers.modpython import handler
(project) /var/www/project$ mkdir project (project) /var/www/project/project$ mkdir db django media www (project) /var/www/project/project$ cd django/ (project) /var/www/project/project/django$ django-admin startproject myproject
DocumentRoot /var/www/project
<Location "/">
SetHandler python-program
PythonHandler project-python
PythonPath "['/var/www/project/','/var/www/project/project/django/'] + sys.path"
SetEnv DJANGO_SETTINGS_MODULE myproject.settings
PythonDebug On
</Location>
Alias /media /var/www/project/project/media
<Location "/media">
SetHandler none
</Location>
<Directory "/var/www/project/project/media">
AllowOverride none
Order allow,deny
Allow from all
Options FollowSymLinks Indexes
</Directory>
With all this, you should be up and running in a basic but stable environment. It's easy enough to update packages for security fixes, etc via pip after activating your virtualenv.
posted at: Fri, 11 Sep 2009 22:49 | in /linux/debian | permalink | add comment (6 others)
Here's an interesting behaviour that, as far as I can tell, is completley undocumented, sightly consfusing but fairly logical. Your program should receive a SIGTTOU when it is running in the background and attempts to output to the terminal -- the idea being that you shouldn't scramble the output by mixing it in while the shell is trying to operate. Here's what the bash manual has to say
Background processes are those whose process group ID differs from the terminal's; such processes are immune to key- board-generated signals. Only foreground processes are allowed to read from or write to the terminal. Background processes which attempt to read from (write to) the terminal are sent a SIGTTIN (SIGTTOU) signal by the terminal driver, which, unless caught, suspends the process.
So, consider the following short program, which writes some output and catches any SIGTTOU's, with an optional flag to switch between canonical and non-canonical mode.
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <termios.h>
#include <unistd.h>
static void sig_ttou(int signo) {
printf("caught SIGTTOU\n");
signal(SIGTTOU, SIG_DFL);
kill(getpid(), SIGTTOU);
}
int main(int argc, char *argv[]) {
signal(SIGTTOU, sig_ttou);
if (argc != 1) {
struct termios tty;
printf("setting non-canoncial mode\n");
tcgetattr(fileno(stdout), &tty);
tty.c_lflag &= ~(ICANON);
tcsetattr(fileno(stdout), TCSANOW, &tty);
}
int i = 0;
while (1) {
printf(" *** %d ***\n", i++);
sleep(1);
}
}
This program ends up operating in an interesting manner.
$ ./sigttou & *** 0 *** [1] 26171 $ *** 1 *** *** 2 *** *** 3 ***
$ ./sigttou 1 & [1] 26494 ianw@jj:/tmp$ setting non-canoncial mode caught SIGTTOU [1]+ Stopped ./sigttou 1
$ stty tostop $ ./sigttou & [2] 26531 ianw@jj:/tmp$ *** 0 *** caught SIGTTOU [2]+ Stopped ./sigttou
You can see a practical example of this by comparing the difference
between cat file & and more file &.
The semantics make some sense -- anything switching off canonical mode
is like to be going to really scramble your terminal, so it's good to
stop it and let it's terminal handling functions run. I'm not sure
why canoncial background is considered useful mixed in with your
prompt, but someone, somewhere must have decided it was so.
Update: upon further investigation, it is the switching of terminal modes that invokes the SIGTTOU. To follow the logic through more, see the various users of tty_check_change in the tty driver.
posted at: Fri, 21 Aug 2009 11:02 | in /linux/tips | permalink | add comment (0 others)
If you go for an ultrasound or some other imaging procedure, they may give you a CD with the images that requires some overly complicated and under-featured Windows viewer. Chances are these images are in DICOM format, which is like the AVI of the medical world.
Your first clue will be that file might report the file as an unoptimised QuickTime movie, e.g.
$ file ./QMAG0001 ./QMAG0001: Apple QuickTime movie (unoptimized)
After figuring out the file type wasn't actually anything to do with QuickTime, I tried some of the many different tools and methods to convert this to something viewable. Unfortunatley, the DICOM viewer in GIMP and ImageMagick (probably the same thing?) didn't like the files at all, and neither did a range of other tools. I finally managed to do it with the dcm2pnm tool from the Debian dcmtk package -- just point it at the file and it spits out a PNM which is easily converted by all graphics tools.
You can also encapsulate a series of images in a DICOM file, like a little movie. dcm2pnm extracts these easily, but requires the --all-frames options. An ffmpeg recipe to turn these extracted files into a more easily viewable movie is:
$ ffmpeg -qscale 5 -r 20 -b 9600 -i foo.%d.ppm movie.mp4
I certainly can't guarantee this will actually work for you, as DICOM appears to be an extremely complicated format with many possible vendor extensions. But hopefully it's a starting point!
posted at: Sun, 08 Feb 2009 14:11 | in /linux/tips | permalink | add comment (2 others)
I've been meaning to try NoMachine NX for a while. Its promise of fast remote X11 sessions sounded exactly like what I wanted to log into my work desktop remotely (I really like having a remote desktop with saved state you can just pick up from when using remote access). That was pretty much all I knew about the software, so I was a completely blank slate.
The getting started guide is the perfect example of how not to write a getting started guide.
Firstly, Section 1 - "Getting started" - gives me a full history of the product, goes into significant depth about the challenges of forwarding X11 requests, talks about the caching and compression implementation, round-trip latency measurement, the details of two-way proxying system and discusses every other feature of the software.
My eyes glazed over after about the first paragraph. That's all great -- I just want to know what to do!
At this point, I assume that I'm required to run some sort of daemon at the remote end. I download and install the server package (it is explained that the server package requires the client and agent packages as well, fine).
I'm paging down, looking for something to get me started. I'm happy to see Section 7 - "Set up your NX Server environment" (remember, at this point I though I needed some daemon running in the background constantly). It even has some commands commands to type, so I tap away, running nxserver --useradd nxtest --system. My server binary doesn't even seem to recognise these options. I give up, assuming that the server isn't running and nothing will work. The getting started guide has abruptly ended and I have no idea what to do.
As it turns out, it's all completely trivial. Here's the missing "getting started guide".
Additional tips:
Other than the documentation, it really works as promised, making remote X11 usable. One really nice feature is that it is smart about the resolution of the remote desktop, filling up your local screen. Add to that you don't need anything setup but your normal ssh connection, and it's a great remote desktop solution.
posted at: Wed, 04 Feb 2009 15:10 | in /linux/tips | permalink | add comment (11 others)
I've written about AUXV previously, focusing on one of its most interesting applications -- its role in helping find linux-gate.so.1.
If you're starting your program, you can get the dynamic loader to echo out the AUXV fields with the environment variable LD_SHOW_AUXV, but if your process has started you'll need to pull the values out of /proc/pid/auxv directly.
This is pretty internal stuff for the dynamic loader and is probably only useful if you're writing a debugger or doing some other low-level tricks (such as debugging!). However, should you need to, here is some sample code which does just that. Hopefully it will save someone else some time!
posted at: Fri, 03 Oct 2008 16:08 | in /linux | permalink | add comment (0 others)
Here are some slides and examples I used for a kernel course I developed (some time ago now).
The course was aimed at C developers who wanted an introduction to both general UNIX-style user-space and Linux kernel development with a focus on embedded systems issues. The course is aimed at two 8-hour days, and is pretty packed in even then.
The first day is user-space development and kernel building, focusing on things like make, autotools, advanced gcc, getting cross-compilers working, configuring the kernel and building. The second day we get into kernel internals; building up a kernel module to produce some simple proc nodes, take data, crash and debug, etc, look at internals like concurrency and the driver model, and focus on USB quite a bit.
Here is a tarball of the entire thing, including the examples.
Hopefully these can help out anyone tackling the design of such a course.
posted at: Mon, 29 Sep 2008 21:27 | in /linux | permalink | add comment (3 others)
A recent post reminded me of a problem I once had; determine the glibc version and its support for various things.
There's actually a little known but useful confstr call defined for just this sort of thing. Here's a minimal example:
#include <stdio.h>
#include <unistd.h>
#include <alloca.h>
#include <string.h>
int main (void)
{
size_t n = confstr (_CS_GNU_LIBC_VERSION, NULL, 0);
if (n > 0)
{
char *buf = alloca (n);
confstr (_CS_GNU_LIBC_VERSION, buf, n);
printf("%s\n", buf);
}
return 0;
}
man confstr has all the details. If you don't need it in your program, you can also just run /lib/libc/so.6 and it will print out it's version info, e.g.
$ /lib/libc.so.6 GNU C Library stable release version 2.7, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.3.1 20080523 (prerelease). Compiled on a Linux >>2.6.24.4<< system on 2008-06-02. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>.
There's also another glibc trick that often comes in useful; the LD_DEBUG environment variable. Start with help and you can get more details from there.
$ LD_DEBUG=help ls Valid options for the LD_DEBUG environment variable are: libs display library search paths reloc display relocation processing files display progress for input file symbols display symbol table processing bindings display information about symbol binding versions display version dependencies all all previous options combined statistics display relocation statistics unused determined unused DSOs help display this help message and exit To direct the debugging output into a file instead of standard output a filename can be specified using the LD_DEBUG_OUTPUT environment variable.
posted at: Fri, 08 Aug 2008 13:51 | in /linux/tips | permalink | add comment (0 others)

This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License.