[9fans] interface for per process gdt manipulation

[9fans] interface for per process gdt manipulation

[cinap_lenrek]

for vx32 and linuxemu an interface is needed in the plan9
kernel to modify per process gdt entries.

for linuxemu, i ended up with a kernel patch that adds
a gdt file to devproc for each process that contains
the binary representation of the process view of the
global descriptor table.

/n/sources/contrib/cinap_Lenrek/gdtpatch.tar

the interface:

/proc/n/gdt

reading the gdt file gets you the whole gdt table.

starting from a constant offset, here are 4 descriptors
that are writable trou the gdt file. writing any other
offsets causes an error.

the write also checks if the current segment registers
still contain valid selectors if the write would be applied.
so for example writing a descriptor for a read only segment
that is selected by the current ss register will fail.

i would like to have such an interface in the default
distribution some day so any objections are welcome.

implementation details for the patch:

the patch adds Segdesc ugdt[NUGDT] to the PMMU struct
in pc/dat.h for the per process gdt entries. these entries are
copied to m->gdt[] on procrestore in pc/main.c on context
switch.

noted was changed in pc/trap.c to only check for the
case that the selectors point to valid descriptors, not
force any specific selector.

pc/mmu.c contains the reading/writing and checking code.

--
cinap

Re: [9fans] interface for per process gdt manipulation

[Russ Cox]

i haven't looked at your code,
but a text interface is better than binary.
if you make the first field the table index number,
then you don't need to bother with seeking
to fixed offsets.  design a text format that is
convenient to use instead of forcing the binary
interface on everyone.

also i wonder if this should really be in
a separate ldt instead of polluting the gdt.

russ

Re: [9fans] interface for per process gdt manipulation

[cinap_lenrek]

> i haven't looked at your code,
> but a text interface is better than binary.
> if you make the first field the table index number,
> then you don't need to bother with seeking
> to fixed offsets.  design a text format that is
> convenient to use instead of forcing the binary
> interface on everyone.

thats a good idea. i'll look into it. should the descriptor be
presented in a decoded/splitted up form or just be the text
representation of the numerical values?

> also i wonder if this should really be in
> a separate ldt instead of polluting the gdt.

older versions of glibc use an ldt entry per thread but it got
deprecated for tls use by set_thread_area wich works only with with
gdt entries.

also ldt is not supported on amd64, but gdt segments are still
present and used for tls on linux.

> russ

--
cinap

Re: [9fans] interface for per process gdt manipulation

[Russ Cox]

On Mon, Jun 15, 2009 at 10:37 PM, <cinap_lenrek@gmx.de> wrote:
>> i haven't looked at your code,
>> but a text interface is better than binary.
>> if you make the first field the table index number,
>> then you don't need to bother with seeking
>> to fixed offsets.  design a text format that is
>> convenient to use instead of forcing the binary
>> interface on everyone.
>
> thats a good idea. i'll look into it. should the descriptor be
> presented in a decoded/splitted up form or just be the text
> representation of the numerical values?

i would hope the former; that's what i meant by
design a text format that is convenient to use.
ideally, cat /dev/gdt should give me something
that is easily human-readable, and if i feed the
lines back into /dev/gdt one at a time
    aux/lines </dev/gdt >/dev/gdt
it should be valid input.

>> also i wonder if this should really be in
>> a separate ldt instead of polluting the gdt.
>
> older versions of glibc use an ldt entry per thread but it got
> deprecated for tls use by set_thread_area wich works only with with
> gdt entries.
>
> also ldt is not supported on amd64, but gdt segments are still
> present and used for tls on linux.

good to know; thanks.

russ