Emulating Windows system calls, take 2
Emulating Windows system calls, take 2
Posted Jul 17, 2020 19:38 UTC (Fri) by krisman (subscriber, #102057)In reply to: Emulating Windows system calls, take 2 by tnemeth
Parent article: Emulating Windows system calls, take 2
> just one single use case. Xenomai has this kind of feature (native,
> posix, ...). It could be a nice place to start looking for a similar
> architecture and do things "right" (IMHO: I'm not sure if I'm right
> ahere myself, not knowing the details :) ).
>
> Even if I'm not a particular fan of being able to run what I think is a
> bunch of ugly Windows applications, I do recognize that some (like my
> children) would like to play Windows games and I would much prefer
> running them under Linux than under Windows itself. I'm clearly afraid
> of security implications of such a mechanism.
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.
>
> But if we go there, then why not add syscall support for other OSes like
> MacOS, Haiku, whateverOS...add specific support for any platform in the kernel.
The goal is to provide an infrastructure for emulation in userspace. This means exactly that we don't need to go adding support for whateverOS in the kernel. :)
> So it is a, not-full-fledged, hiding its name, part of a skin
> mechanism. Sorry :) I like clear views, clear APIs... and grumbling a
> lot.
We try to solve most emulation issues in userspace, unless it really needs to be in the kernel (i.e. the stuff in personality(2)). I'd say to not expect a generic skin interface beyond specific features to solve pain points for userspace emulation.
But, saying we are hiding it is not fair. In fact, I called it a personality mechanism in my first submission, but we dropped that name to avoid confusion.
Posted Jul 17, 2020 21:49 UTC (Fri)
by tnemeth (guest, #37648)
[Link] (2 responses)
Of course not. This is just a /personnal fear/. I have a profound distrust in anything that runs
> The goal is to provide an infrastructure for emulation in userspace. This means exactly that we
It's, indeed, better out of the kernel. So a fuse-like API for personalities :)
> But, saying we are hiding it is not fair. In fact, I called it a personality mechanism in my first
I'm sorry, I didn't mean to be unfair. I missed that point (I do not follow LKML anymore).
Thank you for clearing my mind :)
Posted Jul 18, 2020 17:45 UTC (Sat)
by smcv (subscriber, #53363)
[Link]
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.
Posted Jul 20, 2020 20:03 UTC (Mon)
by plugwash (subscriber, #29694)
[Link]
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.
Pros of separate process
* The foreign code cannot deliberately or accidentally mess with the emulation code.
Posted Jul 23, 2020 13:51 UTC (Thu)
by nix (subscriber, #2304)
[Link]
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
>
> 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.
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 (last time I had been affected was with Cisco Webex) that I can imagine that
some ways will be explored to gain access to a Linux system through faulty Windows
programs.
> don't need to go adding support for whateverOS in the kernel. :)
> submission, but we dropped that name to avoid confusion.
Emulating Windows system calls, take 2
Emulating Windows system calls, take 2
* 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.
* 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