September 2018 - Wine-Bugs - list.winehq.org

[Bug 44902] Baidu Wifi Hotspot crashes in IShellLink:: SetIconLocation method due to missing NULL path handling

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44902 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Baidu Wifi Hotspot crashes |Baidu Wifi Hotspot crashes |inside shell32 |in | |IShellLink::SetIconLocation | |method due to missing NULL | |path handling CC| |focht(a)gmx.net -- 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.

Sept. 30, 2018

[Bug 44902] Baidu Wifi Hotspot crashes inside shell32

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=44902 Louis Lenders <xerox.xerox2000x(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --- Comment #9 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- (In reply to Nikolay Sivov from comment #8) > Please try this one, > https://www.winehq.org/pipermail/wine-devel/2018-September/133011.html. Yes, it fixes the crash (the window coming up is still black, but that is another bug) -- 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.

Sept. 30, 2018

[Bug 45910] GameGuard requires [wevtapi.dll.EvtExportLog] function

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=45910 Louis Lenders <xerox.xerox2000x(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox.xerox2000x(a)gmail.com --- Comment #1 from Louis Lenders <xerox.xerox2000x(a)gmail.com> --- Created attachment 62441 --> https://bugs.winehq.org/attachment.cgi?id=62441 patch Looks like spec file was not updated right/forgotten. Does this patch change anything? -- 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.

Sept. 30, 2018

[Bug 37355] Multiple software protection schemes need ntoskrnl ' MmMapLockedPagesSpecifyCache' implementation (Tages Protection v5.x, BattleEye's 'bedaisy.sys')

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=37355 --- Comment #32 from Richard Yao <ryao(a)gentoo.org> --- Well, my /proc/${PID}/mem idea won't work. iops->mmap is not implemented for /proc/${PID}/mem in fs/proc/base.c. In fact iops isn't implemented period. -- 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.

Sept. 30, 2018

[Bug 45889] Age Of Empire III Steam french version: tutorial crash

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=45889 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #2 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, Do the MP3 files play fine in a native(linux) audio player? And then do they play fine in a windows audio player with wine(same settings as the game)? -- 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.

Sept. 30, 2018

[Bug 37355] Multiple software protection schemes need ntoskrnl ' MmMapLockedPagesSpecifyCache' implementation (Tages Protection v5.x, BattleEye's 'bedaisy.sys')

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=37355 --- Comment #31 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Richard Yao from comment #30) > You also need to handle multiple adjacent allocations and do reference > counting. You basically get to reimplement the kernel's memory management, > which is plenty of effort to get right. The kernel does all of this for us, > so why reimplement it? We'd never have an implementation that is both fast > and correct either due to the need to stop all of the processes' threads to > copy things in a way that would match what it would normally see. The fact > that we need to copy at all would slow this down. I don't think this is as difficult as you make it out to be. It's not like we don't already do memory management anyway (see e.g. server/mapping.c). It seems to me that we'd obviously want to avoid any need for root access (or kernel patching) if possible. -- 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.

Sept. 30, 2018

[Bug 37355] Multiple software protection schemes need ntoskrnl ' MmMapLockedPagesSpecifyCache' implementation (Tages Protection v5.x, BattleEye's 'bedaisy.sys')

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=37355 --- Comment #30 from Richard Yao <ryao(a)gentoo.org> --- (In reply to Zebediah Figura from comment #26) > I think needing root privileges probably rules this approach out. Is there > anything preventing the aforementioned approach using APCs from working? To answer the APCs question, if that does what I think it does, it would be a pain to to handle MmMapLockedPagesSpecifyCache if it is invoked multiple times on the same pages such that different processes expect to share the same pages. Here is a scenario: 1. Process 2 invokes MmMapLockedPagesSpecifyCache to map pages from process 1 into itself. The two expect to share this memory. 2. Process 3 invokes MmMapLockedPagesSpecifyCache to map pages from process 2 into itself. All 3 expect to share the same memory. 3. In a naive implementation, we would copy and remap the pages on the second MmMapLockedPagesSpecifyCache call, such that process 1 will have different pages from process 3. You also need to handle multiple adjacent allocations and do reference counting. You basically get to reimplement the kernel's memory management, which is plenty of effort to get right. The kernel does all of this for us, so why reimplement it? We'd never have an implementation that is both fast and correct either due to the need to stop all of the processes' threads to copy things in a way that would match what it would normally see. The fact that we need to copy at all would slow this down. -- 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.

Sept. 30, 2018

[Bug 37355] Multiple software protection schemes need ntoskrnl ' MmMapLockedPagesSpecifyCache' implementation (Tages Protection v5.x, BattleEye's 'bedaisy.sys')

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=37355 --- Comment #29 from Richard Yao <ryao(a)gentoo.org> --- That is the last time I post to the bug tracker from a mobile device. Anyway, here is what I imagine as being possible: A tiny root daemon that opens a unix domain socket that lets programs request file descriptors from /proc. It will do some checks to see if ptrace would allow access. It could do some additional checks to further restrict things such as: 1. The program requesting it is on a white list of allowed programs by checking the /proc/$PID/exe symlink. 2. The program whose fd it requested is a decedent of it in the process tree. If all checks pass, it could open the file descriptor and send it back via the UNIX domain socket. In the case of wine, the wineserver should be able to pass those checks. wine could get a file descriptor from it to implement `MmMapLockedPagesSpecifyCache()`. -- 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.

Sept. 30, 2018

[Bug 37355] Multiple software protection schemes need ntoskrnl ' MmMapLockedPagesSpecifyCache' implementation (Tages Protection v5.x, BattleEye's 'bedaisy.sys')

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=37355 --- Comment #28 from Richard Yao <ryao(a)gentoo.org> --- (In reply to Richard Yao from comment #27) > I could see someone writing a really tiny root daemon that allows a process > to gain access to a file descriptor of a child’s address space in any case > that ptrace allows access and having the wine server talk to it. It should > be possible to do that in a secure manner. Let me reword that, it should be! I could see someone writing a really tiny root daemon that allows a process to gain access to a file descriptor of the address space of another process in any case that ptrace allows access and having the wine server talk to it. It should be possible to do that in a secure manner. ptrace allows access to every process on the system if you have root, child or non child. The same goes for processes owned by the same UNIX user if I recall correctly. It would possible to add restrictions to such a daemon to lock it down, such as allowing only descendant processes and/or processes that are certain executables though. However, those restrictions should be enough to give Wine what it needs. -- 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.

Sept. 30, 2018

[Bug 37355] Multiple software protection schemes need ntoskrnl ' MmMapLockedPagesSpecifyCache' implementation (Tages Protection v5.x, BattleEye's 'bedaisy.sys')

by wine-bugs＠winehq.org

https://bugs.winehq.org/show_bug.cgi?id=37355 --- Comment #27 from Richard Yao <ryao(a)gentoo.org> --- I could see someone writing a really tiny root daemon that allows a process to gain access to a file descriptor of a child’s address space in any case that ptrace allows access and having the wine server talk to it. It should be possible to do that in a secure manner. -- 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.

Sept. 30, 2018