Wine e le applicazione per Windows

Rispondi
Avatar utente
openresource
Administrator
Administrator
Messaggi: 382
Iscritto il: mar gen 28, 2020 9:52 pm
Reactions score: 4
Località: varese
Contatta:
giu 2020 11 05:12

Wine e le applicazione per Windows

Messaggio da openresource

Immagine

Le moderne applicazioni Windows, infatti, eseguono le istruzioni per le chiamate di sistema direttamente dal codice dell’applicazione, senza passare per WinAPI. Questo crea problemi a Wine, poiché non ha la possibilità di intercettare ed emulare queste syscall, prima che vengano inviate a Linux.
Si rende necessario, quindi, una sorta di filtro che permetta di intercettare le syscall, evitando così che sia Wine direttamente a pensarci, causando enormi problemi di performance. La soluzione proposta si concentra sul modulo SECCOMP del kernel, permettendo l’isolamento delle chiamate di sistema basandosi sulle aree di memoria.

TESTO ORIGINALE:

Modern Windows applications are executing system call instructions
directly from the application's code without going through the WinAPI.
This breaks Wine emulation, because it doesn't have a chance to
intercept and emulate these syscalls before they are submitted to Linux.

In addition, we cannot simply trap every system call of the application
to userspace using PTRACE_SYSEMU, because performance would suffer,
since our main use case is to run Windows games over Linux.  Therefore,
we need some in-kernel filtering to decide whether the syscall was
issued by the wine code or by the windows application.

The filtering cannot really be done based solely on the syscall number,
because those could collide with existing Linux syscalls.  Instead, our
proposed solution is to trap syscalls based on the userspace memory
region that triggered the syscall, as wine is responsible for the
Windows code allocations and it can apply correct memory protections to
those areas.

Therefore, this patch reuses the seccomp infrastructure to trap
system calls, but introduces a new mode to trap based on a vma attribute
that describes whether the userspace memory region is allowed to execute
syscalls or not.  The protection is defined at mmap/mprotect time with a
new protection flag PROT_NOSYSCALL.  This setting only takes effect if
the new SECCOMP_MODE_MEMMAP is enabled through seccomp().

It goes without saying that this is in no way a security mechanism
despite being built on top of seccomp, since an evil application can
always jump to a whitelisted memory region and run the syscall.  This
is not a concern for Wine games.  Nevertheless, we reuse seccomp as a
way to avoid adding a new mechanism to essentially do the same job of
filtering system calls.

  • Why not SECCOMP_MODE_FILTER?



We experimented with dynamically generating BPF filters for whitelisted
memory regions and using SECCOMP_MODE_FILTER, but there are a few
reasons why it isn't enough nor a good idea for our use case:

  1. We cannot set the filters at program initialization time and forget
    about it, since there is no way of knowing which modules will be loaded,
    whether native and windows.  Filter would need a way to be updated
    frequently during game execution.

  2. We cannot predict which Linux libraries will issue syscalls directly.
    Most of the time, whitelisting libc and a few other libraries is enough,
    but there are no guarantees other Linux libraries won't issue syscalls
    directly and break the execution.  Adding every linux library that is
    loaded also has a large performance cost due to the large resulting
    filter.

  3. As I mentioned before, performance is critical.  In our testing with
    just a single memory segment blacklisted/whitelisted, the minimum size
    of a bpf filter would be 4 instructions.  In that scenario,
    SECCOMP_MODE_FILTER added an average overhead of 10% to the execution
    time of sysinfo(2) in comparison to seccomp disabled, while the impact
    of SECCOMP_MODE_MEMMAP was averaged around 1.5%.

Indeed, points 1 and 2 could be worked around with some userspace work
and improved SECCOMP_MODE_FILTER support, but at a high performance and
some stability cost, to obtain the semantics we want.  Still, the
performance would suffer, and SECCOMP_MODE_MEMMAP is non intrusive
enough that I believe it should be considered as an upstream solution.[/color]

Immagine
Rispondi