1. 21 8月, 2018 1 次提交
  2. 18 8月, 2018 6 次提交
  3. 17 8月, 2018 3 次提交
    • G
      arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid() · 5ad356ea
      Greg Hackmann 提交于
      ARM64's pfn_valid() shifts away the upper PAGE_SHIFT bits of the input
      before seeing if the PFN is valid.  This leads to false positives when
      some of the upper bits are set, but the lower bits match a valid PFN.
      
      For example, the following userspace code looks up a bogus entry in
      /proc/kpageflags:
      
          int pagemap = open("/proc/self/pagemap", O_RDONLY);
          int pageflags = open("/proc/kpageflags", O_RDONLY);
          uint64_t pfn, val;
      
          lseek64(pagemap, [...], SEEK_SET);
          read(pagemap, &pfn, sizeof(pfn));
          if (pfn & (1UL << 63)) {        /* valid PFN */
              pfn &= ((1UL << 55) - 1);   /* clear flag bits */
              pfn |= (1UL << 55);
              lseek64(pageflags, pfn * sizeof(uint64_t), SEEK_SET);
              read(pageflags, &val, sizeof(val));
          }
      
      On ARM64 this causes the userspace process to crash with SIGSEGV rather
      than reading (1 << KPF_NOPAGE).  kpageflags_read() treats the offset as
      valid, and stable_page_flags() will try to access an address between the
      user and kernel address ranges.
      
      Fixes: c1cc1552 ("arm64: MMU initialisation")
      Cc: stable@vger.kernel.org
      Signed-off-by: NGreg Hackmann <ghackmann@google.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      5ad356ea
    • W
      arm64: Avoid calling stop_machine() when patching jump labels · f6cc0c50
      Will Deacon 提交于
      Patching a jump label involves patching a single instruction at a time,
      swizzling between a branch and a NOP. The architecture treats these
      instructions specially, so a concurrently executing CPU is guaranteed to
      see either the NOP or the branch, rather than an amalgamation of the two
      instruction encodings.
      
      However, in order to guarantee that the new instruction is visible, it
      is necessary to send an IPI to the concurrently executing CPU so that it
      discards any previously fetched instructions from its pipeline. This
      operation therefore cannot be completed from a context with IRQs
      disabled, but this is exactly what happens on the jump label path where
      the hotplug lock is held and irqs are subsequently disabled by
      stop_machine_cpuslocked(). This results in a deadlock during boot on
      Hikey-960.
      
      Due to the architectural guarantees around patching NOPs and branches,
      we don't actually need to stop_machine() at all on the jump label path,
      so we can avoid the deadlock by using the "nosync" variant of our
      instruction patching routine.
      
      Fixes: 693350a7 ("arm64: insn: Don't fallback on nosync path for general insn patching")
      Reported-by: NTuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
      Reported-by: NJohn Stultz <john.stultz@linaro.org>
      Tested-by: NValentin Schneider <valentin.schneider@arm.com>
      Tested-by: NTuomas Tynkkynen <tuomas@tuxera.com>
      Tested-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      f6cc0c50
    • Y
      Fix kexec forbidding kernels signed with keys in the secondary keyring to boot · ea93102f
      Yannik Sembritzki 提交于
      The split of .system_keyring into .builtin_trusted_keys and
      .secondary_trusted_keys broke kexec, thereby preventing kernels signed by
      keys which are now in the secondary keyring from being kexec'd.
      
      Fix this by passing VERIFY_USE_SECONDARY_KEYRING to
      verify_pefile_signature().
      
      Fixes: d3bfe841 ("certs: Add a secondary system keyring that can be added to dynamically")
      Signed-off-by: NYannik Sembritzki <yannik@sembritzki.me>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: kexec@lists.infradead.org
      Cc: keyrings@vger.kernel.org
      Cc: linux-security-module@vger.kernel.org
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ea93102f
  4. 16 8月, 2018 2 次提交
  5. 15 8月, 2018 3 次提交
  6. 13 8月, 2018 23 次提交
  7. 11 8月, 2018 2 次提交
    • A
      lib/ubsan: remove null-pointer checks · 3ca17b1f
      Andrey Ryabinin 提交于
      With gcc-8 fsanitize=null become very noisy.  GCC started to complain
      about things like &a->b, where 'a' is NULL pointer.  There is no NULL
      dereference, we just calculate address to struct member.  It's
      technically undefined behavior so UBSAN is correct to report it.  But as
      long as there is no real NULL-dereference, I think, we should be fine.
      
      -fno-delete-null-pointer-checks compiler flag should protect us from any
      consequences.  So let's just no use -fsanitize=null as it's not useful
      for us.  If there is a real NULL-deref we will see crash.  Even if
      userspace mapped something at NULL (root can do this), with things like
      SMAP should catch the issue.
      
      Link: http://lkml.kernel.org/r/20180802153209.813-1-aryabinin@virtuozzo.comSigned-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ca17b1f
    • J
      x86/mm/pti: Move user W+X check into pti_finalize() · d878efce
      Joerg Roedel 提交于
      The user page-table gets the updated kernel mappings in pti_finalize(),
      which runs after the RO+X permissions got applied to the kernel page-table
      in mark_readonly().
      
      But with CONFIG_DEBUG_WX enabled, the user page-table is already checked in
      mark_readonly() for insecure mappings.  This causes false-positive
      warnings, because the user page-table did not get the updated mappings yet.
      
      Move the W+X check for the user page-table into pti_finalize() after it
      updated all required mappings.
      
      [ tglx: Folded !NX supported fix ]
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: linux-mm@kvack.org
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: David Laight <David.Laight@aculab.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Eduardo Valentin <eduval@amazon.com>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: aliguori@amazon.com
      Cc: daniel.gruss@iaik.tugraz.at
      Cc: hughd@google.com
      Cc: keescook@google.com
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Waiman Long <llong@redhat.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: "David H . Gutteridge" <dhgutteridge@sympatico.ca>
      Cc: joro@8bytes.org
      Link: https://lkml.kernel.org/r/1533727000-9172-1-git-send-email-joro@8bytes.org
      d878efce