Implement Windows Registry as the Highest Precedence for WSL Configuration

[ssijbabu]

Summary

We propose modifying the WSL configuration loading order to introduce the Windows Registry as a third, and highest-precedence, layer of configuration. This change is necessary to support enterprise and regulated environments that require centralized and protected management of critical WSL settings.

Current Behavior

WSL settings are currently loaded in the following order of precedence (from lowest to highest):

1. Default Settings (Hardcoded platform defaults).
2. %USERPROFILE%.wslconfig (User-level configuration file, which overrides defaults).

In this scheme, any value set in .wslconfig cannot be centrally enforced or protected, as users can easily modify this file.

Proposed Behavior / Motivation

The proposed change is to introduce a third configuration layer that takes precedence over the user-editable .wslconfig file:

Proposed Loading Order (Lowest to Highest Precedence):

1. Default Settings
2. %USERPROFILE%.wslconfig
3. Windows Registry (New Highest Precedence Layer)

Motivation

In enterprise scenarios, certain configurations—such as memory limits, network settings, or security configurations—must be centrally managed and protected from user modification to maintain security compliance and system stability.

By implementing registry-based settings with the highest precedence, system administrators could use Group Policy Objects (GPOs) or configuration management tools to enforce required settings. This ensures:

• Security: Critical settings (e.g., restricted access or resource allocation) cannot be easily bypassed by changing a local file.
• Central Management: A single control point for managing settings across thousands of developer machines.
• Auditability: Enforced settings can be more easily audited via standard Windows tools.

Implementation Suggestion (High-Level)

The implementation would require updating the configuration loader within the WSL Host Service to:

1. Read all settings from the existing sources (Default, .wslconfig).
2. After reading .wslconfig, check a designated Windows Registry path (e.g., HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss\Config).
3. If a configuration key (e.g., memory, swap) exists in the Registry path, its value must overwrite any previously loaded value (including those from .wslconfig).

This would effectively create a "lock-down" mechanism for specific settings without restricting the user's ability to customize non-critical settings via their .wslconfig file.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[OneBlue]

Thank you for reporting this @ssijbabu. This is already implemented (See: https://learn.microsoft.com/en-us/windows/wsl/intune).