Sebastian Lackner sebastian@fds-team.de writes:
This patch also replaces the memory mapping logic with ReadFile.
That's noticeably slower, any particular reason for doing this?
On 14.03.2017 20:29, Alexandre Julliard wrote:
Sebastian Lackner sebastian@fds-team.de writes:
This patch also replaces the memory mapping logic with ReadFile.
That's noticeably slower, any particular reason for doing this?
I did the change for security reasons. If the file is truncated by another process while we are computing the checksum it could lead to a SIGBUS. Nevertheless, I wouldn't really expect that it is much slower. How big is the difference in your case? If it is a problem we could increase the buffer size and/or switch to sha512, which is a bit faster afaik.
Best regards, Sebastian
Sebastian Lackner sebastian@fds-team.de writes:
On 14.03.2017 20:29, Alexandre Julliard wrote:
Sebastian Lackner sebastian@fds-team.de writes:
This patch also replaces the memory mapping logic with ReadFile.
That's noticeably slower, any particular reason for doing this?
I did the change for security reasons. If the file is truncated by another process while we are computing the checksum it could lead to a SIGBUS. Nevertheless, I wouldn't really expect that it is much slower. How big is the difference in your case? If it is a problem we could increase the buffer size and/or switch to sha512, which is a bit faster afaik.
The tiny buffer probably doesn't help, but it's about 10% slower (650ms vs. 600ms).
I have to admit I don't see a security issue here. If another process is modifying the file while we are loading it, then I don't think a SIGBUS is necessarily worse than a corrupted install.
-
Alexandre Julliard -
Sebastian Lackner