Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 26 Jul, 2024 2 commits
  3. 24 Jul, 2024 2 commits
  5. 23 Jul, 2024 1 commit
  7. 21 Jul, 2024 2 commits
  9. 19 Jul, 2024 3 commits
    • Jason A. Donenfeld's avatar
      MAINTAINERS: add random.h headers to RNG subsection · ad8070cb
      Jason A. Donenfeld authored 
      Before, patches to two RNG header files wouldn't be sent to the right
recipients automatically. So add the two header files -- one for
userspace and one for the kernel -- to the right part of the MAINTAINERS
file.
Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      ad8070cb
    • Jason A. Donenfeld's avatar
      x86: vdso: Wire up getrandom() vDSO implementation · 33385150
      Jason A. Donenfeld authored 
      Hook up the generic vDSO implementation to the x86 vDSO data page. Since
the existing vDSO infrastructure is heavily based on the timekeeping
functionality, which works over arrays of bases, a new macro is
introduced for vvars that are not arrays.

The vDSO function requires a ChaCha20 implementation that does not write
to the stack, yet can still do an entire ChaCha20 permutation, so
provide this using SSE2, since this is userland code that must work on
all x86-64 processors.
Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
Reviewed-by: Samuel Neves <sneves@dei.uc.pt> # for vgetrandom-chacha.S
Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      33385150
    • Jason A. Donenfeld's avatar
      random: introduce generic vDSO getrandom() implementation · 4ad10a5f
      Jason A. Donenfeld authored 
      Provide a generic C vDSO getrandom() implementation, which operates on
an opaque state returned by vgetrandom_alloc() and produces random bytes
the same way as getrandom(). This has the following API signature:

  ssize_t vgetrandom(void *buffer, size_t len, unsigned int flags,
                     void *opaque_state, size_t opaque_len);

The return value and the first three arguments are the same as ordinary
getrandom(), while the last two arguments are a pointer to the opaque
allocated state and its size. Were all five arguments passed to the
getrandom() syscall, nothing different would happen, and the functions
would have the exact same behavior.

The actual vDSO RNG algorithm implemented is the same one implemented by
drivers/char/random.c, using the same fast-erasure techniques as that.
Should the in-kernel implementation change, so too will the vDSO one.

It requires an implementation of ChaCha20 that does not use any stack,
in order to maintain forward secrecy if a multi-threaded program forks
(though this does not account for a similar issue with SA_SIGINFO
copying registers to the stack), so this is left as an
architecture-specific fill-in. Stack-less ChaCha20 is an easy algorithm
to implement on a variety of architectures, so this shouldn't be too
onerous.

Initially, the state is keyless, and so the first call makes a
getrandom() syscall to generate that key, and then uses it for
subsequent calls. By keeping track of a generation counter, it knows
when its key is invalidated and it should fetch a new one using the
syscall. Later, more than just a generation counter might be used.

Since MADV_WIPEONFORK is set on the opaque state, the key and related
state is wiped during a fork(), so secrets don't roll over into new
processes, and the same state doesn't accidentally generate the same
random stream. The generation counter, as well, is always >0, so that
the 0 counter is a useful indication of a fork() or otherwise
uninitialized state.

If the kernel RNG is not yet initialized, then the vDSO always calls the
syscall, because that behavior cannot be emulated in userspace, but
fortunately that state is short lived and only during early boot. If it
has been initialized, then there is no need to inspect the `flags`
argument, because the behavior does not change post-initialization
regardless of the `flags` value.

Since the opaque state passed to it is mutated, vDSO getrandom() is not
reentrant, when used with the same opaque state, which libc should be
mindful of.

The function works over an opaque per-thread state of a particular size,
which must be marked VM_WIPEONFORK, VM_DONTDUMP, VM_NORESERVE, and
VM_DROPPABLE for proper operation. Over time, the nuances of these
allocations may change or grow or even differ based on architectural
features.

The opaque state passed to vDSO getrandom() must be allocated using the
mmap_flags and mmap_prot parameters provided by the vgetrandom_opaque_params
struct, which also contains the size of each state. That struct can be
obtained with a call to vgetrandom(NULL, 0, 0, &params, ~0UL). Then,
libc can call mmap(2) and slice up the returned array into a state per
each thread, while ensuring that no single state straddles a page
boundary. Libc is expected to allocate a chunk of these on first use,
and then dole them out to threads as they're created, allocating more
when needed.

vDSO getrandom() provides the ability for userspace to generate random
bytes quickly and safely, and is intended to be integrated into libc's
thread management. As an illustrative example, the introduced code in
the vdso_test_getrandom self test later in this series might be used to
do the same outside of libc. In a libc the various pthread-isms are
expected to be elided into libc internals.
Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      4ad10a5f
  11. 17 Jul, 2024 3 commits
  13. 16 Jul, 2024 1 commit
  15. 15 Jul, 2024 4 commits
  17. 14 Jul, 2024 2 commits
    • Brian Foster's avatar
      MAINTAINERS: remove Brian Foster as a reviewer for bcachefs · 63567f64
      Brian Foster authored 
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      63567f64
    • Lorenzo Bianconi's avatar
      net: airoha: Introduce ethernet support for EN7581 SoC · 23020f04
      Lorenzo Bianconi authored 
      Add airoha_eth driver in order to introduce ethernet support for
Airoha EN7581 SoC available on EN7581 development board (en7581-evb).
EN7581 mac controller is mainly composed by the Frame Engine (PSE+PPE)
and QoS-DMA (QDMA) modules. FE is used for traffic offloading (just
basic functionalities are currently supported) while QDMA is used for
DMA operations and QOS functionalities between the mac layer and the
external modules conncted to the FE GDM ports (e.g MT7530 DSA switch
or external phys).
A general overview of airoha_eth architecture is reported below:

               ┌───────┐                                     ┌───────┐
               │ QDMA2 │                                     │ QDMA1 │
               └───┬───┘                                     └───┬───┘
                   │                                             │
           ┌───────▼─────────────────────────────────────────────▼────────┐
           │                                                              │
           │       P5                                            P0       │
           │                                                              │
           │                                                              │
           │                                                              │    ┌──────┐
           │                                                           P3 ├────► GDM3 │
           │                                                              │    └──────┘
           │                                                              │
           │                                                              │
┌─────┐    │                                                              │
│ PPE ◄────┤ P4                          PSE                              │
└─────┘    │                                                              │
           │                                                              │
           │                                                              │
           │                                                              │    ┌──────┐
           │                                                           P9 ├────► GDM4 │
           │                                                              │    └──────┘
           │                                                              │
           │                                                              │
           │                                                              │
           │        P2                                           P1       │
           └─────────┬───────────────────────────────────────────┬────────┘
                     │                                           │
                 ┌───▼──┐                                     ┌──▼───┐
                 │ GDM2 │                                     │ GDM1 │
                 └──────┘                                     └──┬───┘
                                                                 │
                                                            ┌────▼─────┐
                                                            │  MT7530  │
                                                            └──────────┘

Currently only hw LAN features (QDMA1+GDM1) are available while hw WAN
(QDMA2+GDM{2,3,4}) ones will be added with subsequent patches introducing
traffic offloading support.
Tested-by: default avatarBenjamin Larsson <benjamin.larsson@genexis.eu>
Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/274945d2391c195098ab180a46d0617b18b9e42c.1720818878.git.lorenzo@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      23020f04
  19. 13 Jul, 2024 1 commit
  21. 12 Jul, 2024 4 commits
  23. 11 Jul, 2024 4 commits
  25. 10 Jul, 2024 7 commits
  27. 09 Jul, 2024 4 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7