Wine fun #3

The icing on the cake has finally arrived!

After reversing large parts of the game code and spending a silly amount of time in a debugger, I was finally able to track down the code path that caused the game to crash on wine.
Once that was clear, it was just a matter of comparing the difference in return values when running the game directly on a windows box.

Since I just hacked up the wine source to return the value I needed, it isn't a proper fix.. but I'm hoping the wine devs can come up with a solution that is acceptable for everyone.

The bug details can be found in Bug 10832

Wine fun #2

Forgot to mention that the quick fix to solve the issue I was having, was to change the device mapping so that it doesn't have one pointing to the root of the filesystem anymore. On default wine makes a mapping for drive Z to the root of the filesystem, hence why it was able to find and open /dev/random. So the easy fix was to change the Z drive mapping in ~/.wine/dosdevices

Now I just have to find out why the game bombs out when pixel shaders are enabled...

Wine fun

Don't ask me how I came to this situation, but I was trying to run a windows game on my home server over a VNC connection. Not exactly an ideal and speedy setup, but cool to see it's possible.

However, for some reason I could start the game with wine when I was at the console of the machine, but whenever I tried to start it over a VNC connection, it got stuck in the connection phase. It first looked like a network issue, but a wireshark trace didn't show anything. It was also hard to explain why it would work locally but not remote, first thought it was due to the network load of the VNC session or some timing issue. So it was time to have a closer look at it.

First up, strace of the process showed it was very slowly reading small amounts of bytes from a certain FD. A look into /proc/<pid>/fd/<num> showed it was trying to read from /dev/random. Now we're getting somewhere.

Interesting thing about /dev/random is that it needs a source for entropy. The available entropy can be viewed from /proc/sys/kernel/random/entropy_avail. Wrote a tiny bash script to continuously display that file, which clearly showed that once the connection stage of the game was reached, the pool drained at exactly the same time as the game froze.. and then whenever the pool refilled, it was quickly drained again. So the problem was, due to working remote on the machine, too little events were generated that contributed to the pool, which blocked the process reading from the random device.

Starting some heavy disk activity, showed that this was indeed the issue, because as soon as I did that, the game continued.

Next step was finding out why wine used /dev/random instead of /dev/urandom. However, a quick grep through the source didn't show any location where this would crop up in my situation. Weird.

Next idea was trying to see what the game was trying to open exactly. Luckily wine has some pretty nice debug infrastructure, so after playing with WINEDEBUG a bit. I found that the game was issuing a CreateFileA() with "/dev/random" as file name, which doesn't work on windows of course. A double check in the game executable shows that it does indeed just that:

.text:0042C150 sub_42C150 proc near
.text:0042C150
.text:0042C150 arg_0 = dword ptr 8
.text:0042C150 arg_4 = dword ptr 0Ch
.text:0042C150
.text:0042C150 push esi
.text:0042C151 push offset aRb ; "rb"
.text:0042C156 push offset aDevRandom ; "/dev/random"
.text:0042C15B call _fopen
.text:0042C160 mov esi, eax
.text:0042C162 add esp, 8
.text:0042C165 test esi, esi
.text:0042C167 jz short loc_42C185
.text:0042C169 push 0 ; size_t
.text:0042C16B push 4 ; int
.text:0042C16D push 0 ; char *
.text:0042C16F push esi ; FILE *
.text:0042C170 call _setvbuf
.text:0042C175 add esp, 10h
.text:0042C178 test eax, eax
.text:0042C17A jz short loc_42C189
.text:0042C17C push esi ; FILE *
.text:0042C17D call _fclose
.text:0042C182 add esp, 4
.text:0042C185
.text:0042C185 loc_42C185:
.text:0042C185 xor eax, eax
.text:0042C187 pop esi
.text:0042C188 retn
.text:0042C189 ; ---------------------------------------------------------------------------
.text:0042C189
.text:0042C189 loc_42C189:
.text:0042C189 mov eax, [esp+arg_4]
.text:0042C18D mov ecx, [esp+arg_0]
.text:0042C191 push edi
.text:0042C192 push esi ; int
.text:0042C193 push eax ; int
.text:0042C194 push 1 ; int
.text:0042C196 push ecx ; void *
.text:0042C197 call sub_436C04
.text:0042C19C push esi ; FILE *
.text:0042C19D mov edi, eax
.text:0042C19F call _fclose
.text:0042C1A4 add esp, 14h
.text:0042C1A7 mov eax, edi
.text:0042C1A9 pop edi
.text:0042C1AA pop esi
.text:0042C1AB retn
.text:0042C1AB sub_42C150 endp

It's still not clear why this is done in the game, might be a check for linux (although the game is only available on windows) or maybe it's some old left over code that they forgot to remove. Who knows.

Anyway seems that the fact that wine supports unix file names transparently has caused issues in other places too

FUD Factory in Full Force

Looks like microsoft aficionados are at it again: Intel CPU cache poisoning: dangerously easy on Linux

While it's true it's fairly easy to manipulate the MTRR registers on Linux. You still need to write the actual SMM code to execute and I'm sure anyone able to do that, will be able to download an example windows device driver and add some MTRR manipulation instructions to it. Either way, both Linux and Windows are vulnerable to this.. since it's not an OS issue.

As for the comments on that post.. if the virtualization layer you're using allows a virtual machine to manipulate the MTRR registers, you have bigger things to worry about!

It's a pity sites like Heise online already picked up on this.

Speeding up SSH connections

If you make alot of connections to the same host, it's worth setting up connection sharing in OpenSSH. You can enable this by adding the following to you $HOME/.ssh/config file:

Host *
ControlMaster auto
ControlPath ~/.ssh/%r@%h:%p

Do keep in mind that the 'master' will linger on until all slave connections are gone.

Boot failure

After the lastest kernel update on fedora, my box refused to boot since it was unable to mount the root filesystem. The old kernel still booted fine. My first thought was an issue with the initrd, so I first rebuild it to see if that resolved it. No change.
Therefor it was time to take a closer look.. after unpacking the initrd, I noticed the mkrootdev line was different.. and that's when I recalled that I had updated my /etc/fstab root entry and had added 'relatime' to the mount flags.
Apparently mkrootdev was failing on that flag. I'd figure it would be a simple thing to fix, so I checked out the repository and noticed it was fixed in version 6.0.76-1 (fedora 10 uses 6.0.71):

commit e993db4b1790d0328fcd76c0fd88ca2a82a931d5
Author: Jayson King
Date: Wed Feb 4 21:11:54 2009 +0100

Make nash mount support relatime (#296361)

Make nash mount support relatime (#296361).

Ubuntu: saslauthd internal error in k5support_verify_tgt

When trying to get LDAP simple bind to work against Kerberos5 with saslauthd, I kept running into the following error:

saslauthd[29808]: auth_krb5: k5support_verify_tgt
saslauthd[29808]: do_auth : auth failure: [user=kvo] [service=ldap] [realm=LOCALREALM] [mech=kerberos5] [reason=saslauthd internal error]

a search for the error only mentioned adding the host principle to the keytab file, which I had done, but I was still getting the error.

It seems saslauthd on ubuntu requires that KRB5_KTNAME is set... even though /etc/krb5.keytab is the default, it still needs the environment variable to be present. (explicitly setting the default keytab in /etc/krb5.conf didnt help either).

So the solution to the problem is to add:

export KRB5_KTNAME=/etc/krb5.conf

to the /etc/default/saslauthd file.