Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
In the past a very low effort interface was used:
- All parmeters were treated as though they were type uinptr_t, and
- The maximum number of parmeters (6) was passed in all cases.
The first is potentially wrong and the second is very inefficient. This commit improves this by:
- Making tools/mksyscall.c more intelligent, and
- Extending the syntax for variadic functions.
For example, in syscall.cvs, the open() API was represened like this:
"open","fcntl.h","","int","const char*","int","..."
In reality, open may take only a single optional argument of type mode_t which is not the same size as uintptr_t. And there is not reason to pass 6 parameters in that case.
And this has been extended to:
"open","fcntl.h","","int","const char*","int","...","mode_t"
The existence of the "mode_t" tells tools/mksyscall that there is at most one optional parameter and, if present, it is of type mode_t.
The new OS interface, sched_get_stackinfo() combines two pthread-specific interfaces into a single generic interface. The existing pthread_get_stackaddr_np() and pthread_get_stacksize_np() are moved from sched/pthread to libs/libc/pthread.
There are two motivations for this change: First, it reduces the number of system calls. Secondly, it adds a common hook that is going to used for a future implementation of TLS.
If SMP is enabled this function will return the number of the CPU that the thread is running on. This is non-standard but follows GLIBC if __GNU_SOURCE is enabled. The returned CPU number is, however, worthless since it returns the CPU number of the CPU that was executing the task when the function was called. The application can never know the true CPU number of the CPU tht it is running on since that value is volatile and change change at any time.
task_spawn() and posix_spawn() are NuttX OS interfaces. In PROTECTED and KERNEL build modes, then can be reached from applications only via a system call. Currently, the number of parameters in a system call is limited to six; these spawn function have seven parameters. Rather than extend the maximum number of parameters across all architectures, I opted instead to marshal the seven parameters into a structure.
*
In order to support builtin in function in protected mode, a task_spawn() system call must be supported. Unfortunately this is overly complex because there is a (soft) limit of 6 parameters in a system call; task_spawn has seven paramters. This is a soft limit but still difficult to extend because it involves assembly language changes to numerous architectures. Better to get more creative.
sched/clock: Move the implementation of clock() from libs/libc/time to sched/clock. This is necessary because it calls the (now) internal OS function clock_systimer. clock() is now accessed only via a system call in certain configuratins.
libs/libc/wqueue: Replace calls to clock_systimer() with calls to the equivalent clock().
fs: Add truncate() support for userfs
fs/unionfs: Add truncate() support to the unionfs
fs/tmpfs: Add ftruncate() support to tmpfs
syscall/: Add system call support for ftruncate()
net/route: Adding ftruncate() support eliminates an issue in file-based routing table management.
fs: Add basic framework to support truncate() and ftruncate(). The infrastructure is complete. Now, however, the actual implementation of ftruncate() will have to be done for each file system.
Entropy pool gathers environmental noise from device drivers, user-space, etc., and returns good random numbers, suitable for cryptographic use. Based on entropy pool design from *BSDs and uses BLAKE2Xs algorithm for CSPRNG output.
Patch also adds /dev/urandom support for using entropy pool RNG and new 'getrandom' system call for getting randomness without file-descriptor usage (thus avoiding file-descriptor exhaustion attacks). The 'getrandom' interface is similar as 'getentropy' and 'getrandom' available on OpenBSD and Linux respectively.
