sys_modify_ldt extension (default_ldt)
PATCH 1/1 sys_modify_ldt extension (default_ldt)
Hi,
I am trying to integrate binfmt_xout.c into kernel 2.4 as part of the linux-abi project (formerly known as iBCS). For old Xenix 286 binaries the lcall7 gate needs to part of the LDT.
In kernels 2.0 sys_modify_ldt(0,...) used to return the default_ldt (with lcall7 gate) if there were no segments set up. This behaviour changed in kernels 2.2 . As a result of a discussion with Linus, David Bruce wrote a patch for binfmt_xout.c tweaking with gdt and current->tss.ldt to get the address of default_ldt. This patch does not work any more with kernels 2.4 as tss vanished from task_struct.
I do see 4 ways to cope with this problem:
a) extend sys_modify_ldt with a function to retrieve the default_ldt. I did this for testing (see attached diff for arch/i386/kernel/ldt.c ).
b) do some work an Davids patch but this is kind of magic for me :-) (see attached default_ldt patch)
c) loose the option to compile binfmt_xout (and the rest of linux-abi) as module and simply use the symbol default_ldt. I dint't try that.
d) Forget about those old fashioned 286 binaries. This option will make some linux users feel sad, as they run these progs for their daily business.
Joerg
Signature · 7 lines
------------------------------------------------------------------------------ Joerg Ahrens _/ Koenigsberger Strasse 32 _/_/ 31226 Peine _/ _/ Tel.: 05171/57308 _/ _/_/_/_/ e-mail: [email protected] _/_/_/_/ _/ ------------------------------------------------------------------------------
arch/i386/kernel/ldt.c +20 -0
@@ -44,7 +44,24 @@ out:return err; } +static int read_default_ldt (void * ptr,unsigned long bytecount) +{ +int err; +unsigned long size; +void *address; + + err =0 ; + address = &default_ldt[0 ]; + size =sizeof (struct desc_struct ); +if (size > bytecount) + size = bytecount; + + err = size; +if (copy_to_user (ptr, address, size)) + err = -EFAULT ; +return err; +}static int write_ldt (void * ptr,unsigned long bytecount,int oldmode) {struct mm_struct * mm = current->mm;
@@ -156,6 +173,9 @@break ;case 1 : ret =write_ldt (ptr, bytecount,1 ); +break ; +case 2 : + ret =read_default_ldt (ptr, bytecount);break ;case 0x11 : ret =write_ldt (ptr, bytecount,0 );
struct desc_struct def_ldt;
unsigned long *lp, *lp2;
asm volatile ( "sgdt __gdt+2" );
lp = (unsigned long *)(__gdt[1] + current->tss.ldt );
lp2 = (unsigned long *)(((*lp >> 16) & 0x0000ffff)
| (*(lp+1) & 0xff000000)
| ((*(lp+1) << 16) & 0x00ff0000));def_ldt.a = *lp2;
def_ldt.b = *(lp2+1);
Hi Joerg,
Quoted 13 lines · In article <[email protected]> you wrote:
Hi,
I am trying to integrate
binfmt_xout.cinto kernel 2.4 as part of the linux-abi project (formerly known as iBCS). For old Xenix 286 binaries the lcall7 gate needs to part of the LDT.In kernels 2.0
sys_modify_ldt(0,...)used to return thedefault_ldt(with lcall7 gate) if there were no segments set up. This behaviour changed in kernels 2.2 . As a result of a discussion with Linus, David Bruce wrote a patch forbinfmt_xout.ctweaking with gdt andcurrent->tss.ldtto get the address ofdefault_ldt. This patch does not work any more with kernels 2.4 as tss vanished fromtask_struct.
Quoted 4 lines
I do see 4 ways to cope with this problem:
a) extend
sys_modify_ldtwith a function to retrieve thedefault_ldt. I did this for testing (see attached diff forarch/i386/kernel/ldt.c).
Looks sane to me.
Quoted 5 lines
b) do some work an Davids patch but this is kind of magic for me :-) (see attached
default_ldtpatch)c) loose the option to compile
binfmt_xout(and the rest of linux-abi) as module and simply use the symboldefault_ldt. I dint't try that.
As the linux-abi maintainer I do not think that's a good idea..
Quoted 2 lines
d) Forget about those old fashioned 286 binaries. This option will make some linux users feel sad, as they run these progs for their daily business.
If possible at all I'll vote for having 286 support.
I'll integrate the patch into the linux-abi tree if you also send me the other changes (mostly binfmt_xout.c changes I suppose).
Christoph
Signature · 1 line
Of course it doesn't work. We've performed a software upgrade.