[PATCH] advapi32: MachineGUID to have same value in WoW64
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(a)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). 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); -- 2.17.1
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(a)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);
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 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(a)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);
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(a)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);
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). 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(a)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);
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(a)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);
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(a)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);
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)?
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(a)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);
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(a)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); >
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=43189 Your paranoid android. === debian9 (build log) === error: corrupt patch at line 9 Task: Patch failed to apply
participants (3)
-
Brendan McGrath -
Marvin -
Nikolay Sivov