LWN: Comments on "Emulating Windows system calls, take 2"

Emulating Windows system calls, take 2

ras — Sat, 02 Jan 2021 10:50:32 +0000

This is a very late comment I guess, buts that's mostly because I still don't know what is being proposed.

> The problem with classic personalities is that they are very shallow. They can be used to adapt syscalls, but little else.

I presume that means the design of personality API forces you to place the code in the kernel. "The code" is something using Linux to emulate the foreign syscall. I can tell you with reasonable authority[0] that's true.

Surprisingly the code doesn't care where it lives. In fact it mostly doesn't change. Even if the code was a kernel module moving to user space. I know that because I've done it [1].

I can also tell you from the maintainer of the said code's perspective, user space is the nicer place to be. Far, far, far nicer. To paint the picture, the kernel code I maintained has to do syscall's in some way. Why syscall's? Because they are the only interface in the kernel that's stable, and life's far too short spend it migrating out of tree code to each kernel version. But getting to syscall table was mission bloody impossible. The mechanism I inherited was unwinding the kernel stack, disassembling return addresses until you found the code that dispatched to you, then extract the pointer to the syscall table from the previous instruction. (Sorry if I wrecked your meal.) This is of course not easy to port between kernel versions either, but at least you are porting just one obnoxious thing.

Turns out there is only one real challenge to moving it to user space. That is getting the kernel to deliver the syscall to some user space trampoline address. That ends up in being one of two challenges. The first kind is when the syscall mechanism is what the Linux kernel uses. In that case is becomes 'redirect any syscall outside of the trampoline range to the trampoline'. This case is covered in the article.

The 2nd kind is when the syscall mechanism is not what the kernel uses. A software interrupt is the obvious way, but the x86 / amd64 designers in particular have displayed commendable imaginative flair in this area. However, in every case I've seen the mechanism is illegal to do in user space, so either the kernel handles it, or it's SIGSEGV. So all you have to do is arrange for that mechanism (whatever it is) to boomerang to an address in the trampoline, with minimal overhead.

Handling the second case doesn't seem hard: a standardised API like syscall_trap(SYSCALL_TRAP_INT80, trampoline_trap, trampoline_begin, trampoline_end, flags), a kernel module for each SYSCALL_TRAP_??? mechanism. Job done.

How the proposed mechanism do this is a bit of a mystery. I guess I should look at the code.

[0] http://ibcs64.sourceforge.net/
[1] http://ibcs-us.sourceforge.net/

Emulating Windows system calls, take 2

Ericson2314 — Tue, 11 Aug 2020 19:51:32 +0000

That's why I brought up Capsicum / CloudABI. It's about the most interesting thing that can be done that is "shallow".

Emulating Windows system calls, take 2

Ericson2314 — Tue, 11 Aug 2020 19:50:44 +0000

Thanks for letting me know!

Emulating Windows system calls, take 2

Ericson2314 — Tue, 11 Aug 2020 19:50:26 +0000

Yes absolutely agreed. Being able to do "deep" stuff would basically require "composition over configuration", so an exokernel, to reign in the complexity. Great idea, but Linux absolutely is not that.

Emulating Windows system calls, take 2

Cyberax — Tue, 11 Aug 2020 19:06:06 +0000

The problem with classic personalities is that they are very shallow. They can be used to adapt syscalls, but little else.

Fully emulating Windows requires much more infrastructure. Windows has completely different synchronization primitives, different IO stack (IOCP!), and a different thread and process model.

You need a LOT of code to emulate all of this. You can put it into the kernel (and there were projects that basically put Wine into kernel mode), but the chances of it getting merged are nil.

Emulating Windows system calls, take 2

farnz — Tue, 11 Aug 2020 18:15:27 +0000

Note that personalities already exist in Linux, as a kernel-side concept.

It looks like the only non-Linux personality that hasn't bitrotted to the point of removal is https://elixir.bootlin.com/linux/latest/source/arch/alpha/kernel/osf_sys.c

Emulating Windows system calls, take 2

Ericson2314 — Tue, 11 Aug 2020 15:50:01 +0000

I think there should be both. This is a *dynamic* way to control the meaning of syscalls, personalities area *static* way.

In general, it's not good to force the use of dynamic solutions to static needs, even though the dynamic one is strictly more expressive. It's good to be static where possible because it better conveys intent, is simpler to reason about, especially w.r.t. security, and can be better optimized.

I think Linux should have this and personalities. For example, there could be a native personality, a Windows personality (via Kernel module, let's say), and a way to disjoint-union (sum) personalities via name-spacing (e.g. a tag big) somewhere in memory or registers. Then Wine can use this in combination with the native+windows union personality, and the trampoline just neeeds to set the Windows-or-Linux bit, letting the kernel do the rest.

I separately want personalities to revive Capsicum/CloudABI on Linux. And the dynamic mechanism alone is a dubious way to do something as security-critical as that.

Emulating Windows system calls, take 2

jezuch — Fri, 31 Jul 2020 08:03:16 +0000

You're a subscriber so I guess it's forgiven ;) (also, this was IMO a genuine question im quest of understanding, not a typo report)

Emulating Windows system calls, take 2

jeremy — Mon, 27 Jul 2020 04:18:01 +0000

Thanks, it looks like I clearly misread the article. Not only that, but I evidently didn’t read the guideline in the comment posting section saying:

> Please do NOT post typos in the article as comments, send them to lwn@lwn.net instead.

That’s a double whammy on me for my first ever LWN comment. Please excuse me while I crawl inside my shame cube...

Emulating Windows system calls, take 2

mjg59 — Mon, 27 Jul 2020 01:29:12 +0000

No, the binaries call directly into the Windows kernel. The goal is to be able to intercept those calls in order to run the binaries on Linux.

Emulating Windows system calls, take 2

jeremy — Mon, 27 Jul 2020 01:18:19 +0000

> As a reminder, the intent of this work is to enable the running of Windows binaries that call directly into the Windows kernel without going through the Windows API.

I think you meant to say "Linux kernel" here?

Emulating Windows system calls, take 2

nix — Fri, 24 Jul 2020 22:08:50 +0000

It did -- but this wasn't done the way (say) Solaris did it, by piling the entire threading abstraction into the kernel and complicating the bejeezus out of everything. Instead we got away with a few relatively simple and noninvasive things: thread groups, a bit of tweaking to signal handling (which was painful, sure, but much less painful than almost everything else around signal handling already was and is), futexes, and some nice souping up to PID allocation so you could have silly numbers of them.

(And a good few of those abstractions were, I vaguely recall, there *already*, and used by LinuxThreads: tgids, for instance. I'm sure futexes were new for NPTL though.)

Emulating Windows system calls, take 2

BenHutchings — Thu, 23 Jul 2020 21:02:25 +0000

This is not what happened with threads. The kernel APIs that supported LinuxThreads were not sufficient to build a compliant POSIX threads implementation. The New POSIX Threads Library (NPTL) that eventually replaced LinuxThreads required additional kernel APIs.

Emulating Windows system calls, take 2

clump — Thu, 23 Jul 2020 16:20:01 +0000

> Android completely isolates applications from each other. One application cannot see/access the data of another.

Unless the storage permission is required which makes the external storage a free-for-all. I trust you'd agree that there's plenty of valuable application and user data on the external storage.

Great points about a traditional desktop environment. An exploit or hostile application shouldn't allow the compromise of a user's entire home directory by default. We can and should do better.

Emulating Windows system calls, take 2

pizza — Thu, 23 Jul 2020 14:47:21 +0000

> Android's additional security features are meaningless in practice.

Incorrect.

Android completely isolates applications from each other. One application cannot see/access the data of another.

> However the security features of Android are useless if the user has no choice but to accept all or none of an application's permissions.

That sounds like a problem brought on by using proprietary software, not the underlying permission/security model.

Android's model requires those permissions to be explicitly stated and granted, which is a huge step forward from the free-range model of a traditional desktop environment (Linux or Windows or whatever) -- where applications have carte blanche to do pretty much whatever they want -- including audio, video, networking, and access to every file the user has.

Emulating Windows system calls, take 2

clump — Thu, 23 Jul 2020 13:59:34 +0000

You're right about typical distributions. However the security features of Android are useless if the user has no choice but to accept all or none of an application's permissions. Some Android applications allow users to disable some permissions, while some applications fail to function at all unless you accept everything. Worst of all you have no choice whatsoever about which applications can use networking.

Android's additional security features are meaningless in practice.

Emulating Windows system calls, take 2

nix — Thu, 23 Jul 2020 13:53:43 +0000

Threads were added the same way, and the result was eventually a best-in-class threading implementation which does not fill the kernel with complexity related to one specific threading model. Seems like a good approach to me too (though if you'd asked me back in the year 2000 when LinuxThreads was the only threading implementation out there, I might have said something different!)

Emulating Windows system calls, take 2

nix — Thu, 23 Jul 2020 13:51:52 +0000

> Can you forward any specific security concerns that are not already mitigated to the original thread? We definitely want to have a good look at any security implications of this feature. I expect that most issues would be mitigated by making it unable to cross fork/exec boundaries.

Quite. This has no more security implications than a signal handler (to which it is very similar), so as long as it takes the same approach (reset signal handlers on address space reset at exec() time) we should be fine. Sure, if you use this mechanism *wrong* all sorts of things can happen, but the same is true of signal handlers and indeed of general bugs in code. The implications are no worse, except that making a mistake here is more likely to be obvious because it will probably break the program's use of lots of syscalls at once :)

Emulating Windows system calls, take 2

domenpk — Thu, 23 Jul 2020 10:22:24 +0000

What you write is valid criticism, but it's not a comparison in any sort of way.

What's the permission system on common Linux desktop like? Most "apps" are running under same UID, have access to all the data users actually care about, many peripherals etc.

Emulating Windows system calls, take 2

Funcan — Tue, 21 Jul 2020 13:28:05 +0000

I'd say that they're implementing 'personalities' the same way they did containers - provide the facilities known needed right now, and let anybody built a 'product' around them - adding new feature as needed. This allows multiple parallel efforts at producing a 'product' and iteration, rather than trying to design everything in advance, which history suggests works badly.

Emulating Windows system calls, take 2

Jandar — Tue, 21 Jul 2020 11:33:52 +0000

> The article is about emulating Windows system calls, so non-Android Linux phones are nothing but offtopic.

So either Android and non-Android Linux phones are off topic (regarding the article). But not the criticized post had started to write about them but the parent-post and reacting to existing topics in a discussion can't be off topic relating to the discussion. It can be off topic regarding the parent article but calling a direct response to something mentioned in another comment "spamming" is dishonest.

Emulating Windows system calls, take 2

rvolgers — Tue, 21 Jul 2020 09:36:51 +0000

Not really, as the proposed mechanism clearly puts the emulated system calls at a performance disadvantage vs native Linux system calls.

Emulating Windows system calls, take 2

plugwash — Mon, 20 Jul 2020 20:03:59 +0000

> It's, indeed, better out of the kernel. So a fuse-like API for personalities :)

This leads to the question that if a "personality" is going to be implemented in userland should it be implemented in the same process as the foreign code or a separate process.

There are pros to both approaches.

Pros of same process:

* The performance cost of switching context between processes is avoided.
* The emulation code can easily access data belonging to the foreign code through pointers
* For a foreign platform (like windows) where the "normal" interface is defined as a library ABI, not a syscall ABI most calls don't have to go through the emulation process at all.

Pros of separate process

* The foreign code cannot deliberately or accidentally mess with the emulation code.
* The foreign code can use the address space however it needs (wine has to use some fairly dirty tricks to allow non-relocatable windows binaries to be loaded in the required location)
* There is no need for a special mechanism to switch back and forth between regular syscall mode and foreign syscall mode.
* The system could potentially be used for security sandboxing as well as foreign code support.

Emulating Windows system calls, take 2

zdzichu — Mon, 20 Jul 2020 19:53:29 +0000

The article is about emulating Windows system calls, so non-Android Linux phones are nothing but offtopic.

Emulating Windows system calls, take 2

Jandar — Mon, 20 Jul 2020 19:52:06 +0000

> Something tells me you're spamming. Your comment has nothing to do with the article, or the topic of the thread.

The parent-post said:
> Android is a privacy nightmare, has abysmal security, and keeps internals away from the user. Not very Linux-like.

So talking about non-Android Linux phones is very on topic.

Emulating Windows system calls, take 2

clump — Mon, 20 Jul 2020 13:12:34 +0000

Your comment was also quite useful in reminding myself and others that the mobile phone situation isn't hopeless. We can and should support development efforts that are more respectful toward users. The PinePhone in particular looks nice.

Emulating Windows system calls, take 2

nim-nim — Mon, 20 Jul 2020 12:35:03 +0000

All the "privacy" initiatives Google sponsored in the past years have been trying to protect Android and Chrome data both from "evil" telco operators/ FSB / CIA / whatever and "evil" users. Google documents will not call it that way, but they will dismiss any actual user control because of straw-men like social engineering… The truth is the only power Google wants to give users is the power to do things Google agrees with.

You can not understand Android or Chrome security choices if you do not acknowledge they are extensions of Google IT, and the user is outside the target security perimeter.

Emulating Windows system calls, take 2

ncm — Sun, 19 Jul 2020 23:17:39 +0000

Indeed, it is a response directly to the comment that it is a response to.

Topics do drift. That is not a bug.

Emulating Windows system calls, take 2

clump — Sun, 19 Jul 2020 19:29:12 +0000

I respectfully disagree. Security features are nice, but you have only to look at "all permissions" for nearly any application installed by default on Android. Look at Google Play Services, which includes the following mandatory permissions:

"disable your screen lock"
"have full network access"
"record audio"
"access location in the background"
"take pictures and videos"
"reroute outgoing calls"

I can't remove these permissions. I can't audit their use. I can't examine the source code. Not my idea of secure, private, or user-respecting.

If pointing out issues with Google Play Services is too easy, look at "all permissions" for other apps. There is also the matter of Android's exploit track record, and all of the well-documented issues with applications served from the official Google Play Store.

My point is that Android uses Linux but offers none of its benefits.

Emulating Windows system calls, take 2

quotemstr — Sun, 19 Jul 2020 18:17:09 +0000

WLS2 is just a VM.

Emulating Windows system calls, take 2

pebolle — Sun, 19 Jul 2020 15:28:14 +0000

Except my proposal now misses that the selector is optional. Which the article also does, knowing Jon's writing probably on purpose, to keep things readable.

Is that optional selector enough to call the interface complicated?

Emulating Windows system calls, take 2

ballombe — Sun, 19 Jul 2020 15:25:41 +0000

Does wine support WSL2 ?

Emulating Windows system calls, take 2

nix — Sun, 19 Jul 2020 12:06:35 +0000

Uh, Android has massively better security by any standard that I can think of than mainstream Linux does. Extensive custom SELinux rules, a per-app permission system, every app runs in its own Unix uid... you couldn't do this to desktop Linux without rewriting everything.

Emulating Windows system calls, take 2

pebolle — Sun, 19 Jul 2020 10:22:48 +0000

> The selector argument is a pointer to a byte in memory that provides another mechanism to toggle system-call trapping.

This tripped me over the first time I read it. It's a few paragraphs later that one learns that it's not "another" mechanism but actually the last step in this implementation of syscall trapping. So something like:

"The selector argument is a pointer to a variable that is used by the kernel to check whether system-calls should actually be trapped."

might be less confusing.

Emulating Windows system calls, take 2

ldearquer — Sun, 19 Jul 2020 09:38:11 +0000

To me it certainly looks connected to the comment it replies to...

Emulating Windows system calls, take 2

gus3 — Sun, 19 Jul 2020 02:45:04 +0000

Something tells me you're spamming. Your comment has nothing to do with the article, or the topic of the thread.

Emulating Windows system calls, take 2

ncm — Sun, 19 Jul 2020 01:24:50 +0000

Maybe it is a good time to start watching efforts to make a platform to run Postmarket or Mobian phone OSes, such as Librem 5 and, especially, PinePhone, and maybe to participate in getting them ready for wider use, or set up recurring donations.

You might start with reducing dependence on Signal, moving to the Matrix/Element end-to-end encrypted message infrastructure, which has proven to be more portable to different platforms.

Maybe pre-order a PinePhone for $200. (Hint: if you do, make sure the phone is the only thing in the shopping cart. Order other stuff separately.)

I have no affiliaton with Pine or Purism, besides outstanding orders.

Emulating Windows system calls, take 2

clump — Sat, 18 Jul 2020 23:00:26 +0000

It might be fun if Microsoft used Linux more. Linux is already well-represented in Azure workloads. That said, "the cloud" is where operating systems are often viewed as commodities.

I have an Android phone because it uses Linux. I can't say I'm happy with it. Android is a privacy nightmare, has abysmal security, and keeps internals away from the user. Not very Linux-like.

Microsoft could do more with Linux but if the experience turns out like Android, I wouldn't be interested.

Emulating Windows system calls, take 2

meyert — Sat, 18 Jul 2020 20:40:16 +0000

This could probably replace the current UML mechanism, not sure if something is gained so...

Emulating Windows system calls, take 2

smcv — Sat, 18 Jul 2020 17:45:16 +0000

> I have a profound distrust in anything that runs under Windows. Not that I trust blindingly softwares that runs on Linux, but I've seen so many malware hidden in documents, images and vulnerabilities even in windows softwares made by "security" teams

Wine is already not a security mechanism. If you want to run Windows software with lower privilege than your normal login account, you'll need to run Wine in a less-privileged environment using container namespaces, LSMs and/or seccomp (for example a Flatpak, Snap or Docker container), as a separate uid, or in a virtual machine.