Noah Misch <n...@leadboat.com> writes: > On Mon, Jul 10, 2017 at 10:46:09AM -0400, Tom Lane wrote: >> Shall we go for broke and also remove the ASLR-disabling patch in beta2?
> As I mentioned in my message eight hours ago, no. Ah, sorry, I'd managed to swap out that bit of info already. However, I've now gone and read the Symantec paper you pointed to. It's pretty interesting, although I think it should not be treated as gospel. For one thing, it's ten years old, and for another, it's describing the behavior of Windows Vista; one might reasonably assume that Microsoft has improved some of this stuff since then. I noted with particular interest that the PEB (Process Environment Block) location is stated to be randomized whether or not you have ASLR enabled, although apparently there are only a small number of possible locations. I wonder whether that could explain anything. If it is affecting us then the retry logic should fix it. Anyway, the point at hand is Symantec's claim that there's a global offset that normally only changes at reboot but might change at other times. I'm inclined to take that with a really large grain of salt. For instance, here's a flat denial of that from a Microsoft person: https://blogs.msdn.microsoft.com/oldnewthing/20170118-00/?p=95205 with some interesting stuff in the comments too, particularly about how Windows attempts to load DLLs at the same location in all processes so as to share page table entries. Looking at Symantec's appendix II, which is a script that claims to provoke changes in this global offset, what it's doing is creating, executing, and deleting files over and over. It seems plausible to me that Windows intends to assign a randomized address to an executable or DLL once per boot, or at least once per loading of such a file, and that what Symantec's script is doing is defeating Windows' recognition that the "same" executable is being run each time. Without games like that, the executable image would persist at the same base address, at least till it got swapped out, allowing it to appear at the same address across multiple executions. If things do work more or less like that, then it's likely that it would have no effect on us, because the continuous existence of the postmaster process would lock the PG executable as well as all DLLs loaded by the postmaster into addresses that would not change for the life of the postmaster. Under that theory, what might bite us is randomization of the PEB, stack, or heap (which are stated to be re-done every time); or some antivirus code that's doing something weird. It's entirely possible that security-oriented code might take measures to ensure that it gets mapped into different addresses in every process even though Windows wouldn't normally do that. But all of these cases would presumably yield to retry of the process launch. In short, I don't really buy that we should be afraid to enable ASLR because of this Symantec paper. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers