From: jeremie le-h. <le-...@ep...> - 2003-12-30 18:33:42
|
Hi all, I have just subscribed to this list because I found a strange bug while compiling an UML within an SKAS'd host. Here is the problem : (my host is a 2.4.23 kernel with the SKAS patch released on 2002/11/11) --- cut here --- droopy:tmp$ wget -q http://heanet.dl.sourceforge.net/sourceforge/user-mode-linux/uml-patch-2.4.23-1.bz2 droopy:tmp$ bzip2 -d uml-patch-2.4.23-1.bz2 droopy:tmp$ wget -q http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.23.tar.bz2 droopy:tmp$ tar xfj linux-2.4.23.tar.bz2 droopy:tmp$ cd linux-2.4.23 droopy:linux-2.4.23$ patch -p1 < ../uml-patch-2.4.23-1 [... no error ...] droopy:linux-2.4.23$ make menuconfig ARCH=um [... do not change anything, just quit ...] droopy:linux-2.4.23$ make dep ARCH=um [...] droopy:linux-2.4.23$ make linux ARCH=um [...] gcc -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -U__i386__ -Ui386 -DUM_FASTCALL -g -D__arch_um__ -DSUBARCH=\"i386\" -D_LARGEFILE64_SOURCE -I/space/kernel/tmp/linux-2.4.23/arch/um/include -I/space/kernel/tmp/linux-2.4.23/arch/um/kernel/tt/include -I/space/kernel/tmp/linux-2.4.23/arch/um/kernel/skas/include -D_GNU_SOURCE -c -o process.o process.c [...] In file included from process.c:27: /space/kernel/tmp/linux-2.4.23/arch/um/include/skas_ptrace.h:9: redefinition of `struct ptrace_faultinfo' /space/kernel/tmp/linux-2.4.23/arch/um/include/skas_ptrace.h:14: redefinition of `struct ptrace_ldt' make[3]: *** [process.o] Error 1 [...] --- cut here --- After preprocessing the process.c file, I found that `struct ptrace_faultinfo' and `struct ptrace_ldt' were first defined in file `/usr/include/asm/ptrace.h' and then in `arch/um/include/skas_ptrace.h'. Since `/usr/include/asm/' is a symlink in `/usr/src/linux/` which in turn points to my kernel source, I thought that it was maybe due to some tricky patch I have applied on my host's kernel. So I used a clean kernel source instead, and I made `/usr/include/asm/' point in it. And everything compiled perfectly. Therefore I went through my various patches to see which one modified `asm-i386/ptrace.h'. And what a surprise when I saw the following in `host-skas3.patch' : --- cut here --- diff -urN linux-2.4.23/include/asm-i386/ptrace.h linux-2.4.23-host_skas3_20031111/include/asm-i386/ptrace.h --- linux-2.4.23/include/asm-i386/ptrace.h 2001-09-14 23:04:08.000000000 +0200 +++ linux-2.4.23-host_skas3_20031111/include/asm-i386/ptrace.h 2003-12-04 21:08:46.000000000 +0100 @@ -51,6 +51,22 @@ #define PTRACE_SETOPTIONS 21 +struct ptrace_faultinfo { + int is_write; + unsigned long addr; +}; + +struct ptrace_ldt { + int func; + void *ptr; + unsigned long bytecount; +}; + +#define PTRACE_FAULTINFO 52 +#define PTRACE_SIGPENDING 53 +#define PTRACE_LDT 54 +#define PTRACE_SWITCH_MM 55 --- cut here --- This is *exactly* the same content as `arch/um/include/skas_ptrace.h'. From what I googled, it seems to be a known bug. But it think it would not be very difficult to make some #define protection around theses structures to prevent from changing the destination of `/usr/src/linux/' to a source without the SKAS patch applied. Regards, -- Jeremie LE HEN aka TtZ/TataZ jer...@ep... tt...@ep... Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! |
From: BlaisorBlade <bla...@ya...> - 2003-12-30 19:34:06
|
Alle 19:33, marted=EC 30 dicembre 2003, jeremie le-hen ha scritto: > Hi all, > I have just subscribed to this list because I found a strange bug while > compiling an UML within an SKAS'd host. Here is the problem : > > (my host is a 2.4.23 kernel with the SKAS patch released on 2002/11/11) > After preprocessing the process.c file, I found that > `struct ptrace_faultinfo' and `struct ptrace_ldt' were first defined > in file `/usr/include/asm/ptrace.h' and then in > `arch/um/include/skas_ptrace.h'. > Since `/usr/include/asm/' is a symlink > in `/usr/src/linux/` which in turn points to my kernel source, Making /usr/include/asm a symlink into kernel sources is a very bad thing; = if=20 your distro did this it's not your fault, but recent distros don't do this= =20 from ages (neither RedHat nor Mandrake, at least, for what I saw). > > This is *exactly* the same content as `arch/um/include/skas_ptrace.h'. > From what I googled, it seems to be a known bug. But it think it would > not be very difficult to make some #define protection around theses > structures to prevent from changing the destination of `/usr/src/linux/' > to a source without the SKAS patch applied. Yes, it wouldn't not hard. But you should not use the same source tree to apply both patches. I think= =20 this is explained very clearly and that the patches are not meant to be=20 compatible. Also, in that way you easily get into problems because=20 include/asm points to asm-i386 and is not updated to point to asm-um. Also, if you make /usr/include/asm (this holds also for /usr/include/linux)= a=20 symlink into kernel sources, that is not good. And I don't think that any update to the host patch will ever be made=20 available, since Jeff Dike is making ready the SKAS 4 patch. =2D-=20 cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN |
From: Jeff D. <jd...@ad...> - 2004-01-06 02:39:47
|
le-...@ep... said: > But it think it would not be very difficult to make some #define > protection around theses structures to prevent from changing the > destination of `/usr/src/linux/' to a source without the SKAS patch > applied. Maybe, but skas4 doesn't have this problem, and /usr/include/asm should point to the distro kernel headers, not whatever you have sitting in /usr/src/linux (and if the distro put a kernel tree there, you should be building stuff somewhere else). Of course, this is wrong if there are distros shipping a kernel tree with the skas patch in it (which maybe SuSE is). In this case, some sort of protection would be the right thing for skas3. Jeff |
From: attriel <at...@d2...> - 2004-01-06 04:27:32
|
> Maybe, but skas4 doesn't have this problem, and /usr/include/asm should Is SKAS4 nearing completion, btw? I know you said a while ago that you were working out a last little bug or something, just curious how it's going :) --attriel |
From: jeremie le-h. <le-...@ep...> - 2004-01-06 20:43:07
|
> le-...@ep... said: > > But it think it would not be very difficult to make some #define > > protection around theses structures to prevent from changing the > > destination of `/usr/src/linux/' to a source without the SKAS patch > > applied. > > Maybe, but skas4 doesn't have this problem, and /usr/include/asm should > point to the distro kernel headers, not whatever you have sitting in > /usr/src/linux (and if the distro put a kernel tree there, you should be > building stuff somewhere else). Ok, I understand better now. Altough it's a bit off-topic here, I would like to know where I can understand these subtleties. Instinctively, I would say that /usr/include/{asm,linux}/ need to point to the current kernel headers in order to use an API in sync with the running kernel : for example, imagine a kernel patch which adds the incoming and outgoing interfaces in the tuple used by connection tracking in the NetFilter framework ; /usr/src/linux/include/linux/netfilter_ipv4/ip_conntrack_tuple.h would be modified, and so applications including <linux/netfilter_ipv4/ip_conntrack_tuple.h> for any reason would not use the correct structure. I must be missing something, but I can't get what. Please tell me. Thanks in advance, -- Jeremie LE HEN aka TtZ/TataZ jer...@ep... tt...@ep... Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! |