Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
syscall: verify that windows uintptr structure fields are not pointers #24820
Recently #21376 (comment) we discovered that using uintptr structure fields to store pointers will confuse GC.
https://go-review.googlesource.com/#/c/go/+/106275/ converts all syscall code used by crypto/x509 package to use syscall.Pointer instead of uintptr. But there are other uintptr fields in syscall.
This issue is so we don't forget to check them all.
Some syscall structures used by crypto/x509 have uintptr fields that store pointers. These pointers are set with a pointer to another Go structure. But the pointers are not visible by garbage collector, and GC does not update the fields after they were set. So when structure with invalid uintptr pointers passed to Windows, we get memory corruption. This CL introduces CertInfo, CertTrustListInfo and CertRevocationCrlInfo types. It uses pointers to new types instead of uintptr in CertContext, CertSimpleChain and CertRevocationInfo. CertRevocationInfo, CertChainPolicyPara and CertChainPolicyStatus types have uintptr field that can be pointer to many different things (according to Windows API). So this CL introduces Pointer type to be used for those cases. As suggested by Austin Clements. Fixes #21376 Updates #24820 Change-Id: If95cd9eee3c69e4cfc35b7b25b1b40c2dc8f0df7 Reviewed-on: https://go-review.googlesource.com/106275 Reviewed-by: Austin Clements <firstname.lastname@example.org> Run-TryBot: Austin Clements <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org>
@aclements I spent some time looking at windows uintptrs in syscall package.
And the only real pointer remains is AddrinfoW.Addr (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms737529(v=vs.85).aspx for its documentation). I tried changing AddrinfoW.Addr type from uintptr into syscall.Pointer, and nothing else needs to change anywhere in standard library. We do use AddrinfoW.Addr in net package in 2 places, but we already convert all uses of it into unsafe.Pointer. Also the way we use AddrinfoW.Addr it is always set by Windows, never by us, so, while it is, probably, pointing onto Go memory, it could be treated as external memory by garbage collector. I think.
Given we already changed syscall package in CL 106275, I think we should change AddrinfoW.Addr into syscall.Pointer. But leaving this decision up to you. Let me know what you think either way. Happy to send a CL if you agree.