[PATCH] advapi32: MachineGUID to have same value in WoW64

Brendan McGrath brendan at redmandi.com
Wed Oct 17 00:34:49 CDT 2018 

You're right. I guess I wasn't expecting it to be an application 
developers responsibility to use the 'KEY_WOW64_64KEY' flag when 
accessing 'HKLM\Software\Microsoft\Cryptography' unless:
a) 'HKLM\Software\Microsoft\Cryptography' was created after the advent 
of 64bit windows; or
b) Microsoft doesn't care about breaking legacy 32bit apps

I had also been testing with a Mono app that worked when compiled as 
both 32bit or 64bit. I was thinking it was Windows taking care of the 
abstraction; but .NET must add the 'KEY_WOW64_64KEY' flag when it is 
running as a 32bit application in a 64bit environment.

When I went to test my Mono app with wine, I found I couldn't run the 
32bit variant with 'wine64'. I was getting an 'Out of Memory' error:
LdrInitializeThunk Main exe initialization for failed, "status c0000017"

My investigation found a bug in 'ntdll/virtual.c' was the cause. When 
allocating the stack it was using IMAGE_NT_HEADERS. IMAGE_NT_HEADERS is 
defined at compile time as IMAGE_OPTIONAL_HEADER32 for 'wine' and 
IMAGE_OPTIONAL_HEADER64 for 'wine64'. But it should actually be using 
IMAGE_OPTIONAL_HEADER32 for a 32-bit app whether running with 'wine' or 
'wine64'.

This resulted in an overflow and a large size being requested from mmap 
which returned an ENOMEM error.

The fix I used is pretty much a copy and paste from 'server/mapping.c' - 
so I'm not convinced it's the right solution - but I'll submit it anyway 
and await feedback.

But back on topic: my original patch is no good - but did you want me to 
submit a patch for using KEY_WOW64_64KEY when opening a key in 
CRYPT_CreateMachineGuid()?


On 16/10/18 10:13 pm, Nikolay Sivov wrote:
> On 10/16/2018 02:10 PM, Brendan McGrath wrote:
>
>> After applying the following (which is what I think you meant):
>> --- a/dlls/advapi32/crypt.c
>> +++ b/dlls/advapi32/crypt.c
>> @@ -281,7 +281,7 @@ static void CRYPT_CreateMachineGuid(void)
>>         LONG r;
>>         HKEY key;
>>
>> -       r = RegOpenKeyExW(HKEY_LOCAL_MACHINE, cryptographyW, 0, 
>> KEY_ALL_ACCESS,
>> +       r = RegOpenKeyExW(HKEY_LOCAL_MACHINE, cryptographyW, 0, 
>> KEY_ALL_ACCESS | KEY_WOW64_64KEY,
>>
>> the 32bit branch no longer exists but I now get:
>> $ wine reg query 'HKLM\Software\Microsoft\Cryptography' /v MachineGuid
>> reg: The system was unable to find the specified registry key or value
>>
>> $ wine64 reg query 'HKLM\Software\Microsoft\Cryptography' /v MachineGuid
>> HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography
>>     MachineGuid    REG_SZ e6ecce64-237e-4e28-8342-3f292975255f
>>
>> So this is not desirable either (as it also means the 32-bit Launcher 
>> I've been testing with no longer works).
>
> Yes, and that's what happens on Windows when you use 32-bit reg.exe.
>
>>
>>
>>
>> On 16/10/18 21:47, Nikolay Sivov wrote:
>>>
>>>
>>> On 10/16/2018 01:43 PM, Brendan McGrath wrote:
>>>> I agree - that would match what Windows currently does.
>>>>
>>>> But at the moment wine creates two reg entries:
>>>> [Software\\Microsoft\\Cryptography] 1539591005
>>>> "MachineGuid"="136a597b-d2a8-4b79-8d9c-d8d99a496a0e"
>>>>
>>>> [Software\\*Wow6432Node*\\Microsoft\\Cryptography] 1539591011
>>>> "MachineGuid"="ace73aff-5746-4a53-8358-795778289ed0"
>>>>
>>>> And when running 'wine' (as opposed to 'wine64') wine automatically 
>>>> uses KEY_WOW64_32KEY when accessing registry keys; thus:
>>>> $ wine reg query 'HKLM\Software\Microsoft\Cryptography' /v MachineGuid
>>>> HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography
>>>>     MachineGuid    REG_SZ ace73aff-5746-4a53-8358-795778289ed0
>>>>
>>>> returns the value from the 32bit branch (i.e. under 'Wow6432Node').
>>>>
>>>> and when running:
>>>> $ wine64 reg query 'HKLM\Software\Microsoft\Cryptography' /v 
>>>> MachineGuid
>>>> HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography
>>>>     MachineGuid    REG_SZ 136a597b-d2a8-4b79-8d9c-d8d99a496a0e
>>>>
>>>> we get the correct value from the 64bit branch.
>>>>
>>>> But this is two different values based on whether you use 'wine' or 
>>>> 'wine64' - which is definitely not right (and results in 
>>>> https://bugs.winehq.org/show_bug.cgi?id=43464).
>>>>
>>>> This patch doesn't remove the 'MachineGuid' value from the 32bit 
>>>> branch - but it does at least fix the aforementioned bug.
>>>>
>>>> Finding a solution to remove the 'MachineGuid' value from the 32bit 
>>>> branch was something I considered - but I couldn't find a precedent.
>>>>
>>>> Please let me know if there is a precedent - but if not I think our 
>>>> only option would be to intercept a get/set value request to 
>>>> "Software\\Wow6432Node\\Microsoft\\Cryptography\\MachineGuid" and 
>>>> remove the "Wow6432Node" part.
>>>>
>>>> Other alternatives that would still result in a 32bit branch value 
>>>> (but keep it in sync with the 64bit branch value) would be:
>>>> a) some kind of symlink equivalent for individual values; or
>>>> b) registry reflection
>>>>
>>>
>>> The value in 32-bit branch shouldn't exist in a first place. Like I 
>>> said, try KEY_WOW64_64KEY when opening a key in 
>>> CRYPT_CreateMachineGuid().
>>>
>>>>
>>>> On 16/10/18 19:54, Nikolay Sivov wrote:
>>>>>
>>>>>
>>>>> On 10/16/2018 11:06 AM, Brendan McGrath wrote:
>>>>>> Currently, when running the following two commands in a new prefix:
>>>>>> wine reg query 'HKLM\Software\Microsoft\Cryptography' /v MachineGuid
>>>>>> wine64 reg query 'HKLM\Software\Microsoft\Cryptography' /v 
>>>>>> MachineGuid
>>>>>>
>>>>>> Two different values are returned. This can cause an issue when, for
>>>>>> example, a 32-bit Launcher and 64-bit application expect the same 
>>>>>> value.
>>>>>>
>>>>>> This patch ensures that when the 64-bit GUID is created, the 32-bit
>>>>>> GUID is created as well (with the same value).
>>>>>>
>>>>>> Signed-off-by: Brendan McGrath <brendan at redmandi.com>
>>>>>> ---
>>>>>>
>>>>>> I considered a few options on how to achieve this; but ended up with
>>>>>> this option as it seemed the simplest. However, it does leave the
>>>>>> possiblity for an application or user to change one and leave the 
>>>>>> other.
>>>>>>
>>>>>> I did note that Windows doesn't appear to have a MachineGuid 
>>>>>> entry for
>>>>>> WoW, so it looks like Windows just uses the one entry. But I wasn't
>>>>>> sure of the best way to achieve that in Wine (and couldn't find a
>>>>>> precedent).
>>>>>
>>>>> Hi, Brendan.
>>>>>
>>>>> Thanks for the patch. Since this value should only be present in 
>>>>> 64bit branch, key should be opened with KEY_WOW64_64KEY when 
>>>>> setting it. You can't access it on Windows either, with /reg:32 
>>>>> mode, which is default for 32-bit reg.exe.
>>>>>
>>>>>>
>>>>>>   dlls/advapi32/crypt.c | 8 ++++++++
>>>>>>   1 file changed, 8 insertions(+)
>>>>>>
>>>>>> diff --git a/dlls/advapi32/crypt.c b/dlls/advapi32/crypt.c
>>>>>> index 01d58804235..0ea64b52226 100644
>>>>>> --- a/dlls/advapi32/crypt.c
>>>>>> +++ b/dlls/advapi32/crypt.c
>>>>>> @@ -313,6 +313,14 @@ static void CRYPT_CreateMachineGuid(void)
>>>>>>                           RegSetValueExW(key, machineGuidW, 0, 
>>>>>> REG_SZ,
>>>>>>                                          (const BYTE *)buf,
>>>>>> (lstrlenW(buf)+1)*sizeof(WCHAR));
>>>>>> +                        r = RegOpenKeyExW(HKEY_LOCAL_MACHINE, 
>>>>>> cryptographyW, 0,
>>>>>> + KEY_ALL_ACCESS | KEY_WOW64_32KEY, &key);
>>>>>> +                        if (!r)
>>>>>> +                        {
>>>>>> +                            RegSetValueExW(key, machineGuidW, 0, 
>>>>>> REG_SZ,
>>>>>> +                                           (const BYTE *)buf,
>>>>>> + (lstrlenW(buf)+1)*sizeof(WCHAR));
>>>>>> +                        }
>>>>>>                       }
>>>>>>           }
>>>>>>           RegCloseKey(key);
>>>>>
>>>>
>>>
>>
>

More information about the wine-devel mailing list