Experimenting with mypy and nuitka

[seanbudd]

Originally raised in #18449

Has anyone investigated NVDA with pypy or nuitka?

NVDA could see real performance gains as a compiled program with Nuitka.
However, this would make functionality like python add-ons and the NVDA python console unusable.

Given this, is there any value or interest in creating an experimental version of NVDA with Nuitka?
This could provide two sorts of benefit:

• A potentially lighter and faster form of NVDA (with compilation)
• A more restricted and secure form of NVDA (no python API)

On the other hand, people often suggest pypy as even more performant to nuitka, and this would keep the python API available.
It's not 100% clear to me why we chose cpython over pypy given the performance differences.
I know in the past there's limited support for C extensions and the language lags behind a bit (still on 3.11).
I'm not sure if it's still an issue, but I'm guessing it's fairly majorly broken with NVDA given the C extension issues.
CPython is also building a JIT compiler to rival pypy, so pypy may become redundant in future version of Python

[josephsl]

Hi, CPython is the default and most widely used Python implementation. Note that just-i-time compilation for CPython is in the works. Thanks.

[seanbudd]

Hi - yep I guess my ninja-edit did not make it before the email notification went out. The JIT compiler in cpython is fairly new, but I assume that it will eventually make mypy redundant. Also pure speculation - but I can imagine astral putting out a Rust optimized Python compiler/interpreter in the near future.
I guess this discussion might better be based around experimenting with Nuitka and cpython's JIT compiler for 3.13/3.14

[gexgd0419]

May I ask a question:

If the performance is important, why does NVDA use Python, instead of using languages such as C/C++ everywhere?

Now some of the (performance-critical) modules are already written in C/C++. But also, Windows API functions might be easier to use in C++ than in Python in some cases. Python requires you to write boilerplate code in order to use those APIs, while the Windows SDK already has C/C++ header files that have all the definitions.

One of the benefits of using a dynamic language like Python is that it's easier for add-on code to interact with anything inside NVDA, and even patch/modify NVDA's code. The add-on's code becomes essentially part of NVDA's code when loaded. Is this considered an advantage, or a "security loophole"? If the answer is the former, then the Python API should be kept.

I'm curious about the "new sandboxed add-on API" mentioned in #18449. Would they still be in Python? Would the add-ons be run in dedicated processes? Would the process permission be locked down like Chromium renderer processes?

There's actually a similar problem for 64-bit migration: 32-bit plugins cannot run in 64-bit processes, so there must be some kind of cross-process add-on API that supports this.

[gexgd0419]

I found that multiprocessing is currently excluded in setup.py, because it "isn't going to work in a frozen environment". But there's also multiprocessing.freeze_support().

By "sandbox" I think it means complete isolation, and sandboxed add-ons shouldn't be able to do things not permitted to do.

I found RestrictedPython, which can limit the modules and functions available to untrusted Python code. Basically explicitly allowlisting everything the code can call. So we can then block the calls to os and ctypes, for example, without actually tweaking the permissions - as long as there's only Python code.

If restricting process permissions is desired, we can:

• Use CreateRestrictedToken to create a restricted token
• Use SetTokenInformation with TokenIntegrityLevel to lower the integrity
• Use CreateProcessAsUser to apply the token to subprocesses
• Put the processes in a job object to restrict more things like disallowing changing display settings and preventing clipboard access
• On Windows 8 or later, we can create an AppContainer to restrict even more things such as camera/microphone access and network access. Processes running in an AppContainer cannot access any user files by default, which is safe, but can also cause problems like not able to load DLLs.

Chromium's sandbox does all of the above on renderer processes, so the sandboxed processes are only allowed to do the absolute minimum. For files they do need to access, they will have to tell the main process through IPC to get the access. This is obviously safe, but can also be a hassle to implement. Chromium's sandbox implementation is actually open-source, but I'm not sure how difficult it will be to integrate it.

So I think we need to clarify the boundary of the sandbox. Is the goal to:

• Only allow add-ons to interact with a few NVDA APIs, but absolutely nothing else, like accessing files or loading its own DLL? Then maybe RestrictedPython is enough.
• Give the add-on some freedom to load its own modules and even DLLs, but prevent the add-on from messing up the system? Then we'll have to lock down the permissions carefully.

Loading DLLs means introducing uncontrollable code, and not Python code that can be controlled by RestrictedPython. But some functionality may require loading one, such as some third-party voices.

[seanbudd]

You can view https://github.com/nvda-art/ for more info on where we are at with the project.
Note we aren't investing in public documentation yet, so it may be hard to follow.

[gexgd0419]

Thanks for making the sandbox work public.

I just skimmed through the art-sandbox.md. Seems that the sandbox is restricted in these ways:

• No admin permissions and privileges
• No shutdown privilege
• No clipboard access
• Restricted UI handle access
• Memory usage limit

But many restrictions are not enforced due to compatibility reasons. Especially, the integrity level is still Medium, the same as most other user processes. This means that the add-on can still access everything the user can access.

This does prevent the add-on from modifying the system files, but so does the UAC. This does not protect the user's files, and the add-on could still read, modify, and delete arbitrary user files as long as it's not in the protected system folders. I can repair my system installation, but if my data is lost, it's gone, unless I've backed it up somewhere else. I guess that's the reason why mobile OSes run each app under a dedicated user, and why Microsoft introduced AppContainers and Metro apps/UWPs.

But yes, I could also imagine what will happen if the permission is really locked down to the minimum like the Chromium sandbox. Many add-ons do need to access some files in other places. Even Chrome doesn't run SAPI5/OneCore voices in the sandbox, because they don't work in a sandbox (see this issue). Third-party parts are often closed-source, so it's hard to figure out what exact resources they need to access, and they are often not designed to be used under a highly restricted environment. Even Microsoft had to introduce "UAC virtualization" that redirects file/registry writes elsewhere to preserve compatibility when enforcing UAC.

So the current sandbox implementation does help, but only to some extent. It cannot stop a malicious add-on from, for example, stealing Chrome's password and cookies, or encrypting user's file for ransom. It could help preventing key loggers, for example. But, if it want to be sneaky, it can inject itself into other medium-integrity processes outside the sandbox, and escape from the sandbox easily. This means that having the same permission and integrity level as other user programs doesn't seem to be a good idea.

So, what about compatibility issues, where a third-party DLL cannot access some files?

My idea is as follows:

• Hook the functions that interacts with files, registries, etc., such as NtCreateFile. Hopefully hooking user-mode APIs is enough, since loading drivers is not allowed.
• When the sandboxed process attempts to access an inaccessible resource, use IPC to ask the main process.
• The main process would then decide to allow or deny access, based on a built-in list, or ask for user's confirmation.
• If the access is allowed, the main process opens the resource, and duplicates the handle to the sandboxed process.
• If the access is denied, report failure, or redirect writes to somewhere else.

This way, the main process can decide exactly what kind of access it will allow, based on file/registry paths.

But I think it won't be that simple, or Chrome wouldn't have given up putting SAPI5 voices in a sandbox...

[gexgd0419]

After some more inspection, it does seem to disable the user's SID, meaning that user's own data and registry keys are inaccessible by default.

If that's the case, injecting into other processes to escape the sandbox would not be possible.

SaferComputeTokenFromLevel, when using the level SAFER_LEVELID_CONSTRAINED, will create a token with a "restricted SID list" (see parameter RestrictedSidCount and SidsToRestrict of CreateRestrictedToken). The list includes all the original SIDs except disabled SIDs and the user's SID, and also has an additional "RESTRICTED" SID (S-1-5-12) in the list. A resource must grant both the user's SID and this restricted SID to allow processes with this token to access. From Microsoft's doc:

RESTRICTED_CODE (S-1-5-12): This SID is used to control access by untrusted code. ACL validation against tokens with RC consists of two checks, one against the token's normal list of SIDs and one against a second list (typically containing RC - the "RESTRICTED_CODE" token - and a subset of the original token SIDs). Access is granted only if a token passes both tests. Any ACL that specifies RC must also specify WD - the "EVERYONE" token. When RC is paired with WD in an ACL, a superset of "EVERYONE", including untrusted code, is described.

As a result, the process cannot access user's files, but can have read-only access to user's registry key in HKEY_CURRENT_USER, because the registry keys explicitly granted RESTRICTED_CODE SID read access.

[gexgd0419]

Just realized that from Windows 7 and above, the default permission setting for files and folders becomes looser, as follows:

• Administrators, Full access;
• SYSTEM, Full access;
• Authenticated Users (All users except Guest), Modify;
• Users, Read & execute.

So still, having a medium integrity but with the user SID removed cannot prevent malicious code from messing with files outside system folders and the user home directory, for example, other disk drives than C.

[gexgd0419]

I tried PyPy. Unfortunately, comtypes cannot work with PyPy. comtypes is designed to work with CPython, and relies on some CPython APIs. So if we want to use PyPy, we would have to use another COM library, or patch comtypes in some way. COM itself does work in PyPy, if you use the functionality provided by ctypes, but libraries that rely on CPython would fail.

Nuitka, on the other hand, works with comtypes, as it's fully compatible with CPython. So it might be easier to migrate to Nuitka.

Exe files compiled with Nuitka can still load external Python code files (.py) with importlib.util.spec_from_file_location(), importlib.util.module_from_spec(), and spec.loader.exec_module(). Since it can still load Python code and interact with it, what could be preventing Nuitka-compiled NVDA from exposing its full Python API?

[seanbudd]

I was not aware that nutika could expose our python API - if that's possible, moving to nuitka seems pretty feasible will full support.
Given #18449 - I think nuitka might serve as a better alternative to py2exe and pyinstaller

[gexgd0419]

I tried Nuitka, but haven't succeeded in getting it to work. I'm not that familiar with Nuitka and the NVDA's building system, after all.

The current setup.py which uses py2exe builds a list of file paths to be passed to py2exe. However, Nuitka doesn't seem to support being called directly in Python code. I tried building command line arguments, but the file list became so long that the final command line exceeded the maximum allowed command line length in Windows. So the wildcards should be passed to Nuitka without expanding.

Also, compiling would take a significant amout of time. Interestingly, some .py files in the comInterfaces folder turn out to be the most difficult to compile. For example, _C866CA3A_32F7_11D2_9602_00C04F8EE628_0_5_4.py, which is related to SAPI5. It was translated into a 16MB C code file, and compiling this could take several minutes and nearly 20GB of RAM. My computer ran out of memory because of this. But since the original Python code file is already 400KB, I guess that makes sense.

[seanbudd]

Hmm we might have to cache / pre-compile some parts of NVDA and make them more modular.

In terms of RAM have you tried --low-memory.

Does the 64bit branch compile any better?

[seanbudd]

Also relevant: https://coderslegacy.com/python/speed-up-nuitka-compilation-time/

[gexgd0419]

Even compiling _C866CA3A_32F7_11D2_9602_00C04F8EE628_0_5_4.py alone could take that much of memory. The Python file has 12,150 lines, and becomes a 395,555 lines C file for compilation...

In fact, most of the type library wrappers in it are not used at all, only a portion of it is used in the SAPI5 synth driver.

But comtypes generated wrappers for the entire SAPI5 type library, including the speech-recognition part.