KVM is not accelerated by default on WSL2

The Getting started guide at fuchsia.dev is great, but I’ll use the condensed version in the README file of the Fuchsia SDK for this if you want to follow along.

If you copy and paste the commands in your terminal, they will all work except that you will get this message when attempting to run the emulator:

$ tools/ffx emu start workstation_eng.qemu-x64 --headless
Logging to "/home/ixe013/.local/share/Fuchsia/ffx/emu/instances/fuchsia-emulator/emulator.log"
Waiting for Fuchsia to start (up to 60 seconds).............................................................
After 60 seconds, the emulator has not responded to network queries.
The emulator process is still running (pid 506).
The emulator is configured to use user-mode/port-mapped network access.
Hardware acceleration is disabled, which significantly slows down the emulator.
You can execute `ffx target list` to keep monitoring the device, or `ffx emu stop` to terminate it.
You can also change the timeout if you keep encountering this message by executing `ffx config set emu.start.timeout <seconds>`.

Even if the emulator process is running, you will be able to connect to it. Notice this message:

Hardware acceleration is disabled, which significantly slows down the emulator.

You see this for two reasons:

1. Your account does not have permission on /dev/kvm
2. Hardware acceleration is not enabled

The Fuchsia instructions to enable VM acceleration on Linux don’t work in WSL2, we are going to fix that.

Enable hardware accelerated emulation in WSL2

Grant yourself rights to the KVM

First of all, make your user a member of the kvm group with this command. It is the same command that you would do in Linux.

sudo usermod -a -G kvm ${USER}

Unfortunately - for a reason I don’t understand - /dev/kvm will always have root:root as its owner and primary group. To change that you must chmod at startup. Add the following section to the file /etc/wsl.conf:

[boot]
command = /bin/bash -c 'chown -v root:kvm /dev/kvm && chmod 660 /dev/kvm'

Enable nested virtualization

Nested virtualization is not enabled by default in WSL2, at least not in version 21H2 (OS build 22000.1165). You don’t need to recompile your WSL distribution to enable nested virtualization, just add this section to your /etc/wsl.conf:

[wsl2]
nestedVirtualization=true

Restart WSL2

You need to restart WSL2 for the changes to take effect. You can also restart your computer, but it is faster to close every terminal window and run the following command (using the Windows Key + R, or in an existing Powershell or CMD prompt):

wsl.exe --shutdown

Trying it out

From that point on, you are done! Open a new terminal window to start WSL2 under its new configuration and just follow the Fuchsia emulator startup instructions as if your were using Linux on bare metal.

$ tools/ffx emu start workstation_eng.qemu-x64 --headless
Logging to "/home/ixe013/.local/share/Fuchsia/ffx/emu/instances/fuchsia-emulator/emulator.log"
Waiting for Fuchsia to start (up to 60 seconds)...................................
Emulator is ready.

Enjoy!

This Windows batch file will parse Subversion’s svn up output and show you what files were modified, but also what files should be added.

It looks for C++, C, H, PHP, Python, Java and then some. You can easily add your own to the list.

To use simply call localfiles.bat from any versionned directory. Anything you add to the command line will be passed along to svn up. Try these variations :

• localfiles.bat -u to see potential update conflicts.

• localfiles.bat c:\the\path\to\my\project\sources works, you can run the command from anywhere

• localfiles.bat --ignore-externals or any other Subversion command you can think of

In the sample output (below) you will see

• New Source Files are source that were added (localy) but never comitted.

• Modified Source Files are source that are under source control and were modified locally.

• Unversioned Source Files are source that probably should be under source control.

• Each file is listed, with (no source file) if it looks ok.

$ localfiles.bat C:\Users\Guillaume\src\Projects\aucun.selfserve

Gathering data...

======================================
 New sourcefiles
======================================
(none found)

======================================
 Modified sourcefiles
======================================
M       C:\Users\Guillaume\src\Projects\aucun.selfserve\GINA\SecurityHelper.cpp
M       C:\Users\Guillaume\src\Projects\aucun.selfserve\GINA\loggedout_dlg.cpp
M       C:\Users\Guillaume\src\Projects\aucun.selfserve\common\Trace.c
M       C:\Users\Guillaume\src\Projects\aucun.selfserve\GINA\GinaHook.c

======================================
 Unversioned files
======================================
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\GINA\StaticPrompt.cpp
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\shellie\shellie_p.c
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\shellie\dlldata.c
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\shellie\shellie_i.c
?       C:\Users\Guillaume\src\Projects\aucun.selfserve\shellie\shellie.h

Here is the file. I gave it a txt extension, in case you are behing a paranoïac corporate proxy.

J’ai eu à changer ce mot de passe et j’ai bloqué longtemps sur le problème suivant. Et non, je n’ai pas essayé de contacter le support technique à ce sujet, des plans pour qu’ils me demandent de formatter mon PC.

En fait, c’est tout simple. Lorsque vous entrez votre mot de passe dans ce formulaire les majuscules sont converties en minuscules, tout simplement.:

Je me suis douté de quelque chose quand les mots de passe générés par Password Safe ne fonctionnais pas, mais les blasphèmes et insultes marchait tout le temps… Pas de majuscules !

Alors allez vous choisir un nouveau mot de passe SMTP, tout en minuscules. Nous savons tous qu’il n’a pas changé depuis 5 ans au moins !

The activation feature itself is not totally broken, it is just that the key supplied is not recognized as a valid one. I don’t know what makes up a valid activation key, but there an easy workaround that might work for you.

Use the activation key of an old computer.

That’s it. No need for any Virtual Box plug-ins and what not. Any activation key that is on any computer that still have their Windows XP sticker, but don’t need it anymore. Maybe you installed Linux on that old desktop that was getting a little slow ? I used the license that came with had a Dell D430 on which I installed my Partner license for demonstration purposes.

From my experience, it looks like Windows XP is less fussy about Windows SKU numbers than Windows 7 is. YMMV.

Fortunately, I had set up LSASS to run under ntsd, which was connected to a remote Windbg.

To edit the registry of a remote machine running under a debugger :

1. Break into the debugger. This step will happen naturally in most snafu

2. Start a shell with the .! command

3. Fix the registry with the command line reg.exe tool. For example, to restore authentication packages type

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Authentication packages" /t REG_MULTI_SZ /d msv1_0

1. Type exit to quit the shell (hit Enter enough times to get back to Windbg’s prompt)

Then use the g command to resume execution.

As a side note : The windows subsystem is fully loaded before LSASS.exe starts, or at least there is enough of it to launch CMD.exe and REG.exe.

• Every time you type CTRL-ATL-DEL, a new LogonUI process is launched.

• LogonUI will try to load any registered Credential Providers COM objects.

• You can run any process on the secure desktop

With that knowledge, it is easy to set up a debugging session for your Credential Provider, right on your development machine. Before I continue, be aware that it might affect the stability of your computer temporarily, as the following illustration shows.

To debug your credential provider, you will need this :

• A CredentialProvider that can be loaded by LogonUI

• Microsoft’s Debugging Tools for Windows

• Microsoft’s psexec tool (of Sysinternals fame)

I guess you could also use Visual Studio instead, ymmv. If it works, please drop us a line in the comments.

To start debugging, here is what you have to do:

1. Start a command shell on the Secure Desktop with this command:

psexec -dsx cmd.exe

1. Build a debug version of your Credential Provider and register it.

2. Type CTRL-ALT-DEL to switch to the secure desktop. That will also launch LogonUI.exe

3. Hit Alt-Tab to switch to the command prompt you started at step 1

4. Change to the directory where your source code is

5. Debug LogonUI.exe and set the source path at once, with this command :

windbg –pn logonui.exe –srcpath %CD%

That’s it. You might not be very familiar with windbg, so here are a few tips to get you started:

• When you attached to LogonUI at step 6, the process is stopped. You can enter commands to set breakpoints before resuming it.

• Verify that your Credential Provider is loaded with the lm command. Look for a string like this one:

000007fe`f5e80000 000007fe`f5e9b000 SampleCredentialProvider (private pdb symbols)

• Just to be sure, verify that a specific symbol is loaded with this command (you should get an address):

x SampleCredentialProvider!CSampleProvider::SetUsageScenario

• Set a breakpoint to the same location with this command:

bu SampleCredentialProvider!CSampleProvider::SetUsageScenario

• Resume LogonUI with the g command.

You can now lock your workstation and try to unlock it. When LogonUI appears to freeze, ATL-TAB to the debugger. It should be waiting for you with the source file loaded, waiting for your instructions. Type g to resume. Complete the unlock procedure to end LogonUI.

To reattach to logon UI, you can quit windbg and launch it again, but it is easier to list the process with the .tlist command (LogonUI.exe will be the last in the list). Attach to it again with .attach 0n2331 (replace with your PID).

Happy debugging !

Image credits : http://www.123rf.com/photo_6015610_idiot-saws-branch.html

Microsoft new architecture is better, but the separation it enforces makes it hard to play tricks with the security policy. First, there are no shortcuts with Credential Providers. The documentation is formal :

CredentialProviders are not enforcement mechanisms. They are used to gather and serialize credentials. The Local Authority and Authentication Packages enforce security.

So we have to use an authentication package with the credential provider. Nothing that we didn’t see coming. I have played with authentication packages before, it just a matter of writing one.

Second, LogonUI will not kill another user’s session. I am able to get a credential provider tile on the unlock screen, logon with administrator credentials, but then I get this error message :

This computer is locked. Only the logged on user can unlock the computer.

Which makes some sense: why kill (or unlock) a user’s session if you can just start a new session next to it ? Unfortunatly, it does not help the most common use case my custom GINA users need to solve: many users need to access a single application running in a single session.

But I haven’t given up yet.

I tested on Windows 7 Ultimate 64bits, with or without fast user switching. If you ever able to unlock another user’s session, write a line in the comments. I would love to hear about it.

A custom Gina runs in Winlogon’s process. It runs under the SYSTEM account, in the TCB… In short it can do pretty much anything. But some things just can’t be done, no matter what rights you have.

Fortunately, there is an easy way to tell if a GINA can do what you need it to do, without having to write a single line of code.

The trick is to launch a cmd.exe shell (or whatever shell you prefer) on the Winlogon desktop. I used to work with EnumWinStaGui, but Microsoft’s own psexec (of Sysinternals fame) is easier to use.

To run a cmd shell on Winlogon desktop, do the following :

1. Logon with an account with administrator rights

2. Open a command prompt (elevated if you are on Vista or later)

3. Type this command :

psexec –dsx cmd.exe

That’s it ! You will not see your shell, because it is running on the current desktop. To verify that it works, hit CTRL-ALT-DEL and your command prompt will be there. On Vista and later, it will be hidden under the full screen logon application (logonui.exe). Just ALT-TAB to it. That shell will keep running even if you log out, because it is not tied to the interactive session you used to start it. From that command line on the secure desktop, launch whatever command you need to confirm that what you want to do can be done.

For example, say you need to launch a process that will notify a web application just before the password is validated, maybe to start a timekeeping application. Can it be done ? Yes. On the command line running on the secure desktop, type this command :

start iexplore http://www.paralint.com/

It might not work. Maybe your proxy is not set up in the SYSTEM account ? Whatever the problem may be, you need to fix it. Writing a custom Gina is a waste of time if you can’t get past this step.

Tortoise SVN is a Explorer shell extension which calls a Windows executable, TortoiseProc.exe.

To use it from the command line, simply save this batch file somewhere in your path :

@echo off 
start "" "C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:%1 /path:"%2"

Then simply call like this :

tortoise log http://src.pararlint.com/aucun/trunk

or like this

tortoise commit .

Tested on Windows with 32 and 64 bits version.

Après vérification, le terme “désosser” est bien celui qu’il faut utiliser pour désigner, en français, le reverse engineering. Malheureusement, je n’aurai peut-être pas l’occasion d’apprendre de nouveaux mots avec eux, puisque le contrat de license stipule aussi ceci :

16.6    Québec :   En regard du Québec, les parties déclarent par les présentes qu'elles exigent que cette entente et tous les documents afférents, soit pour le présent ou l'avenir, soient rédigés en anglais seulement.

Too bad !