bitarithm.h is not needed for the interface of shed but may cause conflicts
due to different definitions of SETBIT and CLRBIT
common implementations are: (value, offset) xor (value, mask) bitarithm
implements the later
frac.c and nrf52/usbdev.c use bitarithm.h but where missing the include
sam0/rtt.c defined a bit using mask from bitarithm,
changed that to the soulution used in sam0/rtc.c
As the whitelist define can be set per compilation unit in all
legitimate cases, the checks do not need to be run on every single usb.h
inclusion. This is done for two reaons:
* It is sufficient -- if any user C file includes usb.h, there's already
a good chance that the user is doing something USB related manualy.
(And conversely, the existing examples with boards that happen to pull
in CDC-ACM or CDC-ECM do not include usb.h from an example C file).
* Defining the USB_H_USER_IS_RIOT around legitimate uses of the header
by other headers would allow accidental sidestepping: If a user
includes a legitimate usb.h using header (say, board.h) and just
forgets to include usb.h on their own, their application that'd mess
with USB would still work as usb.h is transitively included, and the
check for custom includes does not trigger.
A new define, USB_H_USER_IS_RIOT_INTERNAL, is defined that may only be
set from within RIOT's own compilation units that deem themselves
standard RIOT peripherals. If all usb.h users in a program match that
requirement, a default VID/PID pair is set.
Due to the new composite check, the individual checks for VID/PID being
set become moot and are removed.
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.
