[Bug 46471] amd k10 keepass2 dotnet472 divide by zero in encryption

wine-bugs at winehq.org wine-bugs at winehq.org
Wed Jan 23 08:29:12 CST 2019


https://bugs.winehq.org/show_bug.cgi?id=46471

--- Comment #12 from noabody at yahoo.com ---
With that in mind we can build an abstract of the problem.

KeePassLibC64.dll uses SSSE3 encryption functions
KeePassLibC32.dll doesn't use SSSE3
AMD K10 lacks SSSE3


But the program works on K10 in Win64 so we'll expand:

KeePassLibC64.dll uses SSSE3 encryption functions
KeePassLibC32.dll doesn't use SSSE3
AMD K10 lacks SSSE3
KeePass.exe tries to use LibC64 and falls back to LibC32 if SSSE3 not found


Now we'll apply that to wine stable:

KeePassLibC64.dll uses SSSE3 encryption functions
KeePassLibC32.dll doesn't use SSSE3
AMD K10 lacks SSSE3
KeePass.exe tries to use LibC64
KeePass.exe falls back to LibC32 because a wine stubbed API function is not
available
Encryption is handed off to gnutls
Program executes normally


And to wine-devel/staging:

KeePassLibC64.dll uses SSSE3 encryption functions
KeePassLibC32.dll doesn't use SSSE3
AMD K10 lacks SSSE3
KeePass.exe uses LibC64 because a wine stubbed API function is available
Encryption is handed off to gnutls
gnutls returns a divide by zero


What changed between wine stable and devel with no change in keepass?  We can
surmise that a previously stubbed encryption call is now implemented.

But it's a bug in gnutls, right, that is the mechanism that handles encryption?
 It should see the SSSE3 instruction request, recognize that the CPU lacks the
instruction set, and fallback to a software only implementation.

That suggests that any given SSSE3 instruction has an identical software
function to wrap to.  Maybe there is.  Maybe the version of gnutls in Ubuntu
18.04 currently lacks the code to wrap the function call properly.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list