1. 16 8月, 2017 1 次提交
    • M
      efi/arm64: add EFI_KIMG_ALIGN · 170976bc
      Mark Rutland 提交于
      The EFI stub is intimately coupled with the kernel, and takes advantage
      of this by relocating the kernel at a weaker alignment than the
      documented boot protocol mandates.
      
      However, it does so by assuming it can align the kernel to the segment
      alignment, and assumes that this is 64K. In subsequent patches, we'll
      have to consider other details to determine this de-facto alignment
      constraint.
      
      This patch adds a new EFI_KIMG_ALIGN definition that will track the
      kernel's de-facto alignment requirements. Subsequent patches will modify
      this as required.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Tested-by: NLaura Abbott <labbott@redhat.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      170976bc
  2. 13 7月, 2017 1 次提交
  3. 23 6月, 2017 3 次提交
    • D
      efi: Process the MEMATTR table only if EFI_MEMMAP is enabled · 457ea3f7
      Daniel Kiper 提交于
      Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.
      
      In theory we can check EFI_PARAVIRT too, however,
      EFI_MEMMAP looks more targeted and covers more cases.
      Signed-off-by: NDaniel Kiper <daniel.kiper@oracle.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: andrew.cooper3@citrix.com
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: linux-efi@vger.kernel.org
      Cc: matt@codeblueprint.co.uk
      Cc: stable@vger.kernel.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1498128697-12943-2-git-send-email-daniel.kiper@oracle.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      457ea3f7
    • T
      trace, ras: add ARM processor error trace event · e9279e83
      Tyler Baicar 提交于
      Currently there are trace events for the various RAS
      errors with the exception of ARM processor type errors.
      Add a new trace event for such errors so that the user
      will know when they occur. These trace events are
      consistent with the ARM processor error section type
      defined in UEFI 2.6 spec section N.2.4.4.
      Signed-off-by: NTyler Baicar <tbaicar@codeaurora.org>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      e9279e83
    • T
      efi: print unrecognized CPER section · 0fc300f4
      Tyler Baicar 提交于
      UEFI spec allows for non-standard section in Common Platform Error
      Record. This is defined in section N.2.3 of UEFI version 2.5.
      
      Currently if the CPER section's type (UUID) does not match with
      one of the section types that the kernel knows how to parse, the
      section is skipped. Therefore, user is not able to see
      such CPER data, for instance, error record of non-standard section.
      
      This change prints out the raw data in hex in the dmesg buffer so
      that non-standard sections are reported to the user. Non-standard
      section type errors should be reported to the user because these
      can include errors which are vendor specific. The data length is
      taken from Error Data length field of Generic Error Data Entry.
      
      The following is a sample output from dmesg:
       Hardware error from APEI Generic Hardware Error Source: 2
       It has been corrected by h/w and requires no further action
       event severity: corrected
        time: precise 2017-03-15 20:37:35
        Error 0, type: corrected
         section type: unknown, d2e2621c-f936-468d-0d84-15a4ed015c8b
         section length: 0x238
         00000000: 4d415201 4d492031 453a4d45 435f4343  .RAM1 IMEM:ECC_C
         00000010: 53515f45 44525f42 00000000 00000000  E_QSB_RD........
         00000020: 00000000 00000000 00000000 00000000  ................
         00000030: 00000000 00000000 01010000 01010000  ................
         00000040: 00000000 00000000 00000005 00000000  ................
         00000050: 01010000 00000000 00000001 00dddd00  ................
      ...
      
      The raw data from the error can then be decoded using vendor
      specific tools.
      Signed-off-by: NTyler Baicar <tbaicar@codeaurora.org>
      CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
      Reviewed-by: NJames Morse <james.morse@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      0fc300f4
  4. 22 6月, 2017 3 次提交
  5. 20 6月, 2017 1 次提交
  6. 15 6月, 2017 4 次提交
  7. 14 6月, 2017 1 次提交
  8. 13 6月, 2017 1 次提交
  9. 09 6月, 2017 1 次提交
    • D
      efi: Fix boot panic because of invalid BGRT image address · 792ef14d
      Dave Young 提交于
      Maniaxx reported a kernel boot crash in the EFI code, which I emulated
      by using same invalid phys addr in code:
      
        BUG: unable to handle kernel paging request at ffffffffff280001
        IP: efi_bgrt_init+0xfb/0x153
        ...
        Call Trace:
         ? bgrt_init+0xbc/0xbc
         acpi_parse_bgrt+0xe/0x12
         acpi_table_parse+0x89/0xb8
         acpi_boot_init+0x445/0x4e2
         ? acpi_parse_x2apic+0x79/0x79
         ? dmi_ignore_irq0_timer_override+0x33/0x33
         setup_arch+0xb63/0xc82
         ? early_idt_handler_array+0x120/0x120
         start_kernel+0xb7/0x443
         ? early_idt_handler_array+0x120/0x120
         x86_64_start_reservations+0x29/0x2b
         x86_64_start_kernel+0x154/0x177
         secondary_startup_64+0x9f/0x9f
      
      There is also a similar bug filed in bugzilla.kernel.org:
      
        https://bugzilla.kernel.org/show_bug.cgi?id=195633
      
      The crash is caused by this commit:
      
        7b0a9114 efi/x86: Move the EFI BGRT init code to early init code
      
      The root cause is the firmware on those machines provides invalid BGRT
      image addresses.
      
      In a kernel before above commit BGRT initializes late and uses ioremap()
      to map the image address. Ioremap validates the address, if it is not a
      valid physical address ioremap() just fails and returns. However in current
      kernel EFI BGRT initializes early and uses early_memremap() which does not
      validate the image address, and kernel panic happens.
      
      According to ACPI spec the BGRT image address should fall into
      EFI_BOOT_SERVICES_DATA, see the section 5.2.22.4 of below document:
      
        http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf
      
      Fix this issue by validating the image address in efi_bgrt_init(). If the
      image address does not fall into any EFI_BOOT_SERVICES_DATA areas we just
      bail out with a warning message.
      Reported-by: NManiaxx <tripleshiftone@gmail.com>
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 7b0a9114 ("efi/x86: Move the EFI BGRT init code to early init code")
      Link: http://lkml.kernel.org/r/20170609084558.26766-2-ard.biesheuvel@linaro.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      792ef14d
  10. 05 6月, 2017 12 次提交
  11. 01 6月, 2017 2 次提交
    • K
      pstore: Populate pstore record->time field · c7f3c595
      Kees Cook 提交于
      The current time will be initially available in the record->time field
      for all pstore_read() and pstore_write() calls. Backends can either
      update the field during read(), or use the field during write() instead
      of fetching time themselves.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      c7f3c595
    • K
      efi-pstore: Refactor erase routine · efb74e4b
      Kees Cook 提交于
      Right now, every pass through the EFI variables during erase would build
      a copy of the old format variable name. Instead, try each name one time
      through the EFI variables list. Additionally bump up the buffer size to
      avoid truncation in pathological cases, and wipe the write name buffer.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      efb74e4b
  12. 28 5月, 2017 2 次提交
  13. 27 5月, 2017 1 次提交
  14. 25 5月, 2017 7 次提交