This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 05 Apr, 2022 5 commits
    • David Runge's avatar
      Fix localversion · 397f13b4
      David Runge authored
      
      
      localversion-rt:
      Set localversion correctly and upgrade distribution version.
      
      Signed-off-by: David Runge's avatarDavid Runge <dvzrv@archlinux.org>
      397f13b4
    • David Runge's avatar
      Set distribution specific localversion · 5f74f84d
      David Runge authored
      
      
      localversion-rt:
      Change the localversion to append the distribution specific string.
      
      Signed-off-by: David Runge's avatarDavid Runge <dvzrv@archlinux.org>
      5f74f84d
    • Linus Torvalds's avatar
      Revert "swiotlb: rework "fix info leak with DMA_FROM_DEVICE"" · b4dc7716
      Linus Torvalds authored and David Runge's avatar David Runge committed
      commit bddac7c1 upstream.
      
      This reverts commit aa6f8dcb.
      
      It turns out this breaks at least the ath9k wireless driver, and
      possibly others.
      
      What the ath9k driver does on packet receive is to set up the DMA
      transfer with:
      
        int ath_rx_init(..)
        ..
                      bf->bf_buf_addr = dma_map_single(sc->dev, skb->data,
                                                       common->rx_bufsize,
                                                       DMA_FROM_DEVICE);
      
      and then the receive logic (through ath_rx_tasklet()) will fetch
      incoming packets
      
        static bool ath_edma_get_buffers(..)
        ..
              dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr,
                                      common->rx_bufsize, DMA_FROM_DEVICE);
      
              ret = ath9k_hw_process_rxdesc_edma(ah, rs, skb->data);
              if (ret == -EINPROGRESS) {
                      /*let device gain the buffer again*/
                      dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
                                      common->rx_bufsize, DMA_FROM_DEVICE);
                      return false;
              }
      
      and it's worth noting how that first DMA sync:
      
          dma_sync_single_for_cpu(..DMA_FROM_DEVICE);
      
      is there to make sure the CPU can read the DMA buffer (possibly by
      copying it from the bounce buffer area, or by doing some cache flush).
      The iommu correctly turns that into a "copy from bounce bufer" so that
      the driver can look at the state of the packets.
      
      In the meantime, the device may continue to write to the DMA buffer, but
      we at least have a snapshot of the state due to that first DMA sync.
      
      But that _second_ DMA sync:
      
          dma_sync_single_for_device(..DMA_FROM_DEVICE);
      
      is telling the DMA mapping that the CPU wasn't interested in the area
      because the packet wasn't there.  In the case of a DMA bounce buffer,
      that is a no-op.
      
      Note how it's not a sync for the CPU (the "for_device()" part), and it's
      not a sync for data written by the CPU (the "DMA_FROM_DEVICE" part).
      
      Or rather, it _should_ be a no-op.  That's what commit aa6f8dcb
      
      
      broke: it made the code bounce the buffer unconditionally, and changed
      the DMA_FROM_DEVICE to just unconditionally and illogically be
      DMA_TO_DEVICE.
      
      [ Side note: purely within the confines of the swiotlb driver it wasn't
        entirely illogical: The reason it did that odd DMA_FROM_DEVICE ->
        DMA_TO_DEVICE conversion thing is because inside the swiotlb driver,
        it uses just a swiotlb_bounce() helper that doesn't care about the
        whole distinction of who the sync is for - only which direction to
        bounce.
      
        So it took the "sync for device" to mean that the CPU must have been
        the one writing, and thought it meant DMA_TO_DEVICE. ]
      
      Also note how the commentary in that commit was wrong, probably due to
      that whole confusion, claiming that the commit makes the swiotlb code
      
                                        "bounce unconditionally (that is, also
          when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale
          data from the swiotlb buffer"
      
      which is nonsensical for two reasons:
      
       - that "also when dir == DMA_TO_DEVICE" is nonsensical, as that was
         exactly when it always did - and should do - the bounce.
      
       - since this is a sync for the device (not for the CPU), we're clearly
         fundamentally not coping back stale data from the bounce buffers at
         all, because we'd be copying *to* the bounce buffers.
      
      So that commit was just very confused.  It confused the direction of the
      synchronization (to the device, not the cpu) with the direction of the
      DMA (from the device).
      
      Reported-and-bisected-by: default avatarOleksandr Natalenko <oleksandr@natalenko.name>
      Reported-by: default avatarOlha Cherevyk <olha.cherevyk@gmail.com>
      Cc: Halil Pasic <pasic@linux.ibm.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Kalle Valo <kvalo@kernel.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Toke Høiland-Jørgensen <toke@toke.dk>
      Cc: Maxime Bizon <mbizon@freebox.fr>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Backported-for: https://bugs.archlinux.org/task/74187
      
      
      Signed-off-by: David Runge's avatarDavid Runge <dvzrv@archlinux.org>
      b4dc7716
    • Jason A. Donenfeld's avatar
      random: treat bootloader trust toggle the same way as cpu trust toggle · 2bb17449
      Jason A. Donenfeld authored and David Runge's avatar David Runge committed
      
      
      If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND.
      But, the user can disable (or enable) this behavior by setting
      `random.trust_cpu=0/1` on the kernel command line. This allows system
      builders to do reasonable things while avoiding howls from tinfoil
      hatters. (Or vice versa.)
      
      CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards
      the seed passed via EFI or device tree, which might come from RDRAND or
      a TPM or somewhere else. In order to allow distros to more easily enable
      this while avoiding those same howls (or vice versa), this commit adds
      the corresponding `random.trust_bootloader=0/1` toggle.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Graham Christensen <graham@grahamc.com>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Reviewed-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Link: https://github.com/NixOS/nixpkgs/pull/165355
      
      
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: David Runge's avatarDavid Runge <dvzrv@archlinux.org>
      2bb17449
    • Jan Alexander Steffens (heftig)'s avatar
      ZEN: Add sysctl and CONFIG to disallow unprivileged CLONE_NEWUSER · 88857827
      Jan Alexander Steffens (heftig) authored and David Runge's avatar David Runge committed
      
      
      Our default behavior continues to match the vanilla kernel.
      
      Signed-off-by: David Runge's avatarDavid Runge <dvzrv@archlinux.org>
      88857827
  2. 01 Apr, 2022 2 commits
  3. 31 Mar, 2022 2 commits
  4. 28 Mar, 2022 31 commits