We already have all the structs and constants for async I/O, and the
various functions of x/sys/windows take the right parameters. But we're
missing the final step of any ordinary async I/O routine: getting the
result of overlapped I/O. Without this, the rest of the plumbing
supported by this module isn't actually so useful. So add this small
oversight.
Change-Id: I0ce1a71bce06bc81a83f3b0ca10ad9c4b67af726
Reviewed-on: https://go-review.googlesource.com/c/sys/+/168521
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The previous selection was a bit haphazard, and defining random
constants in an application and combining those with existing constants
in this library looks kind of weird. So instead let's add the actual set
of flags, instead of the strange prior assortment.
Change-Id: I6ca266cd80aa7a43e93e969e1dbb09c8c7bf12c7
Reviewed-on: https://go-review.googlesource.com/c/sys/+/168520
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The security API is already quite extensive, but for some strange
reason, this essential and useful function was left out of the initial
port. So, we add it here, along with the relevant constants and a test
case.
Change-Id: I99568703565addf15603480f11b0edafdfc1718f
Reviewed-on: https://go-review.googlesource.com/c/sys/+/167378
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The %WINDIR% variable is an odd choice and not even entirely reliable.
Since Windows 2000, there has been a specific function for determining
this information, so let's use it. It's also a useful function in its
own right for folks who want to launch system tools in a somewhat safe
way, like netsh.exe.
Updates golang/go#14959
Updates golang/go#30642
Change-Id: Ic24baf37d14f2daced0c1db2771b5a673d2c8852
Reviewed-on: https://go-review.googlesource.com/c/sys/+/165759
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
These DLLs, well advapi32.dll in particular, are vulnerable to classic
DLL directory injection attacks. The rest of x/sys/windows moved over to
the safe system loader, but apparently the svc package was forgotten.
This tidies up that oversight.
Change-Id: I330fa752cf2d49ccc5cf1bd60fb4bd612bd2b6b0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/165758
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
ARM64 does this exact same thing, and in fact this is required on
Android 9, where Bionic now only allows lstat on 32-bit platforms
Folks are running into this when using Android on Chromebooks,
which are keeping AMD64 Android alive. So, we change the AMD64
behavior to model that of ARM64.
Change-Id: Id933cc22b42ab365c12980915557bdbf88661a4d
Reviewed-on: https://go-review.googlesource.com/c/153319
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is yet another syscall that needs to be changed around for
Android's seccomp. We already do this in MIPS64 and ARM64, but
apparently forgot about AMD64.
Change-Id: I42c8a4653a55d4714dacfaf7add14012f428c992
Reviewed-on: https://go-review.googlesource.com/109835
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
By simply rearranging the logic, we avoid the overhead of a superfluous
call to getsockopt. For, if p is already non empty, there's no point
in having to check if we need to attach dummy payload. This has
performance benefits when using send/recvmsg for high speed
communications.
Change-Id: If47ab5322464aad8e6d2603a369e95327223211f
Reviewed-on: https://go-review.googlesource.com/108337
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Jason A. Donenfeld