`GOOS` and `GOARCH` can be set to cross compile the Go code. But
`good-names.go` is generated at build time using `mknames.go`, which
must be built for the build platform. `GOOS` and `GOARCH` can be unset
to do this. In many circumstances, Go will use its own internal linker
to build the binary, which means it won't need to use `$CC`. But in
some scenarios, e.g. when building PIE binaries, it will use `$CC` as
the linker, so this needs to be set to the build platform's compiler
for `go run`.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
its calling compiler and linker in single step
ensure that build ldflags are respected as it
might have important information like which runtime
to use.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
On architectures with pointer alignment constraints larger than 8
bytes, e.g. CHERI RISC-V, a raw container calculation in libcap
results in invalid read accesses to members or memory corruption.
Fix this by taking the alignment constraints into account as well
as asserting the memory layout of the container struct.
For capability allocation, libcap uses the struct:
struct _cap_alloc_s {
__u32 magic;
__u32 size;
union {
...
} u;
};
where the union abstracts several capability types that can be
identified by _cap_alloc_s' magic member. To obtain a pointer to the
allocation struct from a pointer to the union, the following
expression is used:
struct _cap_alloc_s *p = (void *) (-2 + (__u32 *) union_ptr);
This calculation relies on the assumption that the union is placed at an
offset of 8 bytes in the allocation struct. However, some struct types
that are in the union may have pionters and thus, these structs may have
larger alignment constraints on architectures with fat pointers, e.g.
16-byte alignment on CHERI RISC-V. In these cases, the offset may be
larger than 8 bytes and the raw container calculation results in an
invalid pointer that is dereferenced.
Fix the caluculation by using the alignment constraint of the union if
it exceeds the size of the two preceeding 32-bit uints magic and size.
Statically assert that the so calculated offset matches the actual
offset of u in _cap_alloc_s.
Signed-off-by: Chris Hofer <christian.hofer@codasip.com>
Added compilation fix for -std=c99 compilation, and suppressed
newly introduced warnings from clang.
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=220415
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Using NewIAB ensures that common startup initialization happens before trying
to use `words`. Also switch to using IAB.good to determine if the parsed IAB
is valid.
Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=220420
Signed-off-by: Garret Kelly <gkelly@gkel.ly>
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The link points to a dead resource.
Replace it with the correct link.
Signed-off-by: Ariel Otilibili <ariel.otilibili-anieli@eurecom.fr>
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Multi-year bug displaying the wrong filename when failing
to set a capability on a file.
Thanks to Nikolas for reporting this:
https://bugzilla.kernel.org/show_bug.cgi?id=220245
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
These ideas were what I shared in this answer:
https://stackoverflow.com/a/68339111/14760867
so I figure I might as well capture them here. Credit goes to the stackoverflow user, "Haydentech", for running
into the issue and prompting me to figure out the issue.
All that being said, within the libcap build sources, is not completely
clear when the __cplusplus support would be invoked.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It looks like __xtensa__ defines SA_RESTORER, but my read of the
kernel code suggests that signal handling does not require it be
set. Specifically, if the SA_RESTORER flag is not set, the kernel
inserts a sys_rt_sigreturn call into the stack frame.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I found some confusing macrology for openrisc. I'm optimistic that
this is recognized with the __or1k__ gcc macro.
See for details:
https://bugzilla.kernel.org/show_bug.cgi?id=219915
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Each architecture seems to have its own nuance. Found a way
to get the kernel header compilation to confirm what sigaction
structure is expected by the kernel. This made a few differences
and I am hoping it addresses why the alpha build fails with
debian's sid compile. It makes some changes to memory reservation
for other architectures, arm64 (aka aarch64) in particular.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This may include a needed fix for __sh__ too.
I don't have any test machines for this, so this code change
is untested, and based solely on reading kernel etc. sources.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
These (__alpha__, __hppa__, __sh__) don't have the SA_RESTORER
complication, so hopefully can "just work". I'm relying on Debian's
build servers to confirm.
See: https://bugzilla.kernel.org/show_bug.cgi?id=219915
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
See cap_text_formats(7). This is the 2nd time this breakout has been
requested. This time by way of Carlos Rodriguez-Fernandez.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It was introduced between libcap-1.97 and libcap-2.00 but never
actually referenced in the build tree. Thanks to Ross Burton for
pointing this out!
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The cap.GetMode() example causes an exception on go.dev, likely because of some
system call blocking, on the website.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This adds `__riscv` (curiously, gcc does not define `__riscv__`) psx
compilation support.
https://bugzilla.kernel.org/show_bug.cgi?id=219687
Also, add explicit __x86_64__ compilation support. It was working
implicitly, but change to be consistent.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
kill(2) is declared in signal.h, however previously this header was not
included. It happened to work on glibc, where sys/wait.h includes
signal.h, this is however not required behavior in the POSIX standard:
> Inclusion of the <sys/wait.h> header may also make visible all symbols
> from <signal.h> and <sys/resource.h>.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The code was using `hval` when it should have used `mix`. I've removed
`hval` from the code now. This fixes this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=219752
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The previous commit fixed a bug with the config parsing in pam_cap.
This is a test that we don't regress against that fix.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The current configuration parsing does not actually skip user names
that do not start with @, but instead treats the name as a group
name for further parsing, which can result in matching unexpected
capability sets and may trigger potential security issues. Only
names starting with @ should be parsed as group names.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This bug, reported by David Runge, identifies another regression
vs. libpsx-2.71:
https://bugzilla.kernel.org/show_bug.cgi?id=219687
A regression of the LWP threading support reintroduced an old bug
in the libpsx-2.72 rewrite, specifically this bug:
https://github.com/golang/go/issues/42494
This present change includes x86_64, i386 and arm* (32-bit and 64-bit)
support. I've tested each of these with debian OSes, some running via QEMU.
Before releasing 2.74, I plan to extend the testing to all of the targets
supported by Debian (see https://wiki.debian.org/DebianInstaller/Qemu).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
As a workaround for the golang bug: 70630, specifically comment
70630#issuecomment-2513491664 provide an alias for the package.
Perhaps, at some point, that bug or the one it is duped into will
be fixed, and we can remove this workaround.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
