As of Go 1.21 syscall.Setrlimit and syscall.prlimit can affect
starting a new process, by restoring the original NOFILE rlimit.
That is recorded locally in the syscall package, so just always
call the syscall functions.
For golang/go#46279
Change-Id: I2f3dafe5562a7dde1297bad6f5d34a80af5d620b
Reviewed-on: https://go-review.googlesource.com/c/sys/+/476695
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
CL 469835 broke the syscall wrapper generation on linux and freebsd by
generating a wrapper for the inexistent SYS_PTRACE_PTR syscall. The
ptracePtr added by CL 469835 correctly uses SYS_PTRACE, likely because
it was manually edited in that CL. However, the incorrect SYS_PTRACE_PTR
syscall is used when regenerating the syscall wrappers.
Change-Id: I270d66511f926d30a9d347930e977a026e033998
Reviewed-on: https://go-review.googlesource.com/c/sys/+/470175
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Go 1.19 incorporates the functionality of execabs directly.
If it has already reported an error, don't report our own error.
In particular Go 1.19 moved the error from lookPathErr to Err.
The code was already checking to not override lookPathErr.
With this change we also do not override Err.
Tested with Go 1.17 through Go 1.20.
Fixesgolang/go#58606
Change-Id: I110127a3925f3800cc058d93e704604a59aa38f7
Reviewed-on: https://go-review.googlesource.com/c/sys/+/469735
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 126516 added support for flags argument, implemented in the same way
as glibc does (it tries to guess what the kernel would do).
CL 246537 added using faccess2(2) Linux syscall which supports the flags
directly. For older kernels, though, the syscall is not available, and
the code uses glibc-like fallback.
There is one very specific scenario in which the fallback fails.
The scenario involves all these conditions:
- no faccessat2 support available (i.e. either Linux kernel < 5.8,
or a seccomp set up to disable faccessat2);
- the current user is not root (i.e. geteuid() != 0);
- CAP_DAC_OVERRIDE capability is set for the current process;
- the file to be executed does not have executable permission
bit set for either the current EUID or EGID;
- the file to be executed have at least one executable bit set.
Unfortunately, this set of conditions was observed in the wild -- a
container run as a non-root user with the binary file owned by root with
executable permission set for a user only [1]. Essentially it means it
is not as rare as it may seem.
Now, CAP_DAC_OVERRIDE essentially makes the kernel bypass most of the
checks, so execve(2) and friends work the same was as for root user,
i.e. if at least one executable bit it set, the permission to execute
is granted (see generic_permission() function in the Linux kernel).
Modify the code to check for CAP_DAC_OVERRIDE and mimic the kernel
behavior for permission checks.
This is essentially the same fix as CL 468735 for Go syscall package.
Tested on CentOS 7 with the repro similar to the one from [2].
[1] https://github.com/opencontainers/runc/issues/3715
[2] https://github.com/golang/go/issues/58552#issuecomment-1432505621
Change-Id: I726b6acab6a6e6d0358ef98e6a582b405c347614
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/sys/+/468877
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
In CL 419915, both pointer fields of the PtraceIoDesc struct were
converted to type uintptr to address golang/go#54113.
However, that change was overzealous: the fix needed to convert fields
that refer to addresses in the child process, but the Addr field of
PtraceIoDesc is not even in the child process! It is instead an
address in the parent (Go) process.
Go's unsafe.Pointer rules prohibit converting a Go pointer to a
uintptr except when immediately converting back to an unsafe.Pointer
or calling a system call. Populating a PtraceIoDesc struct is neither
of those things, so converting the Addr field to uintptr introduced a
use-after-free bug.
This change reverts the change to the Addr field from CL 419915 and
consolidates the implementation of PtraceIO to reduce the the amount
of code that varies with GOARCH.
This change does not address the remaining ptrace uintptr bug
(golang/go#58387), which is also present in the Linux implementation.
Fixesgolang/go#58351.
Updates golang/go#54113.
For golang/go#41205.
Change-Id: I14bdb4af42130aa7b4375e3f53fd1a0435f14307
Reviewed-on: https://go-review.googlesource.com/c/sys/+/465676
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Despite having the misleading type "void*" in the C API, the "offs"
field of the ptrace_io_desc struct is an offset within the child
process, and thus is not necessarily a valid pointer at all in the
parent process. The Go unsafe.Pointer type must refer only to valid
pointers, so converting this field through unsafe.Pointer is incorrect
and (in some cases) dangerous.
While we're here, let's also rename the "addr" function argument to
"offs", since that's the corresponding ptrace_io_desc field. It's very
confusing to have a function argument named "attr" that doesn't map to
the struct field of the same name!
For golang/go#58351.
Change-Id: Id899f823e8d398b51fb0c42f466d7ae2f957c26b
Reviewed-on: https://go-review.googlesource.com/c/sys/+/465675
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The purpose of the _zero variable is to provide a valid address for a
pointer to an array of length zero. All other uses of the variable
take its address, but one reference to it (added in CL 147850043)
converts the variable (which has type uintptr) directly to an
unsafe.Pointer, producing a nil pointer instead of a non-nil pointer
to a zero-length array.
This typo is caught by 'go vet', but was masked for a long time by the
numerous false-positive warnings for the same check (#41205).
For golang/go#41205.
Change-Id: Ib3bebfadc6fc5574db19630169ff3f65da857bdd
Reviewed-on: https://go-review.googlesource.com/c/sys/+/465597
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
The os/signal package drops signal notifications if the channel is not
ready to receive immediately. To avoid dropping signals (for example,
while processing the other branch of a 'select'), the channel must be
buffered.
This fixes a mistake flagged by 'go vet ./...'.
Change-Id: I2a20dbe2aa27ae8ec009fff5e7be47e4409fdddd
Reviewed-on: https://go-review.googlesource.com/c/sys/+/465595
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Support for LoongArch has been merged upstream. This allows to
drop the loong64 specific glibc patches.
Because the header file sys/mount.h of glibc 2.36 includes fcntl.h
(commit 78a408ee7ba041fc8d5dbd5f67065b4a982c11e5), this will leads to
duplicate definition of structure stat on MIPS64. In order to solve
this error, use the custom type my_stat to generate the Go Stat_t.
Change-Id: I888280d777d1c7089548acf1b3821762011d79b0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/453555
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This change adds "." and "-" support for DLL filenames in "//sys".
Supporting "." requires a change in how mkwinsyscall handles the
"= <filename>.<function>" syntax. Instead of assuming that only one "."
can appear in this string, now mkwinsyscall assumes that any additional
"." belongs to the filename.
Supporting "." also requires changing how Go identifiers are created for
each DLL. This change also allows mkwinsyscall to support "-". When
creating a Go identifier, "." and "-" in the DLL filename are replaced
with "_". Otherwise, mkwinsyscall would produce invalid Go code, causing
"format.Source" to fail.
Includes a test for the new behavior. There aren't yet any cases where
this code is executed while generating the x/sys/windows syscalls. The
syscalls "SetSocketMediaStreamingMode" from "windows.networking.dll" and
"WslRegisterDistribution" from "api-ms-win-wsl-api-l1-1-0.dll" can be
successfully called using this change, but these syscalls have no known
use in Go so they are not included in this change.
Fixesgolang/go#57913
Change-Id: If64deeb8c7738d61520e7392fd2d81ef8920f08d
Reviewed-on: https://go-review.googlesource.com/c/sys/+/463215
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
No changes in generated files.
Update loongarch64-linux-gcc to 13.0.0
- The kernel header file version is upgraded to 5.19
Update qemu-loongarch64 to 7.1.0
- Support for LoongArch has been merged upstream.
Change-Id: I637925fd9e5575dfb4ce91ece98951d5bf3053e6
Reviewed-on: https://go-review.googlesource.com/c/sys/+/453458
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This provides a ClockAdjtime function providing access to the clock_adjtime system call on Linux.
The clock_adjtime system call is like adjtimex, but takes a clockid_t as its first argument.
The unix package already provides Adjtimex and the associated Timex struct; it also provides
the other functions that take a clockid_t (like ClockGettime). ClockAdjtime is an essential
system call for programs that want to use the Linux PTP hardware clock infrastructure (see
https://docs.kernel.org/driver-api/ptp.html).
Fixesgolang/go#57618
Change-Id: I68d022425eb9cd394a204ad7fedab985c0496fee
Reviewed-on: https://go-review.googlesource.com/c/sys/+/463056
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
This CL updates the windows.UTF16FromString and windows.UTF16ToString
implementation so they forward to their syscall counterparts.
The standard library uses these particular syscall functions across
the board as it can't depend on x/sys. This means that even if the
syscall API is frozen, the implementation still receives improvements
and bug fixes, such as CL 425054.
Porting CL 425054 to x/sys is possible, but for this particular case
I think it's better to just call the syscall package. This way both
repos will benefit from future improvements (which I plan to do soon).
Change-Id: I305c4409142d79a57008d7e6d0717fb8986fe906
Reviewed-on: https://go-review.googlesource.com/c/sys/+/462875
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
NetBSD has both struct uvmexp (used internally) and struct uvmexp_sysctl
(preferred for interfacing from user code). Expose the latter as type
Uvmexp with the same interface as on OpenBSD.
I am not sure if it makes sense to even have a name parameter for
SysctlUvmexp, since the only valid value can be "vm.uvmext2".
Change-Id: I40a743536c28e3fb7a54253768db35b1629fabfe
Reviewed-on: https://go-review.googlesource.com/c/sys/+/460156
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The current code has continued to work on OpenBSD, since it has been using
syscall(2) via libc. However, the system call numbers are still hardcoded in
golang.org/x/sys/unix. Various system call changes have been made in OpenBSD,
resulting in changes to the system call numbers and arguments, which now
fail when this package is used.
Switch to calling various system calls directly via libc, rather than calling
via libc using syscall(2).
Unfortunately, this will no longer work on upstream Go since the changes
needed to convert it to libc are still blocked pending review. This means
that we're in a less than ideal situation where upstream Go openbsd/mips64
does not work on any supported OpenBSD release (in fact has not since
OpenBSD 6.8, which was EOL over a year ago), however golang.org/x/sys/unix
is now unusable with the Go package that ships with supported releases via
OpenBSD ports. It would seem that being able to actually use Go software on
a supported OpenBSD release trumps maintaining compatibility with the
unusable upstream Go source.
Updates golang/go#36435
Change-Id: Id8947cd0e4e05709e96c3d4478ac8789b924d416
Reviewed-on: https://go-review.googlesource.com/c/sys/+/459497
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This clarifies these functions' behavior when the non-control data is
empty but there is a control data present.
It also makes clear the difference between Sendmsg, SendmsgN, and
SendmsgBuffers, and between Recvmsg and RecvmsgBuffers.
Fixesgolang/go#56911
Change-Id: I1e35659e66e493c192af7f5a426a316f6052475c
Reviewed-on: https://go-review.googlesource.com/c/sys/+/456816
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
