refactor nuageinit to allow a 3rd execution point during boot:
1. nuageinit is invoked before NETWORKING with a minimalistic network setup
for openstrack and potentially other network config setup. it tries
to configure everything which is not requiring any network.
2. nuageinit is invoked again post NETWORKING but pre SERVERS, in the
phase it does all that requires network, like dealing with packages.
Note that creating users have been moved to this phase to allow the
installation of shells like bash or zsh prior the creation of the
users, before that the user creation was failing if a non installed
shell was requested.
3. nuageinit will execute at the rc.local time all the specified scripts
and commands.
MFC After: 1 week
MIT KRB5 krb5kdc differs from the Heimdal kdc.
- The MIT kdc is named krb5kdc while the Heimdal one is named kdc.
- krb5kdc -d flag has a different meaning. krb5kdc -d specifies a
database name. While the Heimdal kdc uses the -d flag to daemonize
it. krb5kdc automaticially daemonizes itself unless the -n flag is
specified.
We do this by looking at the name of the kdc program to determine if
we assume it's a Heimdal kdc or the MIT krb5kdc.
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D50813
Legacy ZFS uses fstab to mount its datasets. In an attempt to fix
another problem 900bc02063 broke legacy ZFS in fstab(5). This
comit works around the problem by mountcritlocal scanning /etc/fstab
for zfs mountpoint and if any are found invoke /etc/rc.d/zpool start.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D50844
In cases where the `/boot` directory is mounted from a different disk,
`/boot/zfs/zpool.cache` will not be found during a `rc.d/zpool`
run. This is because `/etc/fstab` mounts are mounted in
`rc.d/mountcritlocal`, which currently runs AFTER (i.e. `REQUIRE:`)
`rc.d/zpool`.
This change swaps the `rcorder` of `rc.d/zpool`'s dependency on
`mountcritlocal` from `BEFORE:` to `REQUIRE:`. This will ensure that
`/boot` (or even `/etc/` in some configurations) to be visible while
searching for `zpool.cache`.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1614
Closes: https://github.com/freebsd/freebsd-src/pull/1614
Variables for command-line options like $foo_flags can contain characters
that perform pathname expansions, such as '[', ']', and '*'. They were
passed without escaping, and the matched entries in the working directory
affected the command-line options. This change turns off the expansion
when run_rc_command() is called.
While this changes the current behavior, an invocation of a service
program should not depend on entries in the working directory.
Differential Revision: https://reviews.freebsd.org/D45855
Rename path into ni_path (ni stands for nuageinit) which is more
understandable and avoid a shadowing warning because we also use a
variable named path later.
Add a missing local
In official cloudinit, when a user_data file starts with '#!' it
should be execute late in the boot process. To respect this nuageinit
now copy the user_data script into a /var/cache/nuageinit/user_data if
found and a new "firsboot" rcscript anchored to the 'local' rc script is
responsible to execute it if found.
Note by doing this, we fix another issue we had with nuageinit, if the
cloudinit provider provides the user_data scriptout with the executable
permission, previous implementation was not working, like apparently
what Digital Ocean is doing.
PR: 287183
Reported by: olgeni@
To carry out the userdata unit tests, you need to set up the environment in
order to skip adding the default user (nuage.adduser(default_user)
Sponsored by: OVHCloud
These are no longer specific to iSCSI; always build them.
Reviewed by: kevans, jhb
Approved by: kevans (mentor)
Differential Revision: https://reviews.freebsd.org/D50625
This adds a metadata variable, require.kmods, and corresponding functions
or methods in C, C++, and shell, which allow a test to specify that it
requires particular kernel modules to run. If the kernel modules are not
present, the test is skipped. One might want to consider a kyua option
which makes it attempt to load the modules instead.
Differential Revision: https://reviews.freebsd.org/D47470
The only caller already has the current TCB to hand, so just pass it
down rather than get it again. This also makes it clear in the caller
that it depends on the (current) TCB, rather than being storage that
could be assigned to any thread (concurrency issues aside).
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D50594
When this code was first written we didn't have even a struct tcb, so to
make it MI a pointer to the DTV pointer in the TCB was passed around.
Now that we have a struct tcb we can simplify the code by instead
passing around a pointer to that, and the MI code can access the tcb_dtv
member wherever it happens to be in the layout. This reduces boilerplate
in all the various callers of tls_get_addr_common/slow and makes it
clearer that tls_get_addr_common/slow are operating on the TCB, rather
than obfuscating it slightly through the double pointer.
Whilst here, clarify the comments in aarch64's TLSDESC dynamic resolver,
which were using tp without clarifying what this was for (previously a
pointer to the DTV pointer, now a pointer to the TCB, which happen to be
the same thing for Variant I TLS, and in the case of AArch64 are what
TPIDR_EL0 point to directly, with no offset/bias).
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D50591
This was applying a NetBSD fix to FreeBSD. However, the original code
was correct for FreeBSD. NetBSD's obj->tlsoffset is relative to the end
of the TCB, not the TCB itself, whilst ours is relative to the TCB[1]
itself. For example, our allocate_tls uses (char *)tcb + obj->tlsoffset
for the memcpy and memset calls.
Without this reverted, for dynamically loaded shared objects, Initial
Exec accesses to TLS variables on variant I architectures (non-x86) use
the correct address, whilst General Dynamic and dlsym(3) use the
incorrect address (TLS_TCB_SIZE past the start). Note that, on arm64,
LLVM only supports TLSDESC (including LLD) and TLSDESC will use the
static resolver if the variable ends up allocated to the static TLS
block, even in the presence of dlopen(3), so only dlsym(3) shows the
discrepancy there.
Whilst here, add a comment to explain this difference to try and avoid
the same mistake being made in future.
[1] In the case of variant II, it's the amount to subtract, so still
positive
This reverts commit e9a38ed2fa.
Reviewed by: kib (prior version)
Fixes: e9a38ed2fa ("rtld: fix allocate_module_tls() variant I fallback to static allocation")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50565
Provided you don't run out of extra static TLS space this should work,
but it's wholly unnecessary and not how things are supposed to be done.
Only static TLS relocations should allocate static TLS.
Reviewed by: kib
Fixes: 4b1859c0e9 ("Add support for RISC-V architecture.")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50563
Reported and tested: Alex S <iwtcex@gmail.com>
Tested by: pho
Reviewed by: olce
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D50482
If either INET or INET6 is not enabled in the kernel, then the jail(8)
options ip4=<new|inherit> resp. ip6=<new|inherit> are not available.
Detect this case and don't try to provide those options, otherwise
svcjs will not start.
Do this automatically (without a warning) so that net_basic, which
includes both netv4 and netv6, continues to work as expected.
If _svcj_ipaddrs is explicitly configured with an address for an IP
version not supported by the kernel, issue a warning but continue to
start the service. This can result in the service being started with
fewer addresses than expected, but never more.
Reviewed by: netchild, des
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D49976
This leaves the iscsi package for the iSCSI initiator, and the new
package provides the CAM target layer (including the iSCSI target).
Reviewed by: manu, des, jhb
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D50287
When I added libsys I failed to update rtld's reuse of object files
from libc to use ones from libsys instead. This would have turned up
as a broken system in d7847a8d35, but SHARED_CFLAGS is not being
applied to assembly files.
PR: 286975
Reviewed by: jrtc27, jhb
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D50475
This daemon has been removed; also remove things which reference it.
Reviewed by: manu, des, emaste
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D50441
rc.subr uses sysrc(8) for the 'enable' and 'disable' commands, which
means the entire rc(8) stack depends on bsdconfig. Instead, provide a
minimal amount of rc.conf-editing functionality in rc.subr and use it to
implement these commands.
Reviewed by: des, bapt
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D50325
"routing" enables the jail allow.routing permission, which allows the jail to
modify the system routing table. this can be used to run routing daemons
(e.g., BIRD) in a service jail.
Reviewed by: jamie, des
Approved by: des (mentor)
Differential Revision: https://reviews.freebsd.org/D49844
This matches the interface of lposix, although I do wonder why they went
with execp rather than execvp for the function name here.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50177
The key insight here is that the luaL_check*() and luaL_opt*() functions
will happily take indexes that are larger than the stack top and print a
useful error message.
This means that there is no need to check if too few arguments have been
received prior to checking the types of individual arguments.
This patch also replaces a couple reimplementations of luaL_opt*()
functions with the luaL helpers.
References: https://www.lua.org/manual/5.4/manual.html#4.1.2
Reviewed by: emaste, kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50273
This was previously an Elf_Addr and was turned into a uintptr_t when
really it should have been made a size_t. Even on CHERI both actually
work in this case, but it's better style (and more consistent with
elsewhere in the file) to use size_t instead.
Fixes: 4642b638a5 ("rtld-elf: Consistently use uintptr_t for TLS implementation")
Rather than treating the DTV as a raw array of uintptr_t, use proper
struct types and gain the benefit of having different types for
different members. In particular, the module slots now have real pointer
types so less casting is generally needed.
Note that, whilst struct dtv_slot may seem a little unnecessary, this
will help downstream in CheriBSD where we wish to be able to easily
alter the layout of a module's slot, which this helps abstract.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D50231
On traditional architectures where uintptr_t is just a plain integer,
there is no provenance from the order of operations. However, on CHERI
there is even for uintptr_t, and in future this code will use actual
pointer types anyway, where the provenance does technically matter even
for non-CHERI. Commute and associate the operands appropriately to
ensure the provenance is for the new allocation, not the old one.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D50230
This lets us access via named struct members rather than magic
hard-coded indices.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D50229
Firstly, the second argument to allocate_tls is the old TCB (versus
oldtls, which has less of a clear meaning), so rename it to oldtcb like
Variant I.
Secondly, segbase and oldsegbase are oriented towards what ends up in
the segment registers, but that's not the main concern here, and those
don't convey what they actually point to. Instead, rename segbase to tcb
and change it to a uintptr_t **, and remove oldsegbase as it's always
equal to oldtcb, again both matching Variant I.
Thirdly, rename tls to tls_block, again both matching Variant I.
Finally, similarly rename tls to tcb in free_tls, and oldtls to oldtcb
in the common _rtld_allocate_tls.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D50232
Elf_Addr is the format of addresses in the ELF file with the current
ABI's default class. This is normally the same as the format of an
address at run time, though technically exceptions do exist outside of
FreeBSD's currently-supported architectures (for example, IA-64's LP64
supports both ELFCLASS32 and ELFCLASS64 file formats; LP64 vs ILP32 is
an orthogonal EF_IA_64_ABI64 flag). On traditional architectures,
including all currently-supported FreeBSD architectures, addresses and
pointers are synonymous, but on CHERI they are not, as pointers are
capabilities that contain metadata alongside the address. In the cases
here, the quantities are run-time pointers, not addresses (and
definitely not ELF file addresses), so we should use pointer-ish types.
Note that we already use uintptr_t in struct tcb (both Variant I and
Variant II) but still use Elf_Addr in various places here (including
different argument types for tls_get_addr_slow and tls_get_addr_common).
Also use char * for addr rather than even uintptr_t, since most of the
time we want it to be an actual pointer.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D50226
These checks use ps(1) with both the '-p' and '-a' flags, which worked
so far as ps(1)'s '-a' option was buggy. Since the fix in commit
"ps(1): Make '-a' and '-A' always show all processes"
(93a94ce731), such a command-line always selects all processes,
making the specified '-p' useless and the test wrong. Remove the
useless '-a'.
While here, remove the redundant '-x', as '-p' implies '-x' by default.
MFC after: 1 day
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50201
Rather than calling tls_get_addr_common with a biased ti_offset and
un-biasing the return value, we can instead un-bias the offset given in
the first place and not need to adjust the return value. This is in fact
how the MIPS implementation worked, and makes this call tail-recursive.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D50187
For direct exec mode we reuse map_object, but tls_max_index is
initialised to 1. As a result, the executable ends up being assigned
module 2 (and the generation is pointlessly incremented, unlike in
digest_phdr for the normal case). For most architectures this is
harmless, since TLS linker relaxation will optimise General Dynamic
accesses to Initial Exec or Local Exec for executables, but on RISC-V
this relaxation does not exist, yet the linker will initialise the
tls_index in the GOT with module 1, and at run time the call to
__tls_get_addr will fail with:
ld-elf.so.1: Can't find module with TLS index 1
Fix this by making map_object use 1 for obj->tlsindex when it's loading
the main executable, and don't bother to increment tls_dtv_generation
either, matching digest_phdr (though that one is harmless).
(Note this also applies to MIPS on stable/13)
Reviewed by: kib
Fixes: 0fc65b0ab8 ("Make ld-elf.so.1 directly executable.")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50186
If no extra rtld arguments are provided, rtld_argc will be 1 (for
argv[0] and so we are shifting the entire memory range down by a single
pointer. However, unlike argv and envp, auxp's entries are two pointers
in size, not one, and so in this case the source and destination
overlap, meaning simple assignment is UB (C99 6.5.16.1p3). On many
architectures this ends up being harmless as the compiler will emit
double machine word loads and stores, or if it splits them it may still
schedule them such that it works in this case, but our RISC-V baseline
does not include such instructions and LLVM ends up picking a schedule
that copies the second word before the first word, thereby replacing the
first word with a copy of the second word. This results in direct exec
mode segfaulting on RISC-V when given no arguments.
Fix this by using a temporary in the source and let the compiler safely
elide its use.
Reviewed by: kib
Fixes: 0fc65b0ab8 ("Make ld-elf.so.1 directly executable.")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50185
The implementation of dl_iterate_phdr abuses tls_get_addr_slow to get to
the start of the TLS block, inlining the implementation of
__tls_get_addr as if the tls_index's ti_offset were 0 (historically it
called __tls_get_addr itself but changed due to locking issues). For
most architectures, tls_index's ti_offset (relocated by DTPOFF/DTPREL
for GOT entries) is just the offset within that module's TLS block.
However, for PowerPC and RISC-V, which have a non-zero TLS_DTV_OFFSET
and thus are designed assuming DTV entries are biased by that value,
ti_offset normally has TLS_DTV_OFFSET pre-subtracted, but it's
__tls_get_addr's responsibility to compensate for that. By using an
offset of zero here, tls_get_addr_slow will return a pointer to the
start of the TLS block itself, so by adding TLS_DTV_OFFSET we will point
TLS_DTV_OFFSET past the module's TLS block.
Fix this by removing the extra bias (the alternative would be to pass
-TLS_DTV_OFFSET and keep the addition, which would more closely follow
what __tls_get_addr does, but this is more direct).
(Note this also applies to MIPS on stable/13)
Reviewed by: kib
Fixes: d36d681615 ("rtld dl_iterate_phdr(): dlpi_tls_data is wrong")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50184
The implementation here is meant to mirror what a GOT entry for the
given symbol would use for ti_offset. However, on PowerPC and RISC-V,
TLS_DTV_OFFSET is non-zero, and so the GOT entries are normally biased
by this, but we fail to do so here. As a result we end up getting a
pointer TLS_DTV_OFFSET past where the variable actually is.
(Note this also applies to MIPS on stable/13)
Reviewed by: kib
Fixes: 5ceeeba90c ("Import DragonFly BSD commit")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50183
Internally, initfirst objects and their needed objects are put on the
dedicated initlist, which is prepended to the current regular initlist
at the last moment.
This results in the move of the needed objects into the beginning of the
initlist, which is required for the proper initialization of the
dependencies. It seems that glibc moves only the initfirst object,
which makes its constructors depend on not yet initialized dsos.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D50132
