On s390x (gcc-8.3.1-5.1.el8.s390x) the compiler warns that we don't
pass size larger than 2^63-1 to malloc. With LTO enabled, it is also
quite adamant in detecting that with nm_utils_get_next_realloc_size().
Optimally, we would disable this useless warning with "-Wno-alloc-size-larger-than",
but that seems not to work. So add a workaround in code :(
It's hard to actually workaround the warning while handling all kinds of
sizes. The only simple solution is to no handle such huge cases and only
assert.
In function 'nm_secret_mem_realloc',
inlined from '_nm_str_buf_ensure_size' at shared/nm-glib-aux/nm-shared-utils.c:5316:31:
shared/nm-glib-aux/nm-secret-utils.h:180:17: error: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
m_new = g_malloc(new_len);
^
shared/nm-glib-aux/nm-secret-utils.h: In function '_nm_str_buf_ensure_size':
/usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation function 'g_malloc' declared here
gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE(1);
^
lto1: all warnings being treated as errors
RFC4361 intends to set the same IAID/DUID for both DHCPv4 and DHCPv6.
Previously, we didn't have a mode for that.
Of course, you could always set "ipv4.dhcp-client-id" and
"ipv6.dhcp-duid" to (the same) hex string, but there was no
automatic mode. Instead we had:
- "ipv4.dhcp-client-id=duid" which sets the client ID to a stable,
generated DUID. However, there was no option so that the same
DUID/IAID would be automatically used for DHCPv6.
- there are various special values for "ipv6.dhcp-duid" which generate
a stable DUIDs. However, those values did not work for
"ipv4.dhcp-client-id".
Solve that by adding "ipv4.dhcp-client-id=ipv6-duid" which indicates to use
the DUID from DHCPv6's "ipv6.dhcp-duid" setting. As IAID it will prefer "ipv4.dhcp-iaid"
(if set), but fallback to "ipv6.dhcp-iaid".
https://tools.ietf.org/html/rfc4361https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/618https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/718
The default value is `optional' so the current check in place is
actually wrong and blocks NM from connecting to WPA3 networks.
Overall the check is not that useful as WPA3 Enterprise always
requires PMF to be 'required' so let's always force it instead.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Fixes: e874ccc917 ('wifi: add WPA-EAP-SUITE-B-192 support')
This file has no relevance for NetworkManager. And we should not deviate
from upstream n-dhcp4 which we include via git-subtree. Revert the
change.
This partly reverts commit 7f4a7bf433.
Since "_i" is int type and G_N_ELEMENTS() is size_t, the compiler
can warn
error: comparison of unsigned expression in '< 0' is always false [-Werror=type-limits]
Avoid the warning by casting.
It's questionable whether the manual page should explain
exactly what it does.
However, it's a good exercise writing this up (to review
what happens). Also, a manual page that simply says "it configures
the network automatically" without going into how exactly, is
not very useful either.
We use the iface_idx for example to determine the routing table,
by using table 30400+iface_idx.
While the HTTP API for Azure has a index, it does not mean that we
should use that index as-is for our purpose.
Instead, treat those indexes separately and ensure that the
iface_idx that we return is numbering the interfaces starting
from zero.
While it's not clear whether we should be strict or forgiving
when fetching the HTTP meta data, we should be consistent.
On a parse error of the IP addresses we fail. Hence also
fail on a parse error for the subnet.
The API of mcs_provider_get_config() allows to explicitly request
for certain interfaces (MAC addresses), but it also allows to fetch
any.
That means, the result dictionary will be pre-populated with the
MAC addresses that were requested, but if we encounter an unknown
interface, then that is not a reason to fail.
Previously we would call
nmcs_utils_hwaddr_normalize(g_bytes_get_data(response, NULL), -1);
which treats the data in response as NUL terminated. That is not
entirely wrong, because the HTTP request's response is guaranteed
to have a NUL termination at the end. However, it doesn't seam to good
either.
For one, we already have the length. Use it. But also, if the response
contains any NUL bytes in the middle, then this would wrongly only
consider the first line. We should not accept "00:11:22:33:44:55\0bogus"
as valid.
While at it, reject NUL characters from nmcs_utils_hwaddr_normalize() --
except one NUL at the end.
First note that all three provider implementations are very similar.
That is why NMCSProvider's implementation does already some work that
is common to all implementations. For example, it provides the
NMCSProviderGetConfigTaskData structure to help tracking the data of
the request.
Also note that the GCP/Azure implementations didn't handle the
cancellation correctly. They always would pass
g_task_get_cancellable(get_config_data->task)
to the asynchronous requests. That is the GCancellable provider by the
caller. That is fine when there is only one async operation ongoing. But
that is not the case, we have parallel HTTP requests.
Then, when an error happened, the overall get_config() operations fails
and the still pending requests should all be aborted. However, we must
not cancel the GCancellable of the user (because that is not owned by us).
The correct solution is to use an internal cancellable in those cases.
Anyway. Since all of this is similar, we can extend the base class
to handle things for us. This also gets the cancellation right by having
a "get_config_data->intern_cancellable".
The code is not entirely straight forward. Consistent naming
is hence important.
In "nmcs-provider-ec2.c", variables of this kind are called
"get_config_data". That also matches to the type of the data
(NMCSProviderGetConfigTaskData).
Rename the variables to make naming consistent. Also, I find the
longer name to be clearer.
When building without "more-asserts" and LTO enabled, we can get
a warning about uninitalized "obj" variable:
src/platform/nm-linux-platform.c: In function 'ip_route_add':
src/platform/nm-platform.c:4761:24: warning: 'MEM[(struct NMPlatformIPRoute *)&obj + 24B].rt_source' may be used uninitialized in this function [-Wmaybe-uninitialized]
4761 | route->rt_source = nmp_utils_ip_config_source_round_trip_rtprot(route->rt_source);
| ^
src/platform/nm-platform.h:2139:25: warning: 'BIT_FIELD_REF <MEM[(const struct NMPlatformIPRoute *)&obj + 24B], 8, 72>' may be used uninitialized in this function [-Wmaybe-uninitialized]
2139 | return r->table_any ? 254u /* RT_TABLE_MAIN */
|
That is due to the "default" switch case which was unhandled
when building without more-asserts". Avoid that by reworking the
code.
With LTO it's easy to get "-Wmaybe-uninitialized" false positives.
But the warning is useful, we we don't want to disable it altogether.
However, while investigating the problem it can be useful to patch
it temporarily. Add a code comment that suggests how to do that.
With LTO builds we get "-Wmaybe-uninitialized" warnings, which break
the build.
These seem false positives to me, due to aggressive inlining. But also
suppressing them with a pragma does not work. So, make them non-fatal
altogether. That is unfortunate, because this warning would be useful
to catch bugs.
Interestingly, when building --with-more-asserts, then the build passes
without warning. Probably because then the inlining doesn't happen.
libtool: link: gcc -Wall -Werror -Wno-stringop-overflow -Wextra -Wdeclaration-after-statement -Wfloat-equal -Wformat-nonliteral -Wformat-security -Wimplicit-function-declaration -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes -Wpointer-arith -Wshadow -Wshift-negative-value -Wstrict-prototypes -Wundef -Wvla -Wno-duplicate-decl-specifier -Wno-format-truncation -Wno-format-y2k -Wno-missing-field-initializers -Wno-pragmas -Wno-sign-compare -Wno-unknown-pragmas -Wno-unused-parameter -Wno-array-bounds -Wunused-value -Wcast-function-type -Wimplicit-fallthrough -fno-strict-aliasing -fdata-sections -ffunction-sections -Wl,--gc-sections -flto -flto-partition=none -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o src/platform/tests/test-platform-general src/platform/tests/test_platform_general-test-platform-general.o src/.libs/libNetworkManagerTest.a -luuid -lgnutls -lsystemd -lndp -lselinux -L/lib64 -laudit -lpsl -lcurl -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -ludev -ldl -pthread
src/platform/nm-linux-platform.c: In function 'ip_route_add':
src/platform/nm-platform.c:4761:24: error: 'MEM[(struct NMPlatformIPRoute *)&obj + 24B].rt_source' may be used uninitialized in this function [-Werror=maybe-uninitialized]
4761 | route->rt_source = nmp_utils_ip_config_source_round_trip_rtprot(route->rt_source);
| ^
src/platform/nm-platform.h:2139:25: error: 'BIT_FIELD_REF <MEM[(const struct NMPlatformIPRoute *)&obj + 24B], 8, 72>' may be used uninitialized in this function [-Werror=maybe-uninitialized]
2139 | return r->table_any ? 254u /* RT_TABLE_MAIN */
| ^
lto1: all warnings being treated as errors
lto-wrapper: fatal error: gcc returned 1 exit status
When building without more-assertions and LTO, the compiler might think
that "wait" is uninitialized. Avoid the warning.
Initializing a variable is not a great solution either, because
potentially it could hide an actual bug. But it still seems to be
best.
src/nm-policy.c: In function update_system_hostname:
src/nm-policy.c:909: warning: wait may be used uninitialized in this function [-Wmaybe-uninitialized]
909 | if (wait) {
|
src/nm-policy.c:901: note: wait was declared here
901 | gboolean wait;
|
On copr builds, the unit tests sometimes fail to create a veth
interface. In those cases, kernel rejects the netlink request
with EPERM. copr uses mock on Fedora 33 hosts.
I think this is a kernel bug. Add a workaround by retrying a few times.
"shared/nm-std-aux/unaligned.h" is taken from systemd and frequently
re-imported via the "systemd" branch.
It is not our code, and should not be formatted with our clang-format.
Linux headers and some libc headers have overlapping defines
for network types and functions.
In the past years, glibc and linux headers were improved to cooperate
so you could include either one, in any order.
With musl and possibly some older glibc versions that doesn't work so
well.
Reorder and change includes to make it work better. Yes, this looks
pretty random and unmotivated. The includes are changed in order to
successfully build on various libc/kernel versions, with the goal
of not using #if.
Due to mixing includes of userspace network headers (net/*) and
kernelspace onces (linux/if*) symbol redefinitions happen on musl.
[thaller@redhat.com: modified original patch]
We were asserting against error messages from strerror(), and on libmusl
these are different. Relax the checks.
We still assert against parts of the text, where possible. So a similar
problem could happen in the future or with another libc library.