This implements the randomization of canary values on each build as
mentioned in the comment above the STACK_CHK_GUARD macro. The canary
value is generated by the buildsystem and passed to the ssp module using
a `-D` compiler flag. The ssp object file, using this canary value, is
marked as PHONY to make sure it is rebuild on each make invocation,
thereby ensuring that each build uses a new random canary value.
Implementing this properly would require generating a cryptographically
secure random value on each boot of the RIOT operating system. This is
not deemed possible on some constrained devices, e.g. due to lack of
hardware random number generators. Besides, RIOT only seems to support a
PRNG (random module) currently. While this may be implemented in the
future for some devices the changes implemented in this commit may still
be used as a fallback then.
A hardcoded canary value is used when building software on the CI to not
break the CI test cache [1].
[1]: https://github.com/RIOT-OS/RIOT/pull/13119#issuecomment-574132932
The reassembly buffer only needs (and stores) the headers *before* the
fragment header (called per-fragment headers in RFC 8200, section 4.5).
Currently, when a subsequent IPv6 fragment is received before the first
fragment the fragment header is however not removed. With this fix it
does.
This implements a client for DHCPv6 IA_PD (Identity Association for
Prefix Delegation). Goal was to have a IETF-compliant alternative to
UHCP. The implementation was based on RFC 8415.
The comment exists since the introduction of the [original
implementation], but its meaning is unclear and misleading, as the code
doesn't do anything with link-local.
[original implementation]: https://github.com/RIOT-OS/RIOT/pull/3561
Rule 2 of the source address algorithm outlined in [RFC6724] states the
possible source addresses must also be compared among each other:
> Rule 2: Prefer appropriate scope.
> If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and
> otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If
> Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
Our current implementation doesn't do that. It just checks if the scope
of a possible source is lesser than the scope of the destination
(which involves the second "If" in the rule).
This fix grants points according to the scope of an address. If the
scope matches, they get the highest points, ensuring that the selected
source will always be reachable from the destination.
[RFC6724]: https://tools.ietf.org/html/rfc6724
Since the GNRC_IPV6 is part of GNRC it should be a part of the gnrc compile time configuration group.
This adds information on the group to specify it is gnrc and changes the group from config to net_gnrc_conf
