1. 04 10月, 2018 2 次提交
  2. 02 10月, 2018 2 次提交
  3. 21 9月, 2018 6 次提交
  4. 19 9月, 2018 2 次提交
  5. 17 9月, 2018 1 次提交
  6. 14 9月, 2018 2 次提交
  7. 08 9月, 2018 4 次提交
    • N
      x86/mm: Use WRITE_ONCE() when setting PTEs · 9bc4f28a
      Nadav Amit 提交于
      When page-table entries are set, the compiler might optimize their
      assignment by using multiple instructions to set the PTE. This might
      turn into a security hazard if the user somehow manages to use the
      interim PTE. L1TF does not make our lives easier, making even an interim
      non-present PTE a security hazard.
      
      Using WRITE_ONCE() to set PTEs and friends should prevent this potential
      security hazard.
      
      I skimmed the differences in the binary with and without this patch. The
      differences are (obviously) greater when CONFIG_PARAVIRT=n as more
      code optimizations are possible. For better and worse, the impact on the
      binary with this patch is pretty small. Skimming the code did not cause
      anything to jump out as a security hazard, but it seems that at least
      move_soft_dirty_pte() caused set_pte_at() to use multiple writes.
      Signed-off-by: NNadav Amit <namit@vmware.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Sean Christopherson <sean.j.christopherson@intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20180902181451.80520-1-namit@vmware.com
      9bc4f28a
    • T
      x86/apic/vector: Make error return value negative · 47b7360c
      Thomas Gleixner 提交于
      activate_managed() returns EINVAL instead of -EINVAL in case of
      error. While this is unlikely to happen, the positive return value would
      cause further malfunction at the call site.
      
      Fixes: 2db1f959 ("x86/vector: Handle managed interrupts proper")
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      47b7360c
    • W
      KVM: LAPIC: Fix pv ipis out-of-bounds access · bdf7ffc8
      Wanpeng Li 提交于
      Dan Carpenter reported that the untrusted data returns from kvm_register_read()
      results in the following static checker warning:
        arch/x86/kvm/lapic.c:576 kvm_pv_send_ipi()
        error: buffer underflow 'map->phys_map' 's32min-s32max'
      
      KVM guest can easily trigger this by executing the following assembly sequence
      in Ring0:
      
      mov $10, %rax
      mov $0xFFFFFFFF, %rbx
      mov $0xFFFFFFFF, %rdx
      mov $0, %rsi
      vmcall
      
      As this will cause KVM to execute the following code-path:
      vmx_handle_exit() -> handle_vmcall() -> kvm_emulate_hypercall() -> kvm_pv_send_ipi()
      which will reach out-of-bounds access.
      
      This patch fixes it by adding a check to kvm_pv_send_ipi() against map->max_apic_id,
      ignoring destinations that are not present and delivering the rest. We also check
      whether or not map->phys_map[min + i] is NULL since the max_apic_id is set to the
      max apic id, some phys_map maybe NULL when apic id is sparse, especially kvm
      unconditionally set max_apic_id to 255 to reserve enough space for any xAPIC ID.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: NLiran Alon <liran.alon@oracle.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Liran Alon <liran.alon@oracle.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NWanpeng Li <wanpengli@tencent.com>
      [Add second "if (min > map->max_apic_id)" to complete the fix. -Radim]
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      bdf7ffc8
    • L
      KVM: nVMX: Fix loss of pending IRQ/NMI before entering L2 · b5861e5c
      Liran Alon 提交于
      Consider the case L1 had a IRQ/NMI event until it executed
      VMLAUNCH/VMRESUME which wasn't delivered because it was disallowed
      (e.g. interrupts disabled). When L1 executes VMLAUNCH/VMRESUME,
      L0 needs to evaluate if this pending event should cause an exit from
      L2 to L1 or delivered directly to L2 (e.g. In case L1 don't intercept
      EXTERNAL_INTERRUPT).
      
      Usually this would be handled by L0 requesting a IRQ/NMI window
      by setting VMCS accordingly. However, this setting was done on
      VMCS01 and now VMCS02 is active instead. Thus, when L1 executes
      VMLAUNCH/VMRESUME we force L0 to perform pending event evaluation by
      requesting a KVM_REQ_EVENT.
      
      Note that above scenario exists when L1 KVM is about to enter L2 but
      requests an "immediate-exit". As in this case, L1 will
      disable-interrupts and then send a self-IPI before entering L2.
      Reviewed-by: NNikita Leshchenko <nikita.leshchenko@oracle.com>
      Co-developed-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: NLiran Alon <liran.alon@oracle.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      b5861e5c
  8. 07 9月, 2018 4 次提交
  9. 06 9月, 2018 2 次提交
  10. 05 9月, 2018 5 次提交
  11. 04 9月, 2018 10 次提交
    • J
      KVM: s390: Properly lock mm context allow_gmap_hpage_1m setting · df88f318
      Janosch Frank 提交于
      We have to do down_write on the mm semaphore to set a bitfield in the
      mm context.
      Signed-off-by: NJanosch Frank <frankja@linux.ibm.com>
      Fixes: a4499382 ("KVM: s390: Add huge page enablement control")
      Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      df88f318
    • P
      KVM: s390: vsie: copy wrapping keys to right place · 204c9724
      Pierre Morel 提交于
      Copy the key mask to the right offset inside the shadow CRYCB
      
      Fixes: bbeaa58b ("KVM: s390: vsie: support aes dea wrapping keys")
      Signed-off-by: NPierre Morel <pmorel@linux.ibm.com>
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Reviewed-by: NCornelia Huck <cohuck@redhat.com>
      Reviewed-by: NJanosch Frank <frankja@linux.ibm.com>
      Cc: stable@vger.kernel.org # v4.8+
      Message-Id: <1535019956-23539-2-git-send-email-pmorel@linux.ibm.com>
      Signed-off-by: NJanosch Frank <frankja@linux.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      204c9724
    • J
      KVM: s390: Fix pfmf and conditional skey emulation · a11bdb1a
      Janosch Frank 提交于
      We should not return with a lock.
      We also have to increase the address when we do page clearing.
      
      Fixes: bd096f64 ("KVM: s390: Add skey emulation fault handling")
      Signed-off-by: NJanosch Frank <frankja@linux.ibm.com>
      Message-Id: <20180830081355.59234-1-frankja@linux.ibm.com>
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      a11bdb1a
    • G
      nds32: fix build error because of wrong semicolon · ec865393
      Greentime Hu 提交于
      It shall be removed in the define usage. We shall not put a semicolon there.
      
      /kisskb/src/arch/nds32/include/asm/elf.h:126:29: error: expected '}' before ';' token
       #define ELF_DATA ELFDATA2LSB;
                                   ^
      /kisskb/src/fs/proc/kcore.c:318:17: note: in expansion of macro 'ELF_DATA'
           [EI_DATA] = ELF_DATA,
                       ^~~~~~~~
      /kisskb/src/fs/proc/kcore.c:312:15: note: to match this '{'
          .e_ident = {
                     ^
      /kisskb/src/scripts/Makefile.build:307: recipe for target 'fs/proc/kcore.o' failed
      Signed-off-by: NGreentime Hu <greentime@andestech.com>
      ec865393
    • G
      nds32: Fix a kernel panic issue because of wrong frame pointer access. · 0cde56e0
      Greentime Hu 提交于
      It can make sure that trace_hardirqs_off/trace_hardirqs_on can get a correct
      return address by frame pointer through __builtin_return_address() in this fix.
      
      Unable to handle kernel paging request at virtual address fffffffc
      pgd = 3c42e9cf
      [fffffffc] *pgd=02a9c000
      
      Internal error: Oops: 1 [#1]
      Modules linked in:
      CPU: 0
      PC is at trace_hardirqs_off+0x78/0xec
      LP is at common_exception_handler+0xda/0xf4
      pc : [<b23ea5a4>]    lp : [<b2352eba>]    Tainted: G        W
      sp : ada60ab0  fp : efcaff48  gp : 3a020490
      r25: efcb0000  r24: 00000000
      r23: 00000000  r22: 00000000  r21: 00000000  r20: 000700c1
      r19: 000700ca  r18: 3a21b018  r17: 00000001  r16: 00000002
      r15: 00000001  r14: 0000002a  r13: 3a00a804  r12: ada60ab0
      r11: 3a113af8  r10: 3a01c530  r9 : 3a124404  r8 : 00120f9c
      r7 : b2352eba  r6 : 00000000  r5 : 3a126b58  r4 : 00000000
      r3 : 3a1726a8  r2 : b2921000  r1 : 00000000  r0 : 00000000
        IRQs off  Segment user
      Process init (pid: 1, stack limit = 0x069d7f15)
      Stack: (0xada60ab0 to 0xada61000)
      Stack: 0aa0:                                     00000000 00000003 3a110000 0011f000
      Stack: 0ac0: 00000005 00000000 00000000 00000000 ada60b10 3a01fe68 ada60b0c ada60b08
      Stack: 0ae0: 00000000 ada60ab8 ada60b30 3a020550 00000000 00000001 3a11c2f8 3a01c6e8
      Stack: 0b00: 3a01cb80 fffffba8 3a113af8 3a21b018 3a122c28 00003ec4 00000165 00000000
      Stack: 0b20: 3a126aec 0000006c 00000000 00000001 3a01fe68 00000000 00000003 00000000
      Stack: 0b40: 00000001 000003f8 3a020930 3a01c530 00000008 ada60c18 3a020490 3a003120
      Stack: 0b60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0b80: 00000000 00000000 00000000 00000000 ffff8000 00000000 00000000 00000000
      Stack: 0ba0: 00000000 00000001 3a020550 00000000 3a01d020 00000000 fffff000 fffff000
      Stack: 0bc0: 00000000 00000000 00000000 00000000 ada60f2c 00000000 00000001 00000000
      Stack: 0be0: 00000000 00000000 3a01fe68 fffffab0 00008034 00000008 3a0010cc 3a01fe68
      Stack: 0c00: 00000000 00000000 00000001 ada60c88 3a020490 3a0139d4 0009dc6f 00000000
      Stack: 0c20: 00000000 00000000 ada60fce fffff000 00000000 0000ebe0 3a020038 3a020550
      Stack: 0c40: ada60f20 ada60c90 3a0007f0 3a0002a8 ada60c8c 00000000 00000000 ada60c88
      Stack: 0c60: 3a020490 3a004570 00000000 00000000 ada60f20 3a0007f0 3a000000 00000000
      Stack: 0c80: 3a020490 3a004850 00000000 3a013f24 3a000000 00000000 3a01ff44 00000000
      Stack: 0ca0: 00000000 00000000 00000000 00000000 00000000 00000000 3a01ff84 3a01ff7c
      Stack: 0cc0: 3a01ff4c 3a01ff5c 3a01ff64 3a01ff9c 3a01ffa4 3a01ffac 3a01ff6c 3a01ff74
      Stack: 0ce0: 00000000 00000000 3a01ff44 00000000 00000000 00000000 00000000 00000000
      Stack: 0d00: 3a01ff8c 00000000 00000000 3a01ff94 00000000 00000000 00000000 00000000
      Stack: 0d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0d40: 3a01ffbc 3a01ffb4 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0d60: 00000000 00000000 00000000 00000000 00000000 3a01ffc4 00000000 00000000
      Stack: 0d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0da0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0dc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3a01ff54
      Stack: 0de0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0e00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0e20: 00000000 00000004 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0e40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0e60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0e80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      Stack: 0ec0: 00000000 00000000 00000000 00000000 ffffffff 00000000 00000000 00000000
      Stack: 0ee0: 00000000 00000000 00000000 00000000 ada60f20 00000000 00000000 00000000
      Stack: 0f00: 00000000 00000000 00000000 00000000 00000000 00000000 3a020490 3a000b24
      Stack: 0f20: 00000001 ada60fde 00000000 ada60fe4 ada60feb 00000000 00000021 3a038000
      Stack: 0f40: 00000010 0009dc6f 00000006 00001000 00000011 00000064 00000003 00008034
      Stack: 0f60: 00000004 00000020 00000005 00000008 00000007 3a000000 00000008 00000000
      Stack: 0f80: 00000009 0000ebe0 0000000b 00000000 0000000c 00000000 0000000d 00000000
      Stack: 0fa0: 0000000e 00000000 00000017 00000000 00000019 ada60fce 0000001f ada60ff6
      Stack: 0fc0: 00000000 00000000 00000000 b5010000 fa839914 23b5dd89 a2aea540 692fc82e
      Stack: 0fe0: 0074696e 454d4f48 54002f3d 3d4d5245 756e696c 692f0078 0074696e 00000000
      CPU: 0 PID: 1 Comm: init Tainted: G        W         4.18.0-00015-g1888b64a2558-dirty #112
      Hardware name: andestech,ae3xx (DT)
      Call Trace:
      [<b27a8e34>] dump_stack+0x2c/0x38
      [<b2354874>] die+0x128/0x18c
      [<b2356f4c>] do_page_fault+0x3b8/0x4e0
      [<b2352ed4>] ret_from_exception+0x0/0x10
      [<b2352eba>] common_exception_handler+0xda/0xf4
      Signed-off-by: NGreentime Hu <greentime@andestech.com>
      0cde56e0
    • G
      nds32: Only print one page of stack when die to prevent printing too much information. · 487c4b23
      Greentime Hu 提交于
      It may print too much information sometimes if the stack is wrong or
      too big. This patch can limit the debug information in a page of stack.
      Signed-off-by: NGreentime Hu <greentime@andestech.com>
      487c4b23
    • Z
      nds32: Add macro definition for offset of lp register on stack · 95f93ed7
      Zong Li 提交于
      Use macro to replace the magic number.
      Signed-off-by: NZong Li <zong@andestech.com>
      Acked-by: NGreentime Hu <greentime@andestech.com>
      Signed-off-by: NGreentime Hu <greentime@andestech.com>
      95f93ed7
    • Z
      nds32: Remove the deprecated ABI implementation · c5fdf7e0
      Zong Li 提交于
      We are not using NDS32 ABI 2 for now, just remove the preprocessor
      directives __NDS32_ABI_2.
      Signed-off-by: NZong Li <zong@andestech.com>
      Acked-by: NGreentime Hu <greentime@andestech.com>
      Signed-off-by: NGreentime Hu <greentime@andestech.com>
      c5fdf7e0
    • Z
      nds32/stack: Get real return address by using ftrace_graph_ret_addr · 1e377ae9
      Zong Li 提交于
      Function graph tracer has modified the return address to
      'return_to_handler' on stack, and provide the 'ftrace_graph_ret_addr' to
      get the real return address.
      Signed-off-by: NZong Li <zong@andestech.com>
      Acked-by: NGreentime Hu <greentime@andestech.com>
      Signed-off-by: NGreentime Hu <greentime@andestech.com>
      1e377ae9
    • Z
      nds32/ftrace: Support dynamic function graph tracer · 95cd2f7b
      Zong Li 提交于
      This patch contains the implementation of dynamic function graph tracer.
      Signed-off-by: NZong Li <zong@andestech.com>
      Acked-by: NGreentime Hu <greentime@andestech.com>
      Signed-off-by: NGreentime Hu <greentime@andestech.com>
      95cd2f7b