1. 04 11月, 2014 1 次提交
  2. 03 11月, 2014 1 次提交
  3. 14 9月, 2014 1 次提交
    • D
      x86 early_ioremap: Increase FIX_BTMAPS_SLOTS to 8 · 3eddc69f
      Dave Young 提交于
      3.16 kernel boot fail with earlyprintk=efi, it keeps scrolling at the
      bottom line of screen.
      
      Bisected, the first bad commit is below:
      commit 86dfc6f3
      Author: Lv Zheng <lv.zheng@intel.com>
      Date:   Fri Apr 4 12:38:57 2014 +0800
      
          ACPICA: Tables: Fix table checksums verification before installation.
      
      I did some debugging by enabling both serial and efi earlyprintk, below is
      some debug dmesg, seems early_ioremap fails in scroll up function due to
      no free slot, see below dmesg output:
      
        WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:116 __early_ioremap+0x90/0x1c4()
        __early_ioremap(ed00c800, 00000c80) not found slot
        Modules linked in:
        CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-rc1+ #204
        Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013
        Call Trace:
          dump_stack+0x4e/0x7a
          warn_slowpath_common+0x75/0x8e
          ? __early_ioremap+0x90/0x1c4
          warn_slowpath_fmt+0x47/0x49
          __early_ioremap+0x90/0x1c4
          ? sprintf+0x46/0x48
          early_ioremap+0x13/0x15
          early_efi_map+0x24/0x26
          early_efi_scroll_up+0x6d/0xc0
          early_efi_write+0x1b0/0x214
          call_console_drivers.constprop.21+0x73/0x7e
          console_unlock+0x151/0x3b2
          ? vprintk_emit+0x49f/0x532
          vprintk_emit+0x521/0x532
          ? console_unlock+0x383/0x3b2
          printk+0x4f/0x51
          acpi_os_vprintf+0x2b/0x2d
          acpi_os_printf+0x43/0x45
          acpi_info+0x5c/0x63
          ? __acpi_map_table+0x13/0x18
          ? acpi_os_map_iomem+0x21/0x147
          acpi_tb_print_table_header+0x177/0x186
          acpi_tb_install_table_with_override+0x4b/0x62
          acpi_tb_install_standard_table+0xd9/0x215
          ? early_ioremap+0x13/0x15
          ? __acpi_map_table+0x13/0x18
          acpi_tb_parse_root_table+0x16e/0x1b4
          acpi_initialize_tables+0x57/0x59
          acpi_table_init+0x50/0xce
          acpi_boot_table_init+0x1e/0x85
          setup_arch+0x9b7/0xcc4
          start_kernel+0x94/0x42d
          ? early_idt_handlers+0x120/0x120
          x86_64_start_reservations+0x2a/0x2c
          x86_64_start_kernel+0xf3/0x100
      
      Quote reply from Lv.zheng about the early ioremap slot usage in this case:
      
      """
      In early_efi_scroll_up(), 2 mapping entries will be used for the src/dst screen buffer.
      In drivers/acpi/acpica/tbutils.c, we've improved the early table loading code in acpi_tb_parse_root_table().
      We now need 2 mapping entries:
      1. One mapping entry is used for RSDT table mapping. Each RSDT entry contains an address for another ACPI table.
      2. For each entry in RSDP, we need another mapping entry to map the table to perform necessary check/override before installing it.
      
      When acpi_tb_parse_root_table() prints something through EFI earlyprintk console, we'll have 4 mapping entries used.
      The current 4 slots setting of early_ioremap() seems to be too small for such a use case.
      """
      
      Thus increase the slot to 8 in this patch to fix this issue.
      boot-time mappings become 512 page with this patch.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Cc: <stable@vger.kernel.org> # v3.16
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      3eddc69f
  4. 06 5月, 2014 1 次提交
  5. 08 4月, 2014 1 次提交
  6. 14 3月, 2014 1 次提交
  7. 28 2月, 2014 1 次提交
  8. 24 1月, 2014 1 次提交
  9. 31 5月, 2013 1 次提交
  10. 12 4月, 2013 2 次提交
  11. 28 11月, 2012 1 次提交
  12. 18 12月, 2011 1 次提交
  13. 06 6月, 2011 1 次提交
    • A
      x86-64: Give vvars their own page · 9fd67b4e
      Andy Lutomirski 提交于
      Move vvars out of the vsyscall page into their own page and mark
      it NX.
      
      Without this patch, an attacker who can force a daemon to call
      some fixed address could wait until the time contains, say,
      0xCD80, and then execute the current time.
      Signed-off-by: NAndy Lutomirski <luto@mit.edu>
      Cc: Jesper Juhl <jj@chaosbits.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Jan Beulich <JBeulich@novell.com>
      Cc: richard -rw- weinberger <richard.weinberger@gmail.com>
      Cc: Mikael Pettersson <mikpe@it.uu.se>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Louis Rilling <Louis.Rilling@kerlabs.com>
      Cc: Valdis.Kletnieks@vt.edu
      Cc: pageexec@freemail.hu
      Link: http://lkml.kernel.org/r/b1460f81dc4463d66ea3f2b5ce240f58d48effec.1307292171.git.luto@mit.eduSigned-off-by: NIngo Molnar <mingo@elte.hu>
      9fd67b4e
  14. 11 1月, 2011 1 次提交
  15. 25 11月, 2010 1 次提交
  16. 11 11月, 2010 1 次提交
  17. 08 10月, 2010 1 次提交
    • F
      x86: Add two helper macros for fixed address mapping · 5a47c7da
      Feng Tang 提交于
      Sometimes fixmap will be used to map an physical address which
      is not PAGE align, so to use it we need first map it and then
      add the address offset to the mapped fixed address. These 2 new
      helpers are suggested by Ingo Molnar to make the process
      simpler.
      
      For a physicall address like "phys", a directly usable virtual
      address can be get by
      	virt = (void *)set_fixmap_offset(fixed_idx, phys);
      or
      	virt = (void *)set_fixmap_offset_nocache(fixed_idx, phys);
      (depends on whether the physical address is cachable or not).
      Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Cc: alan@linux.intel.com
      Cc: greg@kroah.com
      Cc: x86@kernel.org
      LKML-Reference: <1284361736-23011-3-git-send-email-feng.tang@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5a47c7da
  18. 16 3月, 2010 1 次提交
  19. 30 12月, 2009 1 次提交
    • J
      x86: Lift restriction on the location of FIX_BTMAP_* · 499a5f1e
      Jan Beulich 提交于
      The early ioremap fixmap entries cover half (or for 32-bit
      non-PAE, a quarter) of a page table, yet they got
      uncondtitionally aligned so far to a 256-entry boundary. This is
      not necessary if the range of page table entries anyway falls
      into a single page table.
      
      This buys back, for (theoretically) 50% of all configurations
      (25% of all non-PAE ones), at least some of the lowmem
      necessarily lost with commit e621bd18.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <4B2BB66F0200007800026AD6@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      499a5f1e
  20. 22 7月, 2009 1 次提交
    • J
      x86, intel_txt: Intel TXT boot support · 31625340
      Joseph Cihula 提交于
      This patch adds kernel configuration and boot support for Intel Trusted
      Execution Technology (Intel TXT).
      
      Intel's technology for safer computing, Intel Trusted Execution
      Technology (Intel TXT), defines platform-level enhancements that
      provide the building blocks for creating trusted platforms.
      
      Intel TXT was formerly known by the code name LaGrande Technology (LT).
      
      Intel TXT in Brief:
      o  Provides dynamic root of trust for measurement (DRTM)
      o  Data protection in case of improper shutdown
      o  Measurement and verification of launched environment
      
      Intel TXT is part of the vPro(TM) brand and is also available some
      non-vPro systems.  It is currently available on desktop systems based on
      the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell Optiplex 755, HP
      dc7800, etc.) and mobile systems based on the GM45, PM45, and GS45
      Express chipsets.
      
      For more information, see http://www.intel.com/technology/security/.
      This site also has a link to the Intel TXT MLE Developers Manual, which
      has been updated for the new released platforms.
      
      A much more complete description of how these patches support TXT, how to
      configure a system for it, etc. is in the Documentation/intel_txt.txt file
      in this patch.
      
      This patch provides the TXT support routines for complete functionality,
      documentation for TXT support and for the changes to the boot_params structure,
      and boot detection of a TXT launch.  Attempts to shutdown (reboot, Sx) the system
      will result in platform resets; subsequent patches will support these shutdown modes
      properly.
      
       Documentation/intel_txt.txt      |  210 +++++++++++++++++++++
       Documentation/x86/zero-page.txt  |    1
       arch/x86/include/asm/bootparam.h |    3
       arch/x86/include/asm/fixmap.h    |    3
       arch/x86/include/asm/tboot.h     |  197 ++++++++++++++++++++
       arch/x86/kernel/Makefile         |    1
       arch/x86/kernel/setup.c          |    4
       arch/x86/kernel/tboot.c          |  379 +++++++++++++++++++++++++++++++++++++++
       security/Kconfig                 |   30 +++
       9 files changed, 827 insertions(+), 1 deletion(-)
      Signed-off-by: NJoseph Cihula <joseph.cihula@intel.com>
      Signed-off-by: NShane Wang <shane.wang@intel.com>
      Signed-off-by: NGang Wei <gang.wei@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      31625340
  21. 03 7月, 2009 1 次提交
    • M
      x86: Fix fixmap page order for FIX_TEXT_POKE0,1 · 12b9d7cc
      Mathieu Desnoyers 提交于
      Masami reported:
      
      > Since the fixmap pages are assigned higher address to lower,
      > text_poke() has to use it with inverted order (FIX_TEXT_POKE1
      > to FIX_TEXT_POKE0).
      
      I prefer to just invert the order of the fixmap declaration.
      It's simpler and more straightforward.
      
      Backward fixmaps seems to be used by both x86 32 and 64.
      
      It's really rare but a nasty bug, because it only hurts when
      instructions to patch are crossing a page boundary. If this
      happens, the fixmap write accesses will spill on the following
      fixmap, which may very well crash the system. And this does not
      crash the system, it could leave illegal instructions in place.
      Thanks Masami for finding this.
      
      It seems to have crept into the 2.6.30-rc series, so this calls
      for a -stable inclusion.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Acked-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <20090701213722.GH19926@Krystal>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      12b9d7cc
  22. 01 7月, 2009 1 次提交
    • J
      x86: Fix fixmap ordering · 789d03f5
      Jan Beulich 提交于
      The merge of the 32- and 64-bit fixmap headers made a latent
      bug on x86-64 a real one: with the right config settings
      it is possible for FIX_OHCI1394_BASE to overlap the FIX_BTMAP_*
      range.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: <stable@kernel.org> # for 2.6.30.x
      LKML-Reference: <4A4A0A8702000078000082E8@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      789d03f5
  23. 11 4月, 2009 1 次提交
  24. 10 4月, 2009 1 次提交
  25. 06 3月, 2009 1 次提交
  26. 28 2月, 2009 1 次提交
  27. 31 10月, 2008 1 次提交
  28. 23 10月, 2008 2 次提交
  29. 23 7月, 2008 1 次提交
    • V
      x86: consolidate header guards · 77ef50a5
      Vegard Nossum 提交于
      This patch is the result of an automatic script that consolidates the
      format of all the headers in include/asm-x86/.
      
      The format:
      
      1. No leading underscore. Names with leading underscores are reserved.
      2. Pathname components are separated by two underscores. So we can
         distinguish between mm_types.h and mm/types.h.
      3. Everything except letters and numbers are turned into single
         underscores.
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      77ef50a5
  30. 20 6月, 2008 3 次提交
  31. 26 4月, 2008 1 次提交
  32. 11 10月, 2007 1 次提交