SKAS4 design question

Has any thought been given to making SKAS4 suitably generic that it could be used for more than just UML?

PS: If I understand correctly, UML with the current SKAS3 works by swapping processes into and out of a single "user" address space.

I
propose a system where many distinct "user" address spaces are maintained by the kernel and execution is placed whereever the user-mode scheduler says.

Quoted 2 lines · Jacob Bachmeyer

Has any thought been given to making SKAS4 suitably generic that it could be used for more than just UML?

Not yet, thoughts welcome.

Quoted 6 lines

PS: If I understand correctly, UML with the current SKAS3 works by swapping processes into and out of a single "user" address space.

I propose a system where many distinct "user" address spaces are maintained by the kernel and execution is placed whereever the user-mode scheduler says.

What you say is not clear, but the most obvious understanding of the above sentence is that you propose what already happens.

However, SKAS3 and current ideas for SKAS4, with different APIs but similar semantics, say: implement all guest processes as user-level threads (totally implemented within UML) with the exception that we allow different address spaces.

So we have "switch the guest proc to a different address space" (PTRACE_SWITCH_MM, in arch/i386/kernel/ptrace.c), manipulate with mmap/munmap/mprotect any of these address spaces, and destroy it (all in mm/proc_mm.c).

Quoted 4 lines · Blaisorblade

Quoted 2 lines · Jacob Bachmeyer

Has any thought been given to making SKAS4 suitably generic that it could be used for more than just UML?

Quoted 1 line

Not yet, thoughts welcome.

Let's see:

to support HURD (which uses the Mach ABI):

-- existing facilities plus trap lcall gates

to support WINE (which follows Win32 conventions (ick!)): (x86 only)

--existing facilities plus
-- trap on access to specified pages

Explanation: Win32 API calls are not syscalls in the normal
sense--rather they are made by calling into a system DLL.

These DLLs
are mapped into the process' address space on Windows and under current WINE, much like shared objects in normal Linux. This idea would enable WINE to not actually map these DLLs, but rather simply set the pages where the DLLs would be mapped as "fasttrap".

Then, when the program
attempts to access a DLL's memory image, the kernel would intercept the request and quickly pass it to a userspace thread,

which handles the
"page fault".

The page remains set as "fasttrap", and the control
process modifies the address space and CPU context appropriately before allowing execution to continue.

-- read/write in guest address space

Explanation: mmap is fine for big changes to an address space
(such as loading modules), but one capability WINE would need for this to be truly useful is 1/2/4/8/16-byte PEEK and POKE. (Some Win32 programs like to do wierd things with Windows' system code--in conjunction with "fasttrap", this would allow WINE to keep such programs happy.) As I understand, ptrace already provides this, hopefully adequetely.

-- intercept arbitrary interrupts in guest address space

Explanation: Many older Windows programs (Win16 era)
occasionally directly invoke various soft interrupts (these are basically DOS syscalls). The ability to intercept these is necessary, but need not be particularly efficient or fast.

-- modify guest address space's LDT

Explanation: Again, Win16 support. Old Windows actually
allowed processes to request segments for whatever purpose. This may or may not be doable on all modern hardware.

-- transparently use threads in guest address spaces, if desired

Explanation: WINE currently uses the host's scheduler.
Changing it to this new API shouldn't adversely affect that ability. (And on second thought, using a UML library might not be an option.)

I shall clarify my proposal: each thread is assigned an address space,

while an address space can contain multiple threads.

Each thread also
has a STOP/RUN flag, which if set to RUN, causes the host scheduler to consider that thread for execution (along with all other runnable threads). This flag allows either the userspace control process to make scheduling decisions itself, (by only setting one of its threads to RUN) or to punt and have the kernel handle all scheduling for its threads (by setting them all to RUN and using STOP only to block a thread).

Could all SKAS4 APIs be multiplexed through one syscall? (Perhaps simply as more ptrace functions, or as a new "skas4" syscall?)

Quoted 9 lines · Jacob Bachmeyer

Quoted 7 lines · Blaisorblade

Quoted 3 lines · Jacob Bachmeyer

Has any thought been given to making SKAS4 suitably generic that it could be used for more than just UML?

Not yet, thoughts welcome.

Quoted 5 lines

Let's see:

to support HURD (which uses the Mach ABI):

-- existing facilities plus trap lcall gates

I.e. extend ptrace to trap lcall gates, right? That's another thing, could be done, but it relates more to the Linux-ABI project... at least this can't be merged in mainline since we don't support lcall gates.

Quoted 4 lines

to support WINE (which follows Win32 conventions (ick!)): (x86 only)

--existing facilities plus
-- trap on access to specified pages

We do that: make them unmapped and trap SIGSEGV through ptrace. Doesn't work for accesses from kernel-space (you don't get SIGSEGV, just, likely, -EFAULT). And it's horribly slow. And trapping for kernelspace accesses is
bad.

Quoted 2 lines

Explanation: Win32 API calls are not syscalls in the normal
sense--rather they are made by calling into a system DLL.

Yep, it then can decide whether to trap into the kernel or not (depending on that version's implementation).

Quoted 4 lines

These DLLs are mapped into the process' address space on Windows and under current WINE, much like shared objects in normal Linux. This idea would enable WINE to not actually map these DLLs, but rather simply set the pages where the DLLs would be mapped as "fasttrap".

Which is the reason to trap to the kernel? It's going to be slow. A page fault, like a syscall, is costly (and probably more since it's an interrupt).

If there is a good reason not to map the DLLs, it may at least make sense, but WINE users aren't going to use special patches, and getting such an hackish thing in mainline may be a hard sell (except the reason is _really_ good).

Quoted 2 lines

Then, when the program attempts to access a DLL's memory image, the kernel would intercept the request and quickly pass it to a userspace thread,

Good saying, quickly pass it... signals are slow. There faster but more complicated primitives (I remind netlink for instance).

Quoted 4 lines

which handles the "page fault".

The page remains set as "fasttrap", and the control process modifies the address space and CPU context appropriately before allowing execution to continue.

"Modifies" to return the call or to map the page in? You seem to imply it performs the call and sets the return value in EAX, right?

Also, for security reasons it's not possible to let userspace trap OS accesses (as the OS is more privileged - search TENEX at http://www.isi.edu/~faber/cs402/notes/lecture19.html to see how bad is that).

Quoted 8 lines

-- read/write in guest address space
Explanation: mmap is fine for big changes to an address space
(such as loading modules), but one capability WINE would need for this to be truly useful is 1/2/4/8/16-byte PEEK and POKE. (Some Win32 programs like to do wierd things with Windows' system code--in conjunction with "fasttrap", this would allow WINE to keep such programs happy.) As I understand, ptrace already provides this, hopefully adequetely.

It provides this, it could be made a bit faster (I've reviewed a patch from another project which uses heavily ptrace, which makes that faster).

Quoted 5 lines

-- intercept arbitrary interrupts in guest address space
Explanation: Many older Windows programs (Win16 era)
occasionally directly invoke various soft interrupts (these are basically DOS syscalls). The ability to intercept these is necessary, but need not be particularly efficient or fast.

I recall that hardware IRQ n. x is mapped to k+x, where k is fixed and low; we now have with ACPI 32 IRQs I guess (on my machine the kernel uses up to 22 IRQs), so I guess int 0x21 it's going to conflict somewhere.

That said, this could be added too for interrupts not reserved by the kernel (that is CPU exceptions). But DOSEMU already runs x86 programs, so WINE should be able to do it too... ah, yep, it uses vm86, while you need to do that on a paged system.

Quoted 5 lines

-- transparently use threads in guest address spaces, if desired
Explanation: WINE currently uses the host's scheduler.
Changing it to this new API shouldn't adversely affect that ability. (And on second thought, using a UML library might not be an option.)

Quoted 2 lines

I shall clarify my proposal: each thread is assigned an address space,

and (you forget to say) it can be changed through PTRACE_SWITCH_MM you mean... (otherwise I don't see the addition).

Quoted 1 line

while an address space can contain multiple threads.

you can PTRACE_SWITCH_MM multiple threads to the same address space

Quoted 6 lines

Each thread also has a STOP/RUN flag, which if set to RUN, causes the host scheduler to consider that thread for execution (along with all other runnable threads). This flag allows either the userspace control process to make scheduling decisions itself, (by only setting one of its threads to RUN) or to punt and have the kernel handle all scheduling for its threads (by setting them all to RUN and using STOP only to block a thread).

Hmm, sleeping like that is easy if you mean that only a thread can switch itself from RUN to STOP. The thread can use some mutex/semaphore thing, at that point.

To switch a thread from RUN to STOP from the exterior, you can currentlykill it with -STOP. Beware it's maybe slow, but I don't know whether it matters and if it can be made much faster.

The problem (I think) is that SIGSTOP will be processed not at kill() time, but at delivery time, i.e. after a context switch to the receiving thread, before returning to userspace. I've not checked for SIGSTOP and am not sure for the rest, but I think it's this way.

Quoted 2 lines

Could all SKAS4 APIs be multiplexed through one syscall? (Perhaps simply as more ptrace functions, or as a new "skas4" syscall?)

"multiplexing" like ipc(2) is a bad idea.

However, currently the idea is sys_mm_indirect , taking an fd representing an mm context, a syscall number and its parameters, plus a syscall to get afd representing a mm context.

Quoted 12 lines · Blaisorblade

Quoted 11 lines · Jacob Bachmeyer

Quoted 5 lines · Blaisorblade

Quoted 2 lines · Jacob Bachmeyer

Has any thought been given to making SKAS4 suitably generic that it could be used for more than just UML?

Not yet, thoughts welcome.

Let's see:

to support HURD (which uses the Mach ABI):

Quoted 5 lines

Quoted 1 line

-- existing facilities plus trap lcall gates

I.e. extend ptrace to trap lcall gates, right? That's another thing, could be done, but it relates more to the Linux-ABI project... at least this can't be merged in mainline since we don't support lcall gates.

Why not? And for that matter, why does ptrace not currently catch lcalls?

Quoted 9 lines

Quoted 4 lines

to support WINE (which follows Win32 conventions (ick!)): (x86 only)

--existing facilities plus
-- trap on access to specified pages

We do that: make them unmapped and trap SIGSEGV through ptrace. Doesn't work for accesses from kernel-space (you don't get SIGSEGV, just, likely, -EFAULT). And it's horribly slow. And trapping for kernelspace accesses is bad.

You don't have to trap kernelspace accesses; (-EFAULT there would be a good thing--the host kernel shouldn't be looking in these pages anyway) this is only to apply to userspace code, but SIGSEGV is slow--why should it be fast? It's an error path.

Quoted 11 lines

We do that: make them unmapped and trap SIGSEGV through ptrace.

Quoted 5 lines

These DLLs
are mapped into the process' address space on Windows and under current WINE, much like shared objects in normal Linux. This idea would enable WINE to not actually map these DLLs, but rather simply set the pages where the DLLs would be mapped as "fasttrap".

Which is the reason to trap to the kernel? It's going to be slow. A page fault, like a syscall, is costly (and probably more since it's an interrupt).

Quoted 4 lines

If there is a good reason not to map the DLLs, it may at least make sense, but WINE users aren't going to use special patches, and getting such an hackish thing in mainline may be a hard sell (except the reason is _really_ good).

The overhead is not all that large, as most Win32 API calls ultimately go into the kernel anyway.

This also should allow WINE to work well on
platforms such as x86-64, without needing multiple WINE binaries. (64-bit control process managing mix of 32 and 64 bit address spaces)

Also, what exactly are vsyscalls?

Executables are already demand-paged--so page faults routinely happen anyway.

The reason to trap is to allow WINE to intercept the call while sitting in another address space. (Each Win32 process would have its own guest address space.) The idea is to have the interfaces UML uses be generic enough for WINE to also use.

The reason is simple--improved security by enforcing a sandbox around WINE.

Quoted 6 lines

Quoted 3 lines

Then, when the program
attempts to access a DLL's memory image, the kernel would intercept the request and quickly pass it to a userspace thread,

Good saying, quickly pass it... signals are slow. There faster but more complicated primitives (I remind netlink for instance).

User DLLs (those from the program itself) would actually be mapped. The system DLLs (kernel32, user32, etc.) that WINE itself implements on Linux and that must trap to kernelspace on Windows would be loaded this way.

One benefit is to reduce the chance of conflict, as various internal modules in WINE that don't exist in Windows could thus be removed from the visible (to the Win32 app) address space. This could have uses other than WINE, too. One possibility is as a "padded cell" of sorts--a process is started in a guest address space under a control program that intercepts and discards all syscalls. However, certain pages in that address space are used as a restricted system interface--accessing them blocks the accessing thread and causes a (host) syscall to return in the control process. This syscall would block until a guest thread trips a "fasttrap" page and then returns information such as exact address accessed, read or write, and if write, value written. This syscall need not be new--read or ioctl on an appropriate fd (netlink socket perhaps?) would be enough. The control thread then carries out the requested action (whatever that maybe) and permits the jailed thread to again run.

"fasttrap" may have been a poor choice of terms. The idea is to have more or less generic kernel-in-userspace functionality with one process as a"usermode supervisor" watching a set of other processes.

Quoted 4 lines

Also, for security reasons it's not possible to let userspace trap OS accesses (as the OS is more privileged - search TENEX at
http://www.isi.edu/~faber/cs402/notes/lecture19.html to see how bad is that).

Perform the API call. It would alter the CPU context, possibly, (if the call requires it) also changing the guest address space. There should be no OS accesses to these pages--those would not trap, but would return -EFAULT because the pages would not actually be allocated. (Win32 programs should not be making Linux syscalls--a version of WINE that uses this would need to catch and ignore any Linux syscalls made.)

Quoted 21 lines

Quoted 8 lines

-- read/write in guest address space
Explanation: mmap is fine for big changes to an address space
(such as loading modules), but one capability WINE would need for this to be truly useful is 1/2/4/8/16-byte PEEK and POKE. (Some Win32 programs like to do wierd things with Windows' system code--in conjunction with "fasttrap", this would allow WINE to keep such programs happy.) As I understand, ptrace already provides this, hopefully adequetely.

It provides this, it could be made a bit faster (I've reviewed a patch from another project which uses heavily ptrace, which makes that faster).

Quoted 5 lines

-- intercept arbitrary interrupts in guest address space
Explanation: Many older Windows programs (Win16 era)
occasionally directly invoke various soft interrupts (these are basically DOS syscalls). The ability to intercept these is necessary, but need not be particularly efficient or fast.

I recall that hardware IRQ n. x is mapped to k+x, where k is fixed and low; we now have with ACPI 32 IRQs I guess (on my machine the kernel uses up to 22 IRQs), so I guess int 0x21 it's going to conflict somewhere.

Quoted 4 lines

That said, this could be added too for interrupts not reserved by the kernel (that is CPU exceptions). But DOSEMU already runs x86 programs, so WINE should be able to do it too... ah, yep, it uses vm86, while you need to do that on a paged system.

The only requirement here is to call vm86 in another address space, which is already doable--except on 64-bit hardware, where vm86 doesn't exist anyway.

This is exactly it--I wanted to be sure that distinct threads can share an address space, while one control process can manage as many address spaces as are needed/wanted. There should be no addition here--this was mentioned for completeness.

How about a PTRACE_SET_THREAD_RUNNABLE that takes a 1 (RUN) or 0 (STOP) as its argument and has immediate effects? The problem (IIRC) with SIGSTOP is that signals are delivered to all threads in a process,

Quoted 3 lines

However, currently the idea is sys_mm_indirect , taking an fd representing an mm context, a syscall number and its parameters, plus a syscall to get afd representing a mm context.

How are address spaces manipulated? Could ioctls on the mm context's fd be useful?

Quoted 19 lines · Jacob Bachmeyer

Quoted 17 lines · Blaisorblade

Quoted 14 lines · Jacob Bachmeyer

Quoted 7 lines · Blaisorblade

Quoted 3 lines · Jacob Bachmeyer

Has any thought been given to making SKAS4 suitably generic that it could be used for more than just UML?

Not yet, thoughts welcome.

Let's see:

to support HURD (which uses the Mach ABI):

-- existing facilities plus trap lcall gates

Quoted 5 lines

Quoted 3 lines

I.e. extend ptrace to trap lcall gates, right? That's another thing, could be done, but it relates more to the Linux-ABI project... at least this can't be merged in mainline since we don't support lcall gates.

Why not? And for that matter, why does ptrace not currently catch lcalls?

The lcall stub was removed from arch/i386/kernel/entry.S a little time ago (about 2.6.12 IIRC). So vanilla Linux can't handle lcalls. Clear now?

Quoted 10 lines

Quoted 10 lines

Quoted 5 lines

to support WINE (which follows Win32 conventions (ick!)): (x86 only)

--existing facilities plus
-- trap on access to specified pages

We do that: make them unmapped and trap SIGSEGV through ptrace. Doesn't work for accesses from kernel-space (you don't get SIGSEGV, just, likely, -EFAULT). And it's horribly slow. And trapping for kernelspace accesses is bad.

Quoted 4 lines

You don't have to trap kernelspace accesses; (-EFAULT there would be a good thing--the host kernel shouldn't be looking in these pages anyway) this is only to apply to userspace code, but SIGSEGV is slow--why should it be fast? It's an error path.

Yes, it is thought to be only an error path, but UML abuses of it for normal control, and I said that the kernel supports "fasttrap", but only via SIGSEGV, i.e. in a slow way.

Quoted 4 lines

Quoted 2 lines

We do that: make them unmapped and trap SIGSEGV through ptrace.

The overhead is not all that large, as most Win32 API calls ultimately go into the kernel anyway.

A kernel switch only costs about some thousands TSC units (see the rdtsc assembly instruction), while a signal delivery to a foreign process can cost a lot more (I measure it in the order of 4* 10^5 TSC units, even without a memory switch).

Quoted 2 lines

This also should allow WINE to work well on platforms such as x86-64, without needing multiple WINE binaries. (64-bit control process managing mix of 32 and 64 bit address spaces)

Writing 64-bit code handling cleanly 32-bit syscalls is hard. Compiling 32-bit code in 32-bit mode to do the same is simpler.

Quoted 7 lines

The reason to trap is to allow WINE to intercept the call while sitting in another address space. (Each Win32 process would have its own guest address space.) The idea is to have the interfaces UML uses
be generic enough for WINE to also use.

The reason is simple--improved security by enforcing a sandbox around WINE.

Quoted 12 lines

Quoted 6 lines

Quoted 3 lines

Then, when the program
attempts to access a DLL's memory image, the kernel would intercept the request and quickly pass it to a userspace thread,

Good saying, quickly pass it... signals are slow. There faster but more complicated primitives (I remind netlink for instance).

User DLLs (those from the program itself) would actually be mapped. The system DLLs (kernel32, user32, etc.) that WINE itself implements on Linux and that must trap to kernelspace on Windows would be loaded this way.

Quoted 14 lines

One benefit is to reduce the chance of conflict, as various internal modules in WINE that don't exist in Windows could thus be removed from the visible (to the Win32 app) address space. This could
have uses other than WINE, too. One possibility is as a "padded cell"
of sorts--a process is started in a guest address space under a control
program that intercepts and discards all syscalls. However, certain
pages in that address space are used as a restricted system
interface--accessing them blocks the accessing thread and causes a
(host) syscall to return in the control process. This syscall would
block until a guest thread trips a "fasttrap" page and then returns
information such as exact address accessed, read or write, and if write,
value written. This syscall need not be new--read or ioctl on an
appropriate fd (netlink socket perhaps?) would be enough. The control
thread then carries out the requested action (whatever that maybe) and
permits the jailed thread to again run.

Andrea Arcangeli merged such a "padded cell" functionality, but the allowed interface is read, not a page fault. The former is faster and easier to use, and also allows writing arbitrary amounts of data.

It's called secure computing (see kernel/seccomp.c for details, and/or look on LWN.net for an article about it).

Quoted 11 lines

Quoted 11 lines

Quoted 8 lines

-- read/write in guest address space
Explanation: mmap is fine for big changes to an address space
(such as loading modules), but one capability WINE would need for this to be truly useful is 1/2/4/8/16-byte PEEK and POKE. (Some Win32 programs like to do wierd things with Windows' system code--in conjunction with "fasttrap", this would allow WINE to keep such programs happy.) As I understand, ptrace already provides this, hopefully adequetely.

It provides this, it could be made a bit faster (I've reviewed a patch from another project which uses heavily ptrace, which makes that faster).

Quoted 15 lines

Quoted 14 lines

Quoted 5 lines

-- intercept arbitrary interrupts in guest address space
Explanation: Many older Windows programs (Win16 era)
occasionally directly invoke various soft interrupts (these are basically DOS syscalls). The ability to intercept these is necessary, but need not be particularly efficient or fast.

I recall that hardware IRQ n. x is mapped to k+x, where k is fixed and low; we now have with ACPI 32 IRQs I guess (on my machine the kernel uses up to 22 IRQs), so I guess int 0x21 it's going to conflict somewhere.

That said, this could be added too for interrupts not reserved by the kernel (that is CPU exceptions). But DOSEMU already runs x86 programs, so WINE should be able to do it too... ah, yep, it uses vm86, while you need to do that on a paged system.

Quoted 3 lines

The only requirement here is to call vm86 in another address space, which is already doable--except on 64-bit hardware, where vm86 doesn't exist anyway.

Wait a moment - Windows 3.1 uses 286 paging, and Win16 userspace progs use up to 16M of Ram. You don't have this on vm86(), right?

Quoted 3 lines

How about a PTRACE_SET_THREAD_RUNNABLE that takes a 1 (RUN) or 0 (STOP) as its argument and has immediate effects? The problem (IIRC) with SIGSTOP is that signals are delivered to all threads in a process,

Isn't there tkill() for this purpose (signals to a specific thread)? And if it doesn't work, it should be fixed. Having tons of incoherent APIs is bad, as long as things can be done with current ones.

Quoted 6 lines

Quoted 3 lines

However, currently the idea is sys_mm_indirect , taking an fd representing an mm context, a syscall number and its parameters, plus a syscall to get a fd representing a mm context.

How are address spaces manipulated? Could ioctls on the mm context's fd be useful?

We don't use ioctls, they are inelegants; SKAS3 uses write which is just as bad.

For SKAS4, instead, you'd use sys_mm_indirectI(); you say:

mm_indirect(addr_space_fd, __NR_MMAP, <mmap_args>) mm_indirect(addr_space_fd, __NR_MUNMAP, <munmap_args>)

and so on, for each syscall (excluding fork and exit, for now). To destroy an address space you simply call close on its fd.

Quoted 11 lines · Blaisorblade

Quoted 9 lines · Jacob Bachmeyer

Quoted 5 lines · Blaisorblade

On Thursday 19 January 2006 00:52, Jacob Bachmeyer wrote:

I.e. extend ptrace to trap lcall gates, right? That's another thing, could be done, but it relates more to the Linux-ABI project... at least this can't be merged in mainline since we don't support lcall gates.

Why not? And for that matter, why does ptrace not currently catch lcalls?

Quoted 2 lines

The lcall stub was removed from arch/i386/kernel/entry.S a little time ago (about 2.6.12 IIRC). So vanilla Linux can't handle lcalls. Clear now?

Yes, the last time I looked into that part of the kernel was back in 2.4. So, does this mean that lcalls can no longer be potentially used to escape from UML?

Quoted 3 lines

Yes, it is thought to be only an error path, but UML abuses of it for normal control, and I said that the kernel supports "fasttrap", but only via SIGSEGV, i.e. in a slow way.

That is the exact problem. It shouldn't be abused--a proper interface that has acceptable performance should be devised. (You mention netlink--was it looked into?

This might help with some UML performance
issues.)

Basically what is needed is a means to set a page to no access but cause some other action to occur rather than generate SIGSEGV.

Quoted 9 lines

Quoted 4 lines

Quoted 1 line

We do that: make them unmapped and trap SIGSEGV through ptrace.

The overhead is not all that large, as most Win32 API calls ultimately go into the kernel anyway.

A kernel switch only costs about some thousands TSC units (see the rdtsc assembly instruction), while a signal delivery to a foreign process can cost a lot more (I measure it in the order of 4* 10^5 TSC units, even without a memory switch).

Then a more efficient interface is needed. Besides, this would need to be synchronous.

Quoted 6 lines

Quoted 3 lines

This also should allow WINE to work well on
platforms such as x86-64, without needing multiple WINE binaries. (64-bit control process managing mix of 32 and 64 bit address spaces)

Writing 64-bit code handling cleanly 32-bit syscalls is hard. Compiling 32-bit code in 32-bit mode to do the same is simpler.

The problem is that they need to communicate, especially once Win64 actually hits. WINE currently has a (confusing) "relay" layer that already does similar tasks for 16/32 bit. Furthermore, the Win32 API calling convention is fairly well defined, (parameters on stack; return in EAX) so this shouldn't be more of a problem than has been solved in the past. (That doesn't mean it won't be a real PITA.)

Quoted 7 lines

Quoted 7 lines

The reason to trap is to allow WINE to intercept the call while sitting in another address space. (Each Win32 process would have its own guest address space.) The idea is to have the interfaces UML uses be generic enough for WINE to also use.

The reason is simple--improved security by enforcing a sandbox around WINE.

Seccomp (see below--thanks for bringing it up) could more easily be used to solve this. (Why bother with trapping all the time when only a few pages really need protection? Furthermore, the external control thread would thus have veto power over all syscalls made, so the sandbox can be easily enforced.)

Quoted 4 lines

Andrea Arcangeli merged such a "padded cell" functionality, but the allowed interface is read, not a page fault. The former is faster and easier to use, and also allows writing arbitrary amounts of data.

Quoted 2 lines

It's called secure computing (see kernel/seccomp.c for details, and/or look on LWN.net for an article about it).

I had looked at this earlier, but hadn't realized that it could be used to implement this--provided that mm_indirect can make syscalls in a seccomp address space (bypassing the restriction),

this can do
everything that "fasttrap" could (using some help from appropriate code in userspace).

Maybe SKAS4 should add a new seccomp level?

Quoted 2 lines

Wait a moment - Windows 3.1 uses 286 paging, and Win16 userspace progs use up to 16M of Ram. You don't have this on vm86(), right?

No, but as I said vm86 is gone on x86-64, which means that DOS soft ints are somehow caught--inside the address space in question. (WINE currently runs in-process, I am trying to lay the groundwork to change that--thus all the crazy stuff previously about "fasttrap" to another userspace.) Current WINE can use vm86 on i386 platform, however.

This (Win16 programs with 16MiB of RAM) also means that WINE could always intercept soft interrupts--even without use of vm86.

The other catch is that 64 and 32 bit code doesn't mix very well, and they must be kept in separate processes normally--thus the reason for a 64-bit control process to be able to handle both 32 and 64 bit address spaces. The entire kernel is 64-bit anyway, so leaving the option open can't be too insanely hard.

The other problem is that a more specific interface could be much faster. OTOH, perhaps a better strategy would be to improve the signals--thus also lessening the other problem (slowness of SIGSEGV) as well as improving performance generally.

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

However, currently the idea is sys_mm_indirect , taking an fd representing an mm context, a syscall number and its parameters, plus a syscall to get a fd representing a mm context.

How are address spaces manipulated? Could ioctls on the mm context's fd be useful?

Quoted 2 lines

We don't use ioctls, they are inelegants; SKAS3 uses write which is just as bad.

What is inelegant about an ioctl on a special fd? I say that ioctls are far preferrable to more fds (on other files), or the extra complexity of implementing some other interface (maybe using netlink?).

Besides, if
you implement your own struct file_operations, you get ioctl support by writing the handler function for it.

(If I understand the Linux 2.6.14
VFS correctly).

OTOH, if no operations that fall into ioctl's area are needed, then implementing ioctl for its own sake is silly.

Quoted 5 lines

For SKAS4, instead, you'd use sys_mm_indirectI(); you say:

mm_indirect(addr_space_fd, __NR_MMAP, <mmap_args>) mm_indirect(addr_space_fd, __NR_MUNMAP, <munmap_args>)

Quoted 2 lines

and so on, for each syscall (excluding fork and exit, for now). To destroy an address space you simply call close on its fd.

How do you map region X of the guest address space to region Y (or somewhere) in your own? mmap/munmap on the address space's fd would make sense here.