On Sun, Mar 18, 2001 at 10:56:34PM -0500, Jeff Dike wrote:
> > I wouldn't think so. The standard segment descriptors used on x86
> > userland come from the GDT, and the LDT is unused by default. UML only
> > uses glibc, and in glibc only pthreads seems to use the LDT:
> OK, that makes it reasonably safe.
> Although, at some point I'm going to want to know exactly what the ldt is and
> why it's useful to change it, so I can be sure that a userland process can't
> change it in such a way as to confuse UML enough to break out.
From what I understand about the Intel architecture, all the LDT does is
provide mappings into virtual address space. You basically assign a
(base,length) pair to a segment register, and whenever you use that segment
register for accessing data, the base pointer is added to all your memory
references, and bounds checking against the segment length is done.
Applications don't really need segmented memory architectures. In fact, I
think segmentation is a design wart from hell. Things like WINE are probably
all it is needed for. And it happens to come in handy for doing LDT tricks for
implementing thread-specific data, so pthreads uses it.
I don't think you can use it to confuse UML, but I cannot prove this.
> > You told me a while ago that uml processes don't share their VM in the
> > host; does this hold for (VM-sharing) threads as well? IOW, if I have
> > two processes running under uml that share a VM, do the processes in
> > the host that these two processes map to share VMs?
> Every thread has a separate VM in the host, regardless of whether it shares
> a VM in UML.
I see this had changed now.
> > In the x86 port, LDTs are considered part of the VM, so VM-sharing
> > processes share LDTs as well. If VM-sharing processes in a uml map to
> > non-VM-sharing processes in the host, we might need some magic.
> This is indeed a problem for threaded apps that use modify_ldt, like probably
> that JVM.
> It shouldn't be that hard. Just save the ldt info in the arch-specific piece
> of the mm, record in the thread structure whether it's been done in that
> thread, and when a thread gets switched in, and it hasn't done the modify_ldt
> described in its mm, it does it then.
Heh. And almost before I have it done you switch :-)