xllify – Things you need to know about XLL add-ins

Things you need to know about XLL add-ins

XLL add-ins are native Windows binaries that load directly into Excel. They offer significant advantages for calculation-heavy workbooks but come with trade-offs you should understand before distributing them.

XLLs built with xllify cannot be malicious Unlike traditional XLL development, where authors write arbitrary C/C++ code with full system access, the only code that varies between xllify builds is your function code, and that code runs inside a locked-down sandbox with no ability to access files, the network, the registry, or any other system resource. The xllify runtime is the same trusted, read-only binary in every build. There is no mechanism to break out of the sandbox or inject native code through xllify.

Huge advantages, great success

Performance. XLLs run as native code inside Excel's process. They support multithreaded recalculation (MTR). There is no browser layer, no JavaScript overhead, and no cross-process marshalling. XLLs also support multi-threaded recalculation, so Excel can evaluate your functions across multiple cores simultaneously. For workbooks with thousands of formula calls this makes a real difference.
No server required. An XLL is a single file. Drop it into Excel and your functions are available immediately. No web hosting, no localhost dev server, no manifest to sideload.
Sandboxed function code. Your function code runs inside a proven sandboxed VM with no access to the network or file system. Even if a function contains a bug, it cannot read files, make HTTP requests, or otherwise interact with the system. This is the same sandbox used in production by Roblox to run untrusted code from a huge community of developers.
Offline. Once installed, an XLL works without any network connection.

Things to be aware of

Windows only. XLLs are native Windows DLLs. They do not work on macOS or Excel for the web. If you need cross-platform support, use the Office Add-in build instead, or build both and check the XLL-compatible checkbox when building (coming soon).
Native code trust model. Although your Luau function code is sandboxed, the XLL runtime itself is a native binary that Excel loads into its process. Windows and Excel treat unsigned native binaries with caution. Users will see security warnings, and some organisations block unsigned DLLs entirely.
IT policies. Many corporate environments restrict which add-ins can be loaded. Check with your IT department before distributing an XLL internally.
XLL blocking. Recent versions of Excel block untrusted XLL add-ins by default. Users may need to unblock the file or adjust their Trust Center settings before the add-in will load. See Microsoft's guide to unblocking XLL add-ins for instructions.

Code signing

Code signing is the single most important step you can take before distributing an XLL. A signed binary tells Windows and your users that the file comes from a known publisher and has not been tampered with. Without a signature:

Windows SmartScreen may block the file entirely.
Excel will show a security warning every time the add-in is loaded.
Group Policy and endpoint-protection tools may quarantine the file.

XLLs built by xllify are currently downloaded unsigned. You can sign them yourself using a code-signing certificate before distributing them. Microsoft's Azure Trusted Signing is a straightforward and affordable option. You can also use a traditional code-signing certificate with signtool.exe from the Windows SDK.

Built-in code signing from within xllify is on our roadmap. In a future release you will be able to sign your XLL builds directly, without needing to run a separate signing step.

xllify XLLs cannot be malicious

XLLs built with xllify are in a completely different category from the malicious XLLs that have historically been used as an attack vector. Those XLLs contained arbitrary native code written by the attacker. xllify does not allow that. Your function code is bytecode running in a VM that has no access to anything outside of Excel cell values.

The sandbox in detail

xllify compiles your function code to Luau bytecode. Luau is a language derived from Lua, designed from the ground up for safe sandboxed execution and is trusted by Roblox to run untrusted code from a huge community of developers. The xllify runtime deliberately does not expose any file-system, network, or OS APIs to the scripting environment. Your function code can perform calculations, manipulate strings and tables, and return results to Excel. Right now, nothing more. In the future, a sensible set of opt-in entitlements such as HTTP GET will be permitted to allow-listed domains.

This means that even if you install an XLL from a source you are less familiar with, the custom function code inside it cannot exfiltrate data or modify your system. The security boundary you are trusting is the xllify runtime (that is, us, Lexvica Limited) and the Roblox-sourced VM, not the individual function author. We will provide a simple verification tool to assert as to whether the runtime XLL has been tampered with in a candidate xllify XLL.