* [PATCH] Allow UML kernel to run in a separate host address space
@ 2002-12-17 23:24 Jeff Dike
0 siblings, 0 replies; 11+ messages in thread
From: Jeff Dike @ 2002-12-17 23:24 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Please pull
http://jdike.stearns.org:5000/skas-2.5
This allows the UML kernel to run in a different address space from its
processes. The benefits include better security and much improved performance.
This is a large patch, but
it's all under arch/um and include/asm-um
a lot of it is code movement
This is described fairly completely in
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=fa.ia69pmv.e4qnq1%40ifi.uio.no
Jeff
arch/um/Kconfig | 8
arch/um/Makefile | 77 ++--
arch/um/Makefile-i386 | 4
arch/um/drivers/chan_kern.c | 66 +++
arch/um/drivers/chan_user.c | 33 -
arch/um/drivers/fd.c | 6
arch/um/drivers/line.c | 108 +++++-
arch/um/drivers/mconsole_kern.c | 62 +++
arch/um/drivers/null.c | 5
arch/um/drivers/port_kern.c | 13
arch/um/drivers/port_user.c | 9
arch/um/drivers/pty.c | 19 -
arch/um/drivers/ssl.c | 36 +-
arch/um/drivers/stdio_console.c | 32 +
arch/um/drivers/tty.c | 8
arch/um/drivers/ubd_kern.c | 39 ++
arch/um/drivers/xterm.c | 4
arch/um/include/chan_kern.h | 3
arch/um/include/chan_user.h | 4
arch/um/include/choose-mode.h | 35 ++
arch/um/include/debug.h | 26 -
arch/um/include/frame.h | 18 -
arch/um/include/kern.h | 2
arch/um/include/kern_util.h | 28 -
arch/um/include/line.h | 11
arch/um/include/mconsole_kern.h | 16
arch/um/include/mem.h | 1
arch/um/include/mem_user.h | 12
arch/um/include/mode.h | 30 +
arch/um/include/mode_kern.h | 30 +
arch/um/include/os.h | 8
arch/um/include/sigcontext.h | 2
arch/um/include/syscall_user.h | 13
arch/um/include/sysdep-i386/checksum.h | 217 ++++++++++++
arch/um/include/sysdep-i386/frame_kern.h | 9
arch/um/include/sysdep-i386/ptrace.h | 109 ++++--
arch/um/include/sysdep-i386/sigcontext.h | 33 +
arch/um/include/time_user.h | 2
arch/um/include/um_mmu.h | 40 ++
arch/um/include/um_uaccess.h | 73 ++++
arch/um/include/user_util.h | 26 -
arch/um/kernel/Makefile | 58 +--
arch/um/kernel/checksum.c | 42 ++
arch/um/kernel/exec_kern.c | 64 ---
arch/um/kernel/exec_user.c | 49 --
arch/um/kernel/frame.c | 204 ++++++-----
arch/um/kernel/frame_kern.c | 85 +++-
arch/um/kernel/helper.c | 5
arch/um/kernel/init_task.c | 2
arch/um/kernel/ksyms.c | 17
arch/um/kernel/mem.c | 71 +---
arch/um/kernel/mem_user.c | 44 --
arch/um/kernel/process.c | 136 +++++--
arch/um/kernel/process_kern.c | 477 +--------------------------
arch/um/kernel/ptrace.c | 61 +++
arch/um/kernel/reboot.c | 25 -
arch/um/kernel/sigio_user.c | 13
arch/um/kernel/signal_kern.c | 19 -
arch/um/kernel/signal_user.c | 9
arch/um/kernel/skas/Makefile | 24 +
arch/um/kernel/skas/exec_kern.c | 41 ++
arch/um/kernel/skas/exec_user.c | 61 +++
arch/um/kernel/skas/include/mmu.h | 27 +
arch/um/kernel/skas/include/mode.h | 34 +
arch/um/kernel/skas/include/mode_kern.h | 52 +++
arch/um/kernel/skas/include/proc_mm.h | 55 +++
arch/um/kernel/skas/include/ptrace-skas.h | 57 +++
arch/um/kernel/skas/include/skas.h | 49 ++
arch/um/kernel/skas/include/skas_ptrace.h | 36 ++
arch/um/kernel/skas/include/uaccess.h | 236 +++++++++++++
arch/um/kernel/skas/mem.c | 35 ++
arch/um/kernel/skas/mem_user.c | 95 +++++
arch/um/kernel/skas/mmu.c | 46 ++
arch/um/kernel/skas/process.c | 386 ++++++++++++++++++++++
arch/um/kernel/skas/process_kern.c | 195 +++++++++++
arch/um/kernel/skas/sys-i386/Makefile | 14
arch/um/kernel/skas/sys-i386/sigcontext.c | 114 ++++++
arch/um/kernel/skas/syscall_kern.c | 42 ++
arch/um/kernel/skas/syscall_user.c | 47 ++
arch/um/kernel/skas/time.c | 30 +
arch/um/kernel/skas/tlb.c | 156 +++++++++
arch/um/kernel/skas/trap_user.c | 66 +++
arch/um/kernel/skas/util/Makefile | 10
arch/um/kernel/skas/util/mk_ptregs.c | 50 ++
arch/um/kernel/smp.c | 12
arch/um/kernel/sys_call_table.c | 15
arch/um/kernel/syscall_kern.c | 126 -------
arch/um/kernel/syscall_user.c | 79 ----
arch/um/kernel/sysrq.c | 8
arch/um/kernel/time.c | 22 -
arch/um/kernel/time_kern.c | 3
arch/um/kernel/tlb.c | 225 +------------
arch/um/kernel/trap_kern.c | 361 +++------------------
arch/um/kernel/trap_user.c | 492 +---------------------------
arch/um/kernel/tt/Makefile | 20 +
arch/um/kernel/tt/exec_kern.c | 84 ++++
arch/um/kernel/tt/exec_user.c | 49 ++
arch/um/kernel/tt/gdb.c | 278 ++++++++++++++++
arch/um/kernel/tt/gdb_kern.c | 40 ++
arch/um/kernel/tt/include/debug.h | 29 +
arch/um/kernel/tt/include/mmu.h | 23 +
arch/um/kernel/tt/include/mode.h | 35 ++
arch/um/kernel/tt/include/mode_kern.h | 53 +++
arch/um/kernel/tt/include/ptrace-tt.h | 26 +
arch/um/kernel/tt/include/tt.h | 45 ++
arch/um/kernel/tt/include/uaccess.h | 119 ++++++
arch/um/kernel/tt/ksyms.c | 28 +
arch/um/kernel/tt/mem.c | 77 ++++
arch/um/kernel/tt/process_kern.c | 513 ++++++++++++++++++++++++++++++
arch/um/kernel/tt/ptproxy/Makefile | 13
arch/um/kernel/tt/ptproxy/proxy.c | 370 +++++++++++++++++++++
arch/um/kernel/tt/ptproxy/ptproxy.h | 61 +++
arch/um/kernel/tt/ptproxy/ptrace.c | 239 +++++++++++++
arch/um/kernel/tt/ptproxy/sysdep.c | 71 ++++
arch/um/kernel/tt/ptproxy/sysdep.h | 25 +
arch/um/kernel/tt/ptproxy/wait.c | 86 +++++
arch/um/kernel/tt/ptproxy/wait.h | 15
arch/um/kernel/tt/sys-i386/Makefile | 14
arch/um/kernel/tt/sys-i386/sigcontext.c | 59 +++
arch/um/kernel/tt/syscall_kern.c | 140 ++++++++
arch/um/kernel/tt/syscall_user.c | 90 +++++
arch/um/kernel/tt/time.c | 28 +
arch/um/kernel/tt/tlb.c | 226 +++++++++++++
arch/um/kernel/tt/tracer.c | 466 +++++++++++++++++++++++++++
arch/um/kernel/tt/trap_user.c | 58 +++
arch/um/kernel/tt/uaccess_user.c | 126 +++++++
arch/um/kernel/uaccess_user.c | 126 -------
arch/um/kernel/um_arch.c | 119 +++---
arch/um/kernel/umid.c | 6
arch/um/main.c | 64 ---
arch/um/os-Linux/Makefile | 6
arch/um/os-Linux/drivers/Makefile | 3
arch/um/os-Linux/process.c | 42 ++
arch/um/os-Linux/tty.c | 2
arch/um/ptproxy/Makefile | 10
arch/um/ptproxy/proxy.c | 370 ---------------------
arch/um/ptproxy/ptproxy.h | 61 ---
arch/um/ptproxy/ptrace.c | 238 -------------
arch/um/ptproxy/sysdep.c | 71 ----
arch/um/ptproxy/sysdep.h | 25 -
arch/um/ptproxy/wait.c | 86 -----
arch/um/ptproxy/wait.h | 15
arch/um/sys-i386/Makefile | 36 --
arch/um/sys-i386/checksum.S | 460 ++++++++++++++++++++++++++
arch/um/sys-i386/ksyms.c | 3
arch/um/sys-i386/ldt.c | 69 +++-
arch/um/sys-i386/ptrace.c | 57 ++-
arch/um/sys-i386/ptrace_user.c | 2
arch/um/sys-i386/sigcontext.c | 39 --
arch/um/sys-i386/util/mk_thread_kern.c | 16
arch/um/sys-i386/util/mk_thread_user.c | 32 +
arch/um/uml.lds.S | 1
arch/um/util/Makefile | 11
arch/um/util/mk_constants_kern.c | 24 +
arch/um/util/mk_constants_user.c | 28 +
include/asm-um/a.out.h | 8
include/asm-um/checksum.h | 2
include/asm-um/mmu.h | 18 -
include/asm-um/mmu_context.h | 51 ++
include/asm-um/page.h | 2
include/asm-um/processor-generic.h | 39 +-
include/asm-um/ptrace-generic.h | 2
include/asm-um/uaccess.h | 100 -----
163 files changed, 8121 insertions(+), 3588 deletions(-)
ChangeSet@1.984, 2002-12-17 02:55:00-05:00, jdike@uml.karaya.com
Merge jdike.stearns.org:linux/skas-2.5
into uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
ChangeSet@1.981.1.1, 2002-12-17 02:34:29-05:00, jdike@jdike.wstearns.org
Merge
ChangeSet@1.983, 2002-12-17 02:21:56-05:00, jdike@uml.karaya.com
Removed includes of Rules.mk.
ChangeSet@1.982, 2002-12-17 01:06:44-05:00, jdike@uml.karaya.com
Merged the 2.5.52 Makefile changes.
ChangeSet@1.797.195.3, 2002-12-06 21:30:55-05:00, jdike@uml.karaya.com
Merge jdike.stearns.org:linux/skas-2.5
into uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
ChangeSet@1.797.195.2, 2002-12-06 21:25:54-05:00, jdike@uml.karaya.com
Added a couple of includes as part of the 2.5.50 update.
ChangeSet@1.797.196.1, 2002-12-06 19:04:22-05:00, jdike@jdike.wstearns.org
Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
into jdike.wstearns.org:/home/jdike/linux/skas-2.5
ChangeSet@1.797.195.1, 2002-12-06 18:14:59-05:00, jdike@uml.karaya.com
Merge uml.karaya.com:/home/jdike/linux/2.5/linus-2.5
into uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
ChangeSet@1.797.134.7, 2002-11-25 22:07:47-05:00, jdike@uml.karaya.com
Fixed a stupid compile bug.
ChangeSet@1.797.134.6, 2002-11-25 21:03:24-05:00, jdike@uml.karaya.com
Small fixes to sync up the 2.4 and 2.5 pools.
Also fixed a stupid signal handling bug.
ChangeSet@1.797.134.5, 2002-11-25 13:41:02-05:00, jdike@uml.karaya.com
A whole lot of small changes to sync up the 2.4 and 2.5 pools
somewhat. Mostly whitespace changes, plus some code movement.
Also added checksum.S to the repository, which I had somehow
missed before.
ChangeSet@1.797.134.3, 2002-11-23 21:37:53-05:00, jdike@uml.karaya.com
Merge
ChangeSet@1.797.134.2, 2002-11-23 19:25:48-05:00, jdike@uml.karaya.com
Updated to 2.5.49, which involved fixing the calls to do_fork.
ChangeSet@1.797.72.14, 2002-11-23 16:49:59-05:00, jdike@uml.karaya.com
Finished the skas merge by eliminating a syntax error, fixing the
new compilation warnings, and fixing a call to handle_page_fault.
ChangeSet@1.797.72.13, 2002-11-22 21:47:15-05:00, jdike@uml.karaya.com
Merged the rest of the skas changes.
ChangeSet@1.797.72.12, 2002-11-22 21:22:57-05:00, jdike@uml.karaya.com
Fixed various build problems with the tlb.c merge.
ChangeSet@1.797.72.11, 2002-11-22 20:39:33-05:00, jdike@uml.karaya.com
Merged the tlb.c changes from the skas patch.
ChangeSet@1.797.72.10, 2002-11-22 14:27:24-05:00, jdike@uml.karaya.com
Minor build fixes to the last batch of skas merges.
ChangeSet@1.797.72.9, 2002-11-22 12:53:13-05:00, jdike@uml.karaya.com
Merged a number of small skas changes.
ChangeSet@1.797.72.8, 2002-11-21 23:22:43-05:00, jdike@uml.karaya.com
Some small build fixes to the IP checksum merge.
ChangeSet@1.797.71.4, 2002-11-21 23:21:41-05:00, jdike@uml.karaya.com
Removed the checksum.S symlink from arch/um/sys-i386/Makefile.
ChangeSet@1.797.72.7, 2002-11-21 22:30:24-05:00, jdike@uml.karaya.com
Merged the IP checksum changes from the skas code.
ChangeSet@1.797.72.6, 2002-11-21 22:26:06-05:00, jdike@uml.karaya.com
Some minor build and compilation fixes to the copy_sc merge.
ChangeSet@1.797.72.5, 2002-11-21 22:00:31-05:00, jdike@uml.karaya.com
Applied the sigcontext changes in the skas code.
ChangeSet@1.797.72.4, 2002-11-21 21:38:56-05:00, jdike@uml.karaya.com
A number of small fixes for the uaccess merge.
ChangeSet@1.797.72.3, 2002-11-21 18:54:16-05:00, jdike@uml.karaya.com
Added the uaccess changes from the skas merge.
ChangeSet@1.797.72.2, 2002-11-21 17:16:25-05:00, jdike@uml.karaya.com
Resolved the conflict between the skas and get_config changes in
line.h.
ChangeSet@1.797.80.17, 2002-11-21 14:59:43-05:00, jdike@uml.karaya.com
Added skas/mem_user.c and tt/gdb.c
ChangeSet@1.797.80.16, 2002-11-21 14:48:11-05:00, jdike@uml.karaya.com
Added a bunch of C files under arch/um/kernel/skas and
arch/um/kernel/tt.
ChangeSet@1.797.80.15, 2002-11-21 14:31:45-05:00, jdike@uml.karaya.com
Added a batch of files under arch/um/kernel/skas.
ChangeSet@1.797.80.14, 2002-11-21 14:09:26-05:00, jdike@uml.karaya.com
Added arch/um/include/mode_kern.h
ChangeSet@1.797.71.3, 2002-11-21 14:05:13-05:00, jdike@uml.karaya.com
Changed the config to pull in zlib.
ChangeSet@1.797.80.13, 2002-11-21 13:23:40-05:00, jdike@uml.karaya.com
Added the mode mmu.h and mode.h headers.
ChangeSet@1.797.80.12, 2002-11-21 13:15:09-05:00, jdike@uml.karaya.com
Added mode.h, mk_constants_kern.c, mk_constants_user.c, and um_mmu.h
ChangeSet@1.797.80.11, 2002-11-21 12:58:41-05:00, jdike@uml.karaya.com
Added ptrace-skas.h and ptrace-tt.h.
ChangeSet@1.797.80.10, 2002-11-21 12:52:36-05:00, jdike@uml.karaya.com
Added arch/um/kernel/skas/util/*, which I missed somehow.
ChangeSet@1.797.80.9, 2002-11-20 23:04:22-05:00, jdike@uml.karaya.com
Merged most of the rest of the skas changes.
ChangeSet@1.797.80.8, 2002-11-19 14:54:08-05:00, jdike@uml.karaya.com
Declared mode_tt in user_util.h.
ChangeSet@1.797.80.7, 2002-11-19 14:53:18-05:00, jdike@uml.karaya.com
Merged the skas exec reorg.
ChangeSet@1.797.80.6, 2002-11-19 13:47:41-05:00, jdike@uml.karaya.com
Fixed a couple of buglets in the signal frame merge.
ChangeSet@1.797.80.5, 2002-11-19 00:54:26-05:00, jdike@uml.karaya.com
Merged the signal frame cleanups and fixes from 2.4.
ChangeSet@1.797.80.4, 2002-11-19 00:47:18-05:00, jdike@uml.karaya.com
Fixes to the last merge.
ChangeSet@1.797.80.3, 2002-11-19 00:13:26-05:00, jdike@uml.karaya.com
Merged the os_kill_process and the driver from_user changes from
the 2.4 pool.
Also merged some other cleanups.
ChangeSet@1.797.80.2, 2002-11-18 23:28:32-05:00, jdike@uml.karaya.com
Fixed the Makefiles so that the ptproxy move from arch/um/ptproxy
to arch/um/kernel/tt/ptproxy works.
ChangeSet@1.797.80.1, 2002-11-18 22:47:18-05:00, jdike@uml.karaya.com
Moved the ptproxy code from arch/um/ptproxy to
arch/um/kernel/tt/ptproxy.
ChangeSet@1.797.71.2, 2002-11-18 20:03:13-05:00, jdike@uml.karaya.com
A few more fixes to get 2.4.48 to boot.
ChangeSet@1.797.72.1, 2002-11-18 15:57:40-05:00, jdike@uml.karaya.com
Merged the get_config changes from 2.4.
ChangeSet@1.797.71.1, 2002-11-18 15:57:00-05:00, jdike@uml.karaya.com
Updated to 2.5.48
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] Allow UML kernel to run in a separate host address space
@ 2002-12-28 15:47 Jeff Dike
2002-12-28 19:34 ` Linus Torvalds
0 siblings, 1 reply; 11+ messages in thread
From: Jeff Dike @ 2002-12-28 15:47 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Please pull either
http://uml.bkbits.net/skas-2.5
or http://jdike.stearns.org:5000/skas-2.5
This allows the UML kernel to run in a different address space from its
processes. The benefits include better security and much improved performance.
This is a large patch, but
it's all under arch/um and include/asm-um
a lot of it is code movement
This is described fairly completely in
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=fa.ia69pmv.e4qnq1%40ifi.uio.no
Jeff
arch/um/Kconfig | 8
arch/um/Makefile | 77 ++--
arch/um/Makefile-i386 | 4
arch/um/drivers/chan_kern.c | 66 +++
arch/um/drivers/chan_user.c | 33 -
arch/um/drivers/fd.c | 6
arch/um/drivers/line.c | 108 +++++-
arch/um/drivers/mconsole_kern.c | 62 +++
arch/um/drivers/null.c | 5
arch/um/drivers/port_kern.c | 13
arch/um/drivers/port_user.c | 9
arch/um/drivers/pty.c | 19 -
arch/um/drivers/ssl.c | 36 +-
arch/um/drivers/stdio_console.c | 32 +
arch/um/drivers/tty.c | 8
arch/um/drivers/ubd_kern.c | 39 ++
arch/um/drivers/xterm.c | 4
arch/um/include/chan_kern.h | 3
arch/um/include/chan_user.h | 4
arch/um/include/choose-mode.h | 35 ++
arch/um/include/debug.h | 26 -
arch/um/include/frame.h | 18 -
arch/um/include/kern.h | 2
arch/um/include/kern_util.h | 28 -
arch/um/include/line.h | 11
arch/um/include/mconsole_kern.h | 16
arch/um/include/mem.h | 1
arch/um/include/mem_user.h | 12
arch/um/include/mode.h | 30 +
arch/um/include/mode_kern.h | 30 +
arch/um/include/os.h | 8
arch/um/include/sigcontext.h | 2
arch/um/include/syscall_user.h | 13
arch/um/include/sysdep-i386/checksum.h | 217 ++++++++++++
arch/um/include/sysdep-i386/frame_kern.h | 9
arch/um/include/sysdep-i386/ptrace.h | 109 ++++--
arch/um/include/sysdep-i386/sigcontext.h | 33 +
arch/um/include/time_user.h | 2
arch/um/include/um_mmu.h | 40 ++
arch/um/include/um_uaccess.h | 73 ++++
arch/um/include/user_util.h | 26 -
arch/um/kernel/Makefile | 58 +--
arch/um/kernel/checksum.c | 42 ++
arch/um/kernel/exec_kern.c | 64 ---
arch/um/kernel/exec_user.c | 49 --
arch/um/kernel/frame.c | 204 ++++++-----
arch/um/kernel/frame_kern.c | 85 +++-
arch/um/kernel/helper.c | 5
arch/um/kernel/init_task.c | 2
arch/um/kernel/ksyms.c | 17
arch/um/kernel/mem.c | 71 +---
arch/um/kernel/mem_user.c | 44 --
arch/um/kernel/process.c | 136 +++++--
arch/um/kernel/process_kern.c | 477 +--------------------------
arch/um/kernel/ptrace.c | 61 +++
arch/um/kernel/reboot.c | 25 -
arch/um/kernel/sigio_user.c | 13
arch/um/kernel/signal_kern.c | 19 -
arch/um/kernel/signal_user.c | 9
arch/um/kernel/skas/Makefile | 24 +
arch/um/kernel/skas/exec_kern.c | 41 ++
arch/um/kernel/skas/exec_user.c | 61 +++
arch/um/kernel/skas/include/mmu.h | 27 +
arch/um/kernel/skas/include/mode.h | 34 +
arch/um/kernel/skas/include/mode_kern.h | 52 +++
arch/um/kernel/skas/include/proc_mm.h | 55 +++
arch/um/kernel/skas/include/ptrace-skas.h | 57 +++
arch/um/kernel/skas/include/skas.h | 49 ++
arch/um/kernel/skas/include/skas_ptrace.h | 36 ++
arch/um/kernel/skas/include/uaccess.h | 236 +++++++++++++
arch/um/kernel/skas/mem.c | 35 ++
arch/um/kernel/skas/mem_user.c | 95 +++++
arch/um/kernel/skas/mmu.c | 46 ++
arch/um/kernel/skas/process.c | 386 ++++++++++++++++++++++
arch/um/kernel/skas/process_kern.c | 195 +++++++++++
arch/um/kernel/skas/sys-i386/Makefile | 14
arch/um/kernel/skas/sys-i386/sigcontext.c | 114 ++++++
arch/um/kernel/skas/syscall_kern.c | 42 ++
arch/um/kernel/skas/syscall_user.c | 47 ++
arch/um/kernel/skas/time.c | 30 +
arch/um/kernel/skas/tlb.c | 156 +++++++++
arch/um/kernel/skas/trap_user.c | 66 +++
arch/um/kernel/skas/util/Makefile | 10
arch/um/kernel/skas/util/mk_ptregs.c | 50 ++
arch/um/kernel/smp.c | 12
arch/um/kernel/sys_call_table.c | 15
arch/um/kernel/syscall_kern.c | 126 -------
arch/um/kernel/syscall_user.c | 79 ----
arch/um/kernel/sysrq.c | 8
arch/um/kernel/time.c | 22 -
arch/um/kernel/time_kern.c | 3
arch/um/kernel/tlb.c | 225 +------------
arch/um/kernel/trap_kern.c | 361 +++------------------
arch/um/kernel/trap_user.c | 492 +---------------------------
arch/um/kernel/tt/Makefile | 20 +
arch/um/kernel/tt/exec_kern.c | 84 ++++
arch/um/kernel/tt/exec_user.c | 49 ++
arch/um/kernel/tt/gdb.c | 278 ++++++++++++++++
arch/um/kernel/tt/gdb_kern.c | 40 ++
arch/um/kernel/tt/include/debug.h | 29 +
arch/um/kernel/tt/include/mmu.h | 23 +
arch/um/kernel/tt/include/mode.h | 35 ++
arch/um/kernel/tt/include/mode_kern.h | 53 +++
arch/um/kernel/tt/include/ptrace-tt.h | 26 +
arch/um/kernel/tt/include/tt.h | 45 ++
arch/um/kernel/tt/include/uaccess.h | 119 ++++++
arch/um/kernel/tt/ksyms.c | 28 +
arch/um/kernel/tt/mem.c | 77 ++++
arch/um/kernel/tt/process_kern.c | 513 ++++++++++++++++++++++++++++++
arch/um/kernel/tt/ptproxy/Makefile | 13
arch/um/kernel/tt/ptproxy/proxy.c | 370 +++++++++++++++++++++
arch/um/kernel/tt/ptproxy/ptproxy.h | 61 +++
arch/um/kernel/tt/ptproxy/ptrace.c | 239 +++++++++++++
arch/um/kernel/tt/ptproxy/sysdep.c | 71 ++++
arch/um/kernel/tt/ptproxy/sysdep.h | 25 +
arch/um/kernel/tt/ptproxy/wait.c | 86 +++++
arch/um/kernel/tt/ptproxy/wait.h | 15
arch/um/kernel/tt/sys-i386/Makefile | 14
arch/um/kernel/tt/sys-i386/sigcontext.c | 59 +++
arch/um/kernel/tt/syscall_kern.c | 140 ++++++++
arch/um/kernel/tt/syscall_user.c | 90 +++++
arch/um/kernel/tt/time.c | 28 +
arch/um/kernel/tt/tlb.c | 226 +++++++++++++
arch/um/kernel/tt/tracer.c | 466 +++++++++++++++++++++++++++
arch/um/kernel/tt/trap_user.c | 58 +++
arch/um/kernel/tt/uaccess_user.c | 126 +++++++
arch/um/kernel/uaccess_user.c | 126 -------
arch/um/kernel/um_arch.c | 119 +++---
arch/um/kernel/umid.c | 6
arch/um/main.c | 64 ---
arch/um/os-Linux/Makefile | 6
arch/um/os-Linux/drivers/Makefile | 3
arch/um/os-Linux/process.c | 42 ++
arch/um/os-Linux/tty.c | 2
arch/um/ptproxy/Makefile | 10
arch/um/ptproxy/proxy.c | 370 ---------------------
arch/um/ptproxy/ptproxy.h | 61 ---
arch/um/ptproxy/ptrace.c | 238 -------------
arch/um/ptproxy/sysdep.c | 71 ----
arch/um/ptproxy/sysdep.h | 25 -
arch/um/ptproxy/wait.c | 86 -----
arch/um/ptproxy/wait.h | 15
arch/um/sys-i386/Makefile | 36 --
arch/um/sys-i386/checksum.S | 460 ++++++++++++++++++++++++++
arch/um/sys-i386/ksyms.c | 3
arch/um/sys-i386/ldt.c | 69 +++-
arch/um/sys-i386/ptrace.c | 57 ++-
arch/um/sys-i386/ptrace_user.c | 2
arch/um/sys-i386/sigcontext.c | 39 --
arch/um/sys-i386/util/mk_thread_kern.c | 16
arch/um/sys-i386/util/mk_thread_user.c | 32 +
arch/um/uml.lds.S | 1
arch/um/util/Makefile | 11
arch/um/util/mk_constants_kern.c | 24 +
arch/um/util/mk_constants_user.c | 28 +
include/asm-um/a.out.h | 8
include/asm-um/checksum.h | 2
include/asm-um/mmu.h | 18 -
include/asm-um/mmu_context.h | 51 ++
include/asm-um/page.h | 2
include/asm-um/processor-generic.h | 39 +-
include/asm-um/ptrace-generic.h | 2
include/asm-um/uaccess.h | 100 -----
163 files changed, 8121 insertions(+), 3588 deletions(-)
ChangeSet@1.865.24.3, 2002-12-17 02:55:00-05:00, jdike@uml.karaya.com
Merge jdike.stearns.org:linux/skas-2.5
into uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
ChangeSet@1.865.25.1, 2002-12-17 02:34:29-05:00, jdike@jdike.wstearns.org
Merge
ChangeSet@1.865.24.2, 2002-12-17 02:21:56-05:00, jdike@uml.karaya.com
Removed includes of Rules.mk.
ChangeSet@1.865.24.1, 2002-12-17 01:06:44-05:00, jdike@uml.karaya.com
Merged the 2.5.52 Makefile changes.
ChangeSet@1.797.203.3, 2002-12-06 21:30:55-05:00, jdike@uml.karaya.com
Merge jdike.stearns.org:linux/skas-2.5
into uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
ChangeSet@1.797.203.2, 2002-12-06 21:25:54-05:00, jdike@uml.karaya.com
Added a couple of includes as part of the 2.5.50 update.
ChangeSet@1.797.204.1, 2002-12-06 19:04:22-05:00, jdike@jdike.wstearns.org
Merge jdike.wstearns.org:/home/jdike/linux/linus-2.5
into jdike.wstearns.org:/home/jdike/linux/skas-2.5
ChangeSet@1.797.203.1, 2002-12-06 18:14:59-05:00, jdike@uml.karaya.com
Merge uml.karaya.com:/home/jdike/linux/2.5/linus-2.5
into uml.karaya.com:/home/jdike/linux/2.5/skas-2.5
ChangeSet@1.797.139.7, 2002-11-25 22:07:47-05:00, jdike@uml.karaya.com
Fixed a stupid compile bug.
ChangeSet@1.797.139.6, 2002-11-25 21:03:24-05:00, jdike@uml.karaya.com
Small fixes to sync up the 2.4 and 2.5 pools.
Also fixed a stupid signal handling bug.
ChangeSet@1.797.139.5, 2002-11-25 13:41:02-05:00, jdike@uml.karaya.com
A whole lot of small changes to sync up the 2.4 and 2.5 pools
somewhat. Mostly whitespace changes, plus some code movement.
Also added checksum.S to the repository, which I had somehow
missed before.
ChangeSet@1.797.139.3, 2002-11-23 21:37:53-05:00, jdike@uml.karaya.com
Merge
ChangeSet@1.797.139.2, 2002-11-23 19:25:48-05:00, jdike@uml.karaya.com
Updated to 2.5.49, which involved fixing the calls to do_fork.
ChangeSet@1.797.72.14, 2002-11-23 16:49:59-05:00, jdike@uml.karaya.com
Finished the skas merge by eliminating a syntax error, fixing the
new compilation warnings, and fixing a call to handle_page_fault.
ChangeSet@1.797.72.13, 2002-11-22 21:47:15-05:00, jdike@uml.karaya.com
Merged the rest of the skas changes.
ChangeSet@1.797.72.12, 2002-11-22 21:22:57-05:00, jdike@uml.karaya.com
Fixed various build problems with the tlb.c merge.
ChangeSet@1.797.72.11, 2002-11-22 20:39:33-05:00, jdike@uml.karaya.com
Merged the tlb.c changes from the skas patch.
ChangeSet@1.797.72.10, 2002-11-22 14:27:24-05:00, jdike@uml.karaya.com
Minor build fixes to the last batch of skas merges.
ChangeSet@1.797.72.9, 2002-11-22 12:53:13-05:00, jdike@uml.karaya.com
Merged a number of small skas changes.
ChangeSet@1.797.72.8, 2002-11-21 23:22:43-05:00, jdike@uml.karaya.com
Some small build fixes to the IP checksum merge.
ChangeSet@1.797.71.4, 2002-11-21 23:21:41-05:00, jdike@uml.karaya.com
Removed the checksum.S symlink from arch/um/sys-i386/Makefile.
ChangeSet@1.797.72.7, 2002-11-21 22:30:24-05:00, jdike@uml.karaya.com
Merged the IP checksum changes from the skas code.
ChangeSet@1.797.72.6, 2002-11-21 22:26:06-05:00, jdike@uml.karaya.com
Some minor build and compilation fixes to the copy_sc merge.
ChangeSet@1.797.72.5, 2002-11-21 22:00:31-05:00, jdike@uml.karaya.com
Applied the sigcontext changes in the skas code.
ChangeSet@1.797.72.4, 2002-11-21 21:38:56-05:00, jdike@uml.karaya.com
A number of small fixes for the uaccess merge.
ChangeSet@1.797.72.3, 2002-11-21 18:54:16-05:00, jdike@uml.karaya.com
Added the uaccess changes from the skas merge.
ChangeSet@1.797.72.2, 2002-11-21 17:16:25-05:00, jdike@uml.karaya.com
Resolved the conflict between the skas and get_config changes in
line.h.
ChangeSet@1.797.80.17, 2002-11-21 14:59:43-05:00, jdike@uml.karaya.com
Added skas/mem_user.c and tt/gdb.c
ChangeSet@1.797.80.16, 2002-11-21 14:48:11-05:00, jdike@uml.karaya.com
Added a bunch of C files under arch/um/kernel/skas and
arch/um/kernel/tt.
ChangeSet@1.797.80.15, 2002-11-21 14:31:45-05:00, jdike@uml.karaya.com
Added a batch of files under arch/um/kernel/skas.
ChangeSet@1.797.80.14, 2002-11-21 14:09:26-05:00, jdike@uml.karaya.com
Added arch/um/include/mode_kern.h
ChangeSet@1.797.71.3, 2002-11-21 14:05:13-05:00, jdike@uml.karaya.com
Changed the config to pull in zlib.
ChangeSet@1.797.80.13, 2002-11-21 13:23:40-05:00, jdike@uml.karaya.com
Added the mode mmu.h and mode.h headers.
ChangeSet@1.797.80.12, 2002-11-21 13:15:09-05:00, jdike@uml.karaya.com
Added mode.h, mk_constants_kern.c, mk_constants_user.c, and um_mmu.h
ChangeSet@1.797.80.11, 2002-11-21 12:58:41-05:00, jdike@uml.karaya.com
Added ptrace-skas.h and ptrace-tt.h.
ChangeSet@1.797.80.10, 2002-11-21 12:52:36-05:00, jdike@uml.karaya.com
Added arch/um/kernel/skas/util/*, which I missed somehow.
ChangeSet@1.797.80.9, 2002-11-20 23:04:22-05:00, jdike@uml.karaya.com
Merged most of the rest of the skas changes.
ChangeSet@1.797.80.8, 2002-11-19 14:54:08-05:00, jdike@uml.karaya.com
Declared mode_tt in user_util.h.
ChangeSet@1.797.80.7, 2002-11-19 14:53:18-05:00, jdike@uml.karaya.com
Merged the skas exec reorg.
ChangeSet@1.797.80.6, 2002-11-19 13:47:41-05:00, jdike@uml.karaya.com
Fixed a couple of buglets in the signal frame merge.
ChangeSet@1.797.80.5, 2002-11-19 00:54:26-05:00, jdike@uml.karaya.com
Merged the signal frame cleanups and fixes from 2.4.
ChangeSet@1.797.80.4, 2002-11-19 00:47:18-05:00, jdike@uml.karaya.com
Fixes to the last merge.
ChangeSet@1.797.80.3, 2002-11-19 00:13:26-05:00, jdike@uml.karaya.com
Merged the os_kill_process and the driver from_user changes from
the 2.4 pool.
Also merged some other cleanups.
ChangeSet@1.797.80.2, 2002-11-18 23:28:32-05:00, jdike@uml.karaya.com
Fixed the Makefiles so that the ptproxy move from arch/um/ptproxy
to arch/um/kernel/tt/ptproxy works.
ChangeSet@1.797.80.1, 2002-11-18 22:47:18-05:00, jdike@uml.karaya.com
Moved the ptproxy code from arch/um/ptproxy to
arch/um/kernel/tt/ptproxy.
ChangeSet@1.797.71.2, 2002-11-18 20:03:13-05:00, jdike@uml.karaya.com
A few more fixes to get 2.4.48 to boot.
ChangeSet@1.797.72.1, 2002-11-18 15:57:40-05:00, jdike@uml.karaya.com
Merged the get_config changes from 2.4.
ChangeSet@1.797.71.1, 2002-11-18 15:57:00-05:00, jdike@uml.karaya.com
Updated to 2.5.48
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Allow UML kernel to run in a separate host address space
2002-12-28 15:47 [PATCH] Allow UML kernel to run in a separate host address space Jeff Dike
@ 2002-12-28 19:34 ` Linus Torvalds
2002-12-28 20:24 ` Jeff Dike
0 siblings, 1 reply; 11+ messages in thread
From: Linus Torvalds @ 2002-12-28 19:34 UTC (permalink / raw)
To: Jeff Dike; +Cc: linux-kernel
On Sat, 28 Dec 2002, Jeff Dike wrote:
> This is a large patch, but
> it's all under arch/um and include/asm-um
> a lot of it is code movement
Pulled, but that /proc/mm crap has to go (it wasn't in this patch, or I
would have rejected it).
What are the semantics the host code wants/needs, and how can we implement
a sane generic mechanism that doesn't involve opening magic files?
Having co-processes isn't wrong in itself, I just want the support to be
clean and generic, instead of a huge hack.
Linus
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Allow UML kernel to run in a separate host address space
2002-12-28 19:34 ` Linus Torvalds
@ 2002-12-28 20:24 ` Jeff Dike
2002-12-28 20:50 ` Linus Torvalds
2002-12-29 4:03 ` Jeremy Fitzhardinge
0 siblings, 2 replies; 11+ messages in thread
From: Jeff Dike @ 2002-12-28 20:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
torvalds@transmeta.com said:
> Pulled, but that /proc/mm crap has to go (it wasn't in this patch, or
> I would have rejected it).
Which is exactly why it's not in that patch. I realize that it's a lousy
interface - I'm putting it out there because I don't really have any better
ideas and I'm hoping other people do.
The next iteration of that patch will turn /proc/mm into /dev/mm, but that's
not really a great improvement. It just improves things around the edges a
little.
> What are the semantics the host code wants/needs,
1 - Multiple address spaces per process
2 - Ability to make a child switch between address spaces
3 - Ability to manipulate a child's address space (i.e. mmap, munmap, mprotect
on an address space which is not current->mm)
> and how can we
> implement a sane generic mechanism that doesn't involve opening magic
> files?
Beats me. My first suggestion was to add another file descriptor argument
to mmap et al which would represent the address space to be modified. Alan
didn't like that idea too much.
That still requires getting the descriptor from somewhere. The obvious
alternative to opening a magic file is a system call, new_mm() or something.
BTW, there is some attraction to being able to open /proc/<pid>/mm and getting
a handle on that process' address space. UML doesn't need this, but I bet
there are people who could figure out how to put it to good use.
So, here are the alternatives that I know of. Sane replacements are craved.
Creating a new, empty address space -
open /proc/mm (current UML host patch)
or system call new_mm()
Switch a child from one address to another -
PTRACE_SWITCH_MM (current UML host patch)
Manipulate a child's address space -
write a request struct to a /proc/mm fd (current UML host patch)
or add another fd to the mmap et al calls
Some obvious extensions to this (which UML doesn't need)
switch yourself from one address space to another
open and change another process' existing address space - if we're
going with system calls instead of magic files, then get_mm(pid) would suffice
for the open.
Jeff
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Allow UML kernel to run in a separate host address space
2002-12-28 20:24 ` Jeff Dike
@ 2002-12-28 20:50 ` Linus Torvalds
2002-12-28 23:37 ` Jeff Dike
2002-12-29 0:59 ` Daniel Jacobowitz
2002-12-29 4:03 ` Jeremy Fitzhardinge
1 sibling, 2 replies; 11+ messages in thread
From: Linus Torvalds @ 2002-12-28 20:50 UTC (permalink / raw)
To: Jeff Dike; +Cc: linux-kernel, Ingo Molnar
On Sat, 28 Dec 2002, Jeff Dike wrote:
>
> > What are the semantics the host code wants/needs,
>
> 1 - Multiple address spaces per process
> 2 - Ability to make a child switch between address spaces
> 3 - Ability to manipulate a child's address space (i.e. mmap, munmap, mprotect
> on an address space which is not current->mm)
Well, #3 falls under "ptrace()" as far as I'm concerned, I don't really
want to expose things through /proc (or /dev, which is even _worse_).
We used to have things that could be done with /proc/<pid>/mem, and it was
a total security disaster. It was removed in the 2.3.x series because of
that.
As to #1, that certainly shouldn't be a problem at all. We already do it
temporarily internally inside the kernel for execve() setup and for things
liek lazy TLB switching for kernel threads, and there's nothing keeping us
from having multiple "struct mm_struct" per process. The only issue is
what the interfaces should be to create one (/dev/mm is right _out_), and
how to switch them around sanely.
Having a
int fd = create_mm();
system call is certainly not wrong per se (but thinking that it should be
done using a special file is wrong - we don't have /dev/pipe either). And
creating that system call is trivial - but only worth it if there are good
sane interfaces to switch mm's around and do interesting things with them.
Done right, it should be possible to have "posix_spawn()" etc done using
something like that, ie
/* Create new VM */
int fd = create_mm();
/* populate the dang thing.. */
mmap_mm(fd, .. );
/* start it up */
clone_with_mm(fd, ...);
and the internal implementation should be perfectly trivial, since the
kernel already largely works this way internally anyway (yeah, it is
likely to need some re-organization of clone() to handle pre-created VM's
etc, but that's nothing really fundamental).
> Beats me. My first suggestion was to add another file descriptor argument
> to mmap et al which would represent the address space to be modified. Alan
> didn't like that idea too much.
I do believe that fd's are a natural way to handle it, since it needs
_some_ kind of handle, and the only generic handles the kernel has is a
file descriptor. We could create a new kind of handle, but it would be
likely to be just more complexity.
HOWEVER, the part I worry about is creating tons of new system calls that
just duplicate existing ones by adding a "fd" argument. That part I really
don't much like. Because if this were to really be a generic feature, it
really wants pretty much _all_ system calls supported, ie things like
fd = open(<mm,ptr>, flags, ...);
retval = read(<mm,ptr>..
to allow the user to not just mmap but generally "take the guise of" any
other mm for the duration of the system call.
Which really means that I _think_ the right approach would be to literally
have a "indirect-system-call-using-this-mm" system call, which does
something like
asmlinkage sys_mm_indirect(int fd, struct syscall_descriptor_block *user_args)
{
struct mm_struct *old_mm;
struct syscall_descriptor_block args;
if (memcpy_from_user(&args, user_args, sizeof(args)))
return -EFAULT;
mm = get_fd_mm(fd);
old_mm = current->mm;
current->mm = mm;
switch_mm(mm);
arch_do_syscall(&args);
current->mm = old_mm;
switch_mm(old_mm);
put_mm(mm);
}
which allows _any_ system call to be made for that mm.
Linus
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Allow UML kernel to run in a separate host address space
2002-12-28 20:50 ` Linus Torvalds
@ 2002-12-28 23:37 ` Jeff Dike
2002-12-29 4:13 ` Linus Torvalds
2002-12-29 0:59 ` Daniel Jacobowitz
1 sibling, 1 reply; 11+ messages in thread
From: Jeff Dike @ 2002-12-28 23:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Ingo Molnar
torvalds@transmeta.com said:
> On Sat, 28 Dec 2002, Jeff Dike wrote:
>
> > 3 - Ability to manipulate a child's address space (i.e. mmap, munmap,
> > mprotect on an address space which is not current->mm)
>
> Well, #3 falls under "ptrace()" as far as I'm concerned,
Not exactly. UML needs to be able to fiddle an address space that has no
process in it (swapout, COWing, maybe a few other things).
UML has two relevant processes, one which runs userspace, and one which runs
the kernel and ptraces the userspace process. The kernel process creates
an address space per UML process, and makes the userspace process switch
between them during a UML context switch. So, when there's swapping going
on, pages need to be unmapped from UML processes, and thus from the
corresponding host address spaces.
> Which really means that I _think_ the right approach would be to
> literally have a "indirect-system-call-using-this-mm" system call,
> which does something like
>
> asmlinkage sys_mm_indirect(int fd, struct syscall_descriptor_block
> *user_args)
> {
> struct mm_struct *old_mm;
> struct syscall_descriptor_block args;
>
> if (memcpy_from_user(&args, user_args, sizeof(args)))
> return -EFAULT;
>
> mm = get_fd_mm(fd);
> old_mm = current->mm;
> current->mm = mm;
> switch_mm(mm);
>
> arch_do_syscall(&args);
>
> current->mm = old_mm;
> switch_mm(old_mm);
> put_mm(mm);
> }
Hmmm, I wasn't planning on going that far, but this certainly works for UML,
as long as there is also PTRACE_SWITCH_MM to make a child jump from one mm
to another.
The calls to switch_mm() are needed when the system call is going to modify
data within the address space, but not if it's going to change mappings,
correct?
If those will cause a noticable performance hit, would it be OK to special-case
syscalls which don't need it?
if(!dont_need_no_stinkin_switch_mm[args.syscall])
switch_mm(mm);
arch_do_syscall(&args);
current->mm = old_mm;
if(!dont_need_no_stinkin_switch_mm[args.syscall])
switch_mm(old_mm);
Sorry about the double negative, but it seems easiest to sparsely populate
an array with system calls that really don't want the switch_mm().
Jeff
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Allow UML kernel to run in a separate host address space
2002-12-28 20:50 ` Linus Torvalds
2002-12-28 23:37 ` Jeff Dike
@ 2002-12-29 0:59 ` Daniel Jacobowitz
1 sibling, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2002-12-29 0:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Dike, linux-kernel, Ingo Molnar
On Sat, Dec 28, 2002 at 12:50:53PM -0800, Linus Torvalds wrote:
>
> On Sat, 28 Dec 2002, Jeff Dike wrote:
> >
> > > What are the semantics the host code wants/needs,
> >
> > 1 - Multiple address spaces per process
> > 2 - Ability to make a child switch between address spaces
> > 3 - Ability to manipulate a child's address space (i.e. mmap, munmap, mprotect
> > on an address space which is not current->mm)
>
> Well, #3 falls under "ptrace()" as far as I'm concerned, I don't really
> want to expose things through /proc (or /dev, which is even _worse_).
>
> We used to have things that could be done with /proc/<pid>/mem, and it was
> a total security disaster. It was removed in the 2.3.x series because of
> that.
FWIW, GDB also would like to have #3. We can do without it; GDB
already supports calling functions in the inferior by a stack or code
trampoline, so we could just make the child call mprotect; but it would
be faster and simpler to have a ptrace op for it. HP/UX had, among
other things, TT_PROC_SET_MPROTECT and TT_PROC_GET_MPROTECT; I don't
think we have a system call equivalent to GET_MPROTECT right now.
Of course, without more comprehensive kernel support doing
protection-based watchpoints this way is murder for perfomance, almost
as bad as just doing it by single-stepping. You need to disable them
at every syscall entry, which means that you can't have multiple
threads running in userspace while one thread is in a syscall, or you
might miss a watchpoint event.
It would be ideal to have some way to set the permissions such that
accesses from inside the kernel succeeded and from userspace failed
(i.e. render it temporarily a kernel page; but not exactly; we'd want
things like "normally writeable; currently writeable by the kernel;
still currently readable by userspace" for a normal watchpoint).
I don't know if that's practical without impacting MM performance.
Suggestions welcome; I haven't really started to work on this yet
although it's creeping up my list of important debugger projects.
PowerPC MMUs have a mechanism that could be used for this but I don't
know if other architectures do.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Allow UML kernel to run in a separate host address space
2002-12-28 20:24 ` Jeff Dike
2002-12-28 20:50 ` Linus Torvalds
@ 2002-12-29 4:03 ` Jeremy Fitzhardinge
2002-12-29 5:12 ` Jeff Dike
1 sibling, 1 reply; 11+ messages in thread
From: Jeremy Fitzhardinge @ 2002-12-29 4:03 UTC (permalink / raw)
To: Jeff Dike; +Cc: Linus Torvalds, Linux Kernel List, Julian Seward
On Sat, 2002-12-28 at 12:24, Jeff Dike wrote:
> 1 - Multiple address spaces per process
> 2 - Ability to make a child switch between address spaces
> 3 - Ability to manipulate a child's address space (i.e. mmap, munmap, mprotect
> on an address space which is not current->mm)
I suspect Valgrind could use this too at some point. There hasn't been
much discussion about it yet, but I think Valgrind may well move towards
a more complete virtualization in a later round of development, and
isolating the virtual virtual address space from the Valgrind's real
virtual address space would be very useful. (Jeff suggested the idea of
merging Valgrind and UML at some level, which does raise some
interesting possibilities.)
J
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Allow UML kernel to run in a separate host address space
2002-12-28 23:37 ` Jeff Dike
@ 2002-12-29 4:13 ` Linus Torvalds
2002-12-29 5:12 ` Jeff Dike
0 siblings, 1 reply; 11+ messages in thread
From: Linus Torvalds @ 2002-12-29 4:13 UTC (permalink / raw)
To: Jeff Dike; +Cc: linux-kernel, Ingo Molnar
On Sat, 28 Dec 2002, Jeff Dike wrote:
> torvalds@transmeta.com said:
> > On Sat, 28 Dec 2002, Jeff Dike wrote:
> >
> > > 3 - Ability to manipulate a child's address space (i.e. mmap, munmap,
> > > mprotect on an address space which is not current->mm)
> >
> > Well, #3 falls under "ptrace()" as far as I'm concerned,
>
> Not exactly. UML needs to be able to fiddle an address space that has no
> process in it (swapout, COWing, maybe a few other things).
But that is an address space that it should already has access to through,
since it created it in the first place (ie it would fall under the normal
"sys_mm_indirect()" case).
The thing that I _really_ don't want to have is soem uncontrolled way to
generate accesses to existing "struct mm_struct"s, since that is really
dangerous from a security standpoint.
We could have a PTRACE_GET_MM_FD kind of thing for ptrace (and then the
gdb/tracer can use that to create mappings in the process), but the reason
I want that "hook" to be through ptrace itself is simply that it's a known
interface to control other unrelated processes.
So if you create the MM's yourself, you can use the indirection directly.
But if you want to control your children or unrelated processes, you use
ptrace to get the hook.
Linus
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Allow UML kernel to run in a separate host address space
2002-12-29 4:03 ` Jeremy Fitzhardinge
@ 2002-12-29 5:12 ` Jeff Dike
0 siblings, 0 replies; 11+ messages in thread
From: Jeff Dike @ 2002-12-29 5:12 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Linus Torvalds, Linux Kernel List, Julian Seward
jeremy@goop.org said:
> I suspect Valgrind could use this too at some point. There hasn't
> been much discussion about it yet, but I think Valgrind may well move
> towards a more complete virtualization in a later round of
> development, and isolating the virtual virtual address space from the
> Valgrind's real virtual address space would be very useful. (Jeff
> suggested the idea of merging Valgrind and UML at some level, which
> does raise some interesting possibilities.)
Yes, valgrind already has a pseudo-scheduler, a psuedo-threads library, it
delivers signals by hand, and it wants to run its client in a separate
thread so it can get out of the business of being an LD_PRELOAD shared
library.
This is all stuff that UML has, that UML does right (/me crosses fingers),
and that is usable by Valgrind (and anything else that's interested) with
some repackaging of UML as a library.
Replacing Valgrind's signal delivery with UML's is a no-brainer. Replacing
its scheduler and threads library would involve it creating UML processes
by calling UML's do_fork(). Valgrind would need to provide the low-level
switch_to, I think. There are probably other things that Valgrind would
need to provide, but I see no reason this wouldn't work.
Jeff
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] Allow UML kernel to run in a separate host address space
2002-12-29 4:13 ` Linus Torvalds
@ 2002-12-29 5:12 ` Jeff Dike
0 siblings, 0 replies; 11+ messages in thread
From: Jeff Dike @ 2002-12-29 5:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Ingo Molnar
torvalds@transmeta.com said:
> But that is an address space that it should already has access to
> through, since it created it in the first place (ie it would fall
> under the normal "sys_mm_indirect()" case).
Yes, and so it doesn't fall under ptrace. I think we're in violent agreement
here.
> The thing that I _really_ don't want to have is soem uncontrolled way
> to generate accesses to existing "struct mm_struct"s, since that is
> really dangerous from a security standpoint.
Fine by me. UML has no need for manipulating pre-existing address spaces.
> We could have a PTRACE_GET_MM_FD kind of thing for ptrace (and then
> the gdb/tracer can use that to create mappings in the process), but
> the reason I want that "hook" to be through ptrace itself is simply
> that it's a known interface to control other unrelated processes.
>
> So if you create the MM's yourself, you can use the indirection
> directly. But if you want to control your children or unrelated
> processes, you use ptrace to get the hook.
Yup. As far as UML is concerned, this is all fine. It has no need of
a PTRACE_GET_MM_FD since it creates all address spaces itself, but other
tools might.
Jeff
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2002-12-29 5:00 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-28 15:47 [PATCH] Allow UML kernel to run in a separate host address space Jeff Dike
2002-12-28 19:34 ` Linus Torvalds
2002-12-28 20:24 ` Jeff Dike
2002-12-28 20:50 ` Linus Torvalds
2002-12-28 23:37 ` Jeff Dike
2002-12-29 4:13 ` Linus Torvalds
2002-12-29 5:12 ` Jeff Dike
2002-12-29 0:59 ` Daniel Jacobowitz
2002-12-29 4:03 ` Jeremy Fitzhardinge
2002-12-29 5:12 ` Jeff Dike
-- strict thread matches above, loose matches on Subject: below --
2002-12-17 23:24 Jeff Dike
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox