[PATCH] advapi32: MachineGUID to have same value in WoW64
Brendan McGrath
brendan at redmandi.com
Wed Oct 17 04:40:39 CDT 2018
On 17/10/18 5:35 pm, Nikolay Sivov wrote:
> On 10/17/2018 08:34 AM, Brendan McGrath wrote:
>
>> 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
>
> Another possibility is that they want to avoid this problem exactly,
> so you can't have different value for the "same" parameter. I don't
> really know what exactly was fixed by adding this key, if it was for
> .NET then surely they are aware of 32bit difference.
>
> Do you access this key yourself or does Mono access it (I don't
> immediately see this in their code)?
>
I'm accessing it. But I dug a bit deeper and I think when you run a
32bit mono app with 'wine64' - it just compiles the byte code in to
64bit machine code (thus the 'KEY_WOW64_64KEY' flag isn't necessary).
So the only time you can't access the
'HKLM\Software\Microsoft\Cryptography' key with a mono app is when you
compile for '32bit' and use 'wine' to execute it. If you compile for
'64bit', even if you use 'wine' to execute, it will still generate 64bit
machine code.
>>
>>
>>
>> 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()?
>
>
> Sure, I don't see why not.
>
>>
>>
>> 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