2.6.15-mm1 caused kernel-offsets.c to stop compiling with a syntax error in a
header. The problem was with KBUILD_BASENAME, which didn't get a definition
with the by-hand compilation in the main UML Makefile.
This was OK before since the expansion was syntactically the same as the
KBUILD_BASENAME token. With -mm1, the expansion is now a quote-delimited
string, so there needs to be a definition of it.
Since kernel-offsets.c is basically the same as other arches' asm-offsets.c,
and those seem to build OK, this patch turns kernel-offsets.c into
asm-offsets.c. kernel-offsets.c is in arch/um/sys-$(SUBARCH), i.e. sys-i386
and sys-x86_64, while kbuild expects it to be in arch/um/kernel.
kernel-offsets.c is moved to
arch/um/include/sysdep-$(SUBARCH)/kernel-offsets.h, which is included by
arch/um/kernel/asm-offsets.c. With that, include/asm-um/asm-offsets.h is
generated automatically. kernel-offsets.h continues to exist because it needs
to be accessible to userspace UML code, and include/asm-um isn't. So, a
symlink is made from arch/um/include/kernel-offsets.h to
include/asm-um/asm-offsets.h.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
With Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
UML skas0 stub has been miscompiling for many people (incidentally not
the authors), depending on the used GCC versions.
I think (and testing on some GCC versions shows) this patch avoids the
fundamental issue which is behind this, namely gcc using the stack when
we have just replaced it, behind gcc's back. The remapping and storage
of the return value is hidden in a blob of asm, hopefully giving gcc no
room for creativity.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch makes stub_segv use the stub_syscall macros. This was needed
anyway, but the bug that prompted this was the discovery that gcc was storing
stuff in RCX, which is trashed across a system call. This is exactly the sort
of problem that the new macros fix.
There is a stub_syscall0 for getpid. stub_segv was changed to be a libc file,
and that caused some include changes.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jeff Dike noted that the assembly code for syscall stubs is misassembled with
GCC 3.2.3: the values copied in registers weren't preserved between one asm()
and the following one.
So I fixed the thing by rewriting the __asm__ constraints more like unistd.h
ones.
Note: in syscall6 case I had to add one more instruction (i.e. moving arg6 in
eax and shuffling things around) - it's needed for the function to be valid in
general (we can't load the value from the stack, relative to ebp, because we
change it), but could be avoided since we actually use a constant as param 6.
The only fix would be to turn stub_syscall6 to a macro and use a "i"
constraint for arg6 (i.e., specify it's a constant value).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Without this patch, uml compile fails with:
LD .tmp_vmlinux1
arch/um/kernel/built-in.o: In function `config_gdb_cb':
arch/um/kernel/tt/gdb.c:129: undefined reference to `TASK_EXTERN_PID'
Tested on i386, but fix needed on x86_64 too AFAICS.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Missing half of the [PATCH] uml: Fix sysrq-r support for skas mode
We need to remove these (UPT_[DEFG]S) from the read side as well as the
write one - otherwise it simply won't build.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The old code had the IP and SP coming from the registers in the thread
struct, which are completely wrong since those are the userspace
registers. This fixes that by pulling the correct values from the
jmp_buf in which the kernel state of each thread is stored.
Signed-off-by: Allan Graves <allan.graves@oracle.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I hadn't been running a SKAS3 host when testing the "uml: fix hang in TT mode
on fault" patch (commit 546fe1cbf9), and I
didn't think enough to the missing trap_no in SKAS3 mode.
In fact, the resulting kernel doesn't work at all in SKAS3 mode.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
UML makefiles sanitized:
- number of generated headers reduced to 2 (from user-offsets.c and
kernel-offsets.c resp.). The rest is made constant and simply
includes those two.
- mk_... helpers are gone now that we don't need to generate these
headers
- arch/um/include2 removed since everything under arch/um/include/sysdep
is constant now and symlink can point straight to source tree.
- dependencies seriously simplified.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This merges two sets of files which had no business being split apart in the
first place.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix a macro typo which could break if the macro is passed arguments with
side-effects.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch implements the clone-stub mechanism, which allows skas0 to run
with proc_mm==0, even if the clib in UML uses modify_ldt.
Note: There is a bug in skas3.v7 host patch, that avoids UML-skas from
running properly on a SMP-box. In full skas3, I never really saw problems,
but in skas0 they showed up.
More commentary by jdike - What this patch does is makes sure that the host
parent of each new host process matches the UML parent of the corresponding
UML process. This ensures that any changed LDTs are inherited. This is
done by having clone actually called by the UML process from its stub,
rather than by the kernel. We have special syscall stubs that are loaded
onto the stub code page because that code must be completely
self-contained. These stubs are given C interfaces, and used like normal C
functions, but there are subtleties. Principally, we have to be careful
about stack variables in stub_clone_handler after the clone. The code is
written so that there aren't any - everything boils down to a fixed
address. If there were any locals, references to them after the clone
would be wrong because the stack just changed.
Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
UML has had two modes of operation - an insecure, slow mode (tt mode) in
which the kernel is mapped into every process address space which requires
no host kernel modifications, and a secure, faster mode (skas mode) in
which the UML kernel is in a separate host address space, which requires a
patch to the host kernel.
This patch implements something very close to skas mode for hosts which
don't support skas - I'm calling this skas0. It provides the security of
the skas host patch, and some of the performance gains.
The two main things that are provided by the skas patch, /proc/mm and
PTRACE_FAULTINFO, are implemented in a way that require no host patch.
For the remote address space changing stuff (mmap, munmap, and mprotect),
we set aside two pages in the process above its stack, one of which
contains a little bit of code which can call mmap et al.
To update the address space, the system call information (system call
number and arguments) are written to the stub page above the code. The
%esp is set to the beginning of the data, the %eip is set the the start of
the stub, and it repeatedly pops the information into its registers and
makes the system call until it sees a system call number of zero. This is
to amortize the cost of the context switch across multiple address space
updates.
When the updates are done, it SIGSTOPs itself, and the kernel process
continues what it was doing.
For a PTRACE_FAULTINFO replacement, we set up a SIGSEGV handler in the
child, and let it handle segfaults rather than nullifying them. The
handler is in the same page as the mmap stub. The second page is used as
the stack. The handler reads cr2 and err from the sigcontext, sticks them
at the base of the stack in a faultinfo struct, and SIGSTOPs itself. The
kernel then reads the faultinfo and handles the fault.
A complication on x86_64 is that this involves resetting the registers to
the segfault values when the process is inside the kill system call. This
breaks on x86_64 because %rcx will contain %rip because you tell SYSRET
where to return to by putting the value in %rcx. So, this corrupts $rcx on
return from the segfault. To work around this, I added an
arch_finish_segv, which on x86 does nothing, but which on x86_64 ptraces
the child back through the sigreturn. This causes %rcx to be restored by
sigreturn and avoids the corruption. Ultimately, I think I will replace
this with the trick of having it send itself a blocked signal which will be
unblocked by the sigreturn. This will allow it to be stopped just after
the sigreturn, and PTRACE_SYSCALLed without all the back-and-forth of
PTRACE_SYSCALLing it through sigreturn.
This runs on a stock host, so theoretically (and hopefully), tt mode isn't
needed any more. We need to make sure that this is better in every way
than tt mode, though. I'm concerned about the speed of address space
updates and page fault handling, since they involve extra round-trips to
the child. We can amortize the round-trip cost for large address space
updates by writing all of the operations to the data page and having the
child execute them all at the same time. This will help fork and exec, but
not page faults, since they involve only one page.
I can't think of any way to help page faults, except to add something like
PTRACE_FAULTINFO to the host. There is PTRACE_SIGINFO, but UML doesn't use
siginfo for SIGSEGV (or anything else) because there isn't enough
information in the siginfo struct to handle page faults (the faulting
operation type is missing). Adding that would make PTRACE_SIGINFO a usable
equivalent to PTRACE_FAULTINFO.
As for the code itself:
- The system call stub is in arch/um/kernel/sys-$(SUBARCH)/stub.S. It is
put in its own section of the binary along with stub_segv_handler in
arch/um/kernel/skas/process.c. This is manipulated with run_syscall_stub
in arch/um/kernel/skas/mem_user.c. syscall_stub will execute any system
call at all, but it's only used for mmap, munmap, and mprotect.
- The x86_64 stub calls sigreturn by hand rather than allowing the normal
sigreturn to happen, because the normal sigreturn is a SA_RESTORER in
UML's address space provided by libc. Needless to say, this is not
available in the child's address space. Also, it does a couple of odd
pops before that which restore the stack to the state it was in at the
time the signal handler was called.
- There is a new field in the arch mmu_context, which is now a union.
This is the pid to be manipulated rather than the /proc/mm file
descriptor. Code which deals with this now checks proc_mm to see whether
it should use the usual skas code or the new code.
- userspace_tramp is now used to create a new host process for every UML
process, rather than one per UML processor. It checks proc_mm and
ptrace_faultinfo to decide whether to map in the pages above its stack.
- start_userspace now makes CLONE_VM conditional on proc_mm since we need
separate address spaces now.
- switch_mm_skas now just sets userspace_pid[0] to the new pid rather
than PTRACE_SWITCH_MM. There is an addition to userspace which updates
its idea of the pid being manipulated each time around the loop. This is
important on exec, when the pid will change underneath userspace().
- The stub page has a pte, but it can't be mapped in using tlb_flush
because it is part of tlb_flush. This is why it's required for it to be
mapped in by userspace_tramp.
Other random things:
- The stub section in uml.lds.S is page aligned. This page is written
out to the backing vm file in setup_physmem because it is mapped from
there into user processes.
- There's some confusion with TASK_SIZE now that there are a couple of
extra pages that the process can't use. TASK_SIZE is considered by the
elf code to be the usable process memory, which is reasonable, so it is
decreased by two pages. This confuses the definition of
USER_PGDS_IN_LAST_PML4, making it too small because of the rounding down
of the uneven division. So we round it to the nearest PGDIR_SIZE rather
than the lower one.
- I added a missing PT_SYSCALL_ARG6_OFFSET macro.
- um_mmu.h was made into a userspace-usable file.
- proc_mm and ptrace_faultinfo are globals which say whether the host
supports these features.
- There is a bad interaction between the mm.nr_ptes check at the end of
exit_mmap, stack randomization, and skas0. exit_mmap will stop freeing
pages at the PGDIR_SIZE boundary after the last vma. If the stack isn't
on the last page table page, the last pte page won't be freed, as it
should be since the stub ptes are there, and exit_mmap will BUG because
there is an unfreed page. To get around this, TASK_SIZE is set to the
next lowest PGDIR_SIZE boundary and mm->nr_ptes is decremented after the
calls to init_stub_pte. This ensures that we know the process stack (and
all other process mappings) will be below the top page table page, and
thus we know that mm->nr_ptes will be one too many, and can be
decremented.
Things that need fixing:
- We may need better assurrences that the stub code is PIC.
- The stub pte is set up in init_new_context_skas.
- alloc_pgdir is probably the right place.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Some changes that I sent in didn't make 2.6.12-rc4 for some reason. This
adds them back. We have
an x86_64 definition of TOP_ADDR
a reimplementation of the x86_64 csum_partial_copy_from_user
some syntax fixes in arch/um/kernel/ptrace.c
removal of a CFLAGS definition in the x86_64 Makefile
some include changes in the x86_64 ptrace.c and user-offsets.h
a syntax fix in elf-x86_64.h
Also moved an include in the i386 and x86_64 Makefiles to make the symlinks
work, and some small fixes from Al Viro.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
s390 passes parameters in registers. So the only safe way to find out the
address of signal context, error-address and error-type (trap_no), which are
passed to signal handlers as parameters, is to declare these parameters.
So I inserted an subarch-specific macro which holds the declaration of
parameters for signal handlers.
Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch removes the arch-specific fault/trap-infos from thread and
skas-regs.
It adds a new struct faultinfo, that is arch-specific defined in
sysdep/faultinfo.h.
The structure is inserted in thread.arch and thread.regs.skas and
thread.regs.tt
Now, segv and other trap-handlers can copy the contents from regs.X.faultinfo
to thread.arch.faultinfo with one simple assignment.
Also, the number of macros necessary is reduced to
FAULT_ADDRESS(struct faultinfo)
extracts the faulting address from faultinfo
FAULT_WRITE(struct faultinfo)
extracts the "is_write" flag
SEGV_IS_FIXABLE(struct faultinfo)
is true for the fixable segvs, i.e. (TRAP == 14)
on i386
UPT_FAULTINFO(regs)
result is (struct faultinfo *) to the faultinfo
in regs->skas.faultinfo
GET_FAULTINFO_FROM_SC(struct faultinfo, struct sigcontext *)
copies the relevant parts of the sigcontext to
struct faultinfo.
On SIGSEGV, call user_signal() instead of handle_segv(), if the architecture
provides the information needed in PTRACE_FAULTINFO, or if PTRACE_FAULTINFO is
missing, because segv-stub will provide the info.
The benefit of the change is, that in case of a non-fixable SIGSEGV, we can
give user processes a SIGSEGV, instead of possibly looping on pagefault
handling.
Since handle_segv() sikked arch_fixup() implicitly by passing ip==0 to segv(),
I changed segv() to call arch_fixup() only, if !is_user.
Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reuse asm-x86-64/unistd.h to build our syscall table, like x86-64 already
does.
Like for i386, we must add some #defines for all the (right!) changes UML does
to x86-64 syscall table.
Note: I noted a bogus:
[ __NR_sched_yield ] = (syscall_handler_t *) yield,
while doing this patch (which could only be a workaround for some strange bug,
but I would ignore this possibility). I'm changing this without notice.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Split the i386 entry.S files into entry.S and syscall_table.S which is
included in the previous one (so actually there is no difference between them)
and use the syscall_table.S in the UML build, instead of tracking by hand the
syscall table changes (which is inherently error-prone).
We must only insert the right #defines to inject the changes we need from the
i386 syscall table (for instance some different function names); also, we
don't implement some i386 syscalls, as ioperm(), nor some TLS-related ones
(yet to provide).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Jeff Dike