1. 17 11月, 2009 2 次提交
    • K
      x86, mm: Report state of NX protections during boot · 4b0f3b81
      Kees Cook 提交于
      It is possible for x86_64 systems to lack the NX bit either due to the
      hardware lacking support or the BIOS having turned off the CPU capability,
      so NX status should be reported.  Additionally, anyone booting NX-capable
      CPUs in 32bit mode without PAE will lack NX functionality, so this change
      provides feedback for that case as well.
      Signed-off-by: NKees Cook <kees.cook@canonical.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <1258154897-6770-6-git-send-email-hpa@zytor.com>
      4b0f3b81
    • H
      x86, mm: Clean up and simplify NX enablement · 4763ed4d
      H. Peter Anvin 提交于
      The 32- and 64-bit code used very different mechanisms for enabling
      NX, but even the 32-bit code was enabling NX in head_32.S if it is
      available.  Furthermore, we had a bewildering collection of tests for
      the available of NX.
      
      This patch:
      
      a) merges the 32-bit set_nx() and the 64-bit check_efer() function
         into a single x86_configure_nx() function.  EFER control is left
         to the head code.
      
      b) eliminates the nx_enabled variable entirely.  Things that need to
         test for NX enablement can verify __supported_pte_mask directly,
         and cpu_has_nx gives the supported status of NX.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Vegard Nossum <vegardno@ifi.uio.no>
      Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      LKML-Reference: <1258154897-6770-5-git-send-email-hpa@zytor.com>
      Acked-by: NKees Cook <kees.cook@canonical.com>
      4763ed4d
  2. 12 11月, 2009 1 次提交
  3. 13 10月, 2009 2 次提交
    • D
      x86: Export srat physical topology · 8716273c
      David Rientjes 提交于
      This is the counterpart to "x86: export k8 physical topology" for
      SRAT. It is not as invasive because the acpi code already seperates
      node setup into detection and registration steps, with the
      exception of registering e820 active regions in
      acpi_numa_memory_affinity_init().  This is now moved to
      acpi_scan_nodes() if NUMA emulation is disabled or deferred.
      
      acpi_numa_init() now returns a value which specifies whether an
      underlying SRAT was located.  If so, that topology can be used by
      the emulation code to interleave emulated nodes over physical nodes
      or to register the nodes for ACPI.
      
      acpi_get_nodes() may now be used to export the srat physical
      topology of the machine for NUMA emulation.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Ankita Garg <ankita@in.ibm.com>
      Cc: Len Brown <len.brown@intel.com>
      LKML-Reference: <alpine.DEB.1.00.0909251518580.14754@chino.kir.corp.google.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8716273c
    • D
      x86: Export k8 physical topology · 8ee2debc
      David Rientjes 提交于
      To eventually interleave emulated nodes over physical nodes, we
      need to know the physical topology of the machine without actually
      registering it.  This does the k8 node setup in two parts:
      detection and registration.  NUMA emulation can then used the
      physical topology detected to setup the address ranges of emulated
      nodes accordingly.  If emulation isn't used, the k8 nodes are
      registered as normal.
      
      Two formals are added to the x86 NUMA setup functions: `acpi' and
      `k8'. These represent whether ACPI or K8 NUMA has been detected;
      both cannot be true at the same time.  This specifies to the NUMA
      emulation code whether an underlying physical NUMA topology exists
      and which interface to use.
      
      This patch deals solely with separating the k8 setup path into
      Northbridge detection and registration steps and leaves the ACPI
      changes for a subsequent patch.  The `acpi' formal is added here,
      however, to avoid touching all the header files again in the next
      patch.
      
      This approach also ensures emulated nodes will not span physical
      nodes so the true memory latency is not misrepresented.
      
      k8_get_nodes() may now be used to export the k8 physical topology
      of the machine for NUMA emulation.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Ankita Garg <ankita@in.ibm.com>
      Cc: Len Brown <len.brown@intel.com>
      LKML-Reference: <alpine.DEB.1.00.0909251518400.14754@chino.kir.corp.google.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8ee2debc
  4. 20 9月, 2009 1 次提交
    • Y
      Revert 'x86: Fix system crash when loading with "reservetop" parameter' · eda6da92
      Yinghai Lu 提交于
      After close looking, commit 8126dec3 will break:
      
       1. some cpu feature  in early stage too, like cpu_has_x2apic
       2. will break built-in-command line
       3. will break other memmap= and mem=
       4. early_dbgp and early_console that will use early_ioremap to access mmio (?)
      
      So revert it.
      
      Reported-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>,
      Cc: Linus Torvalds <torvalds@linux-foundation.org>,
      Cc: Andrew Morton <akpm@linux-foundation.org>,
      LKML-Reference: <4AB51DFD.2000904@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      eda6da92
  5. 02 9月, 2009 1 次提交
  6. 01 9月, 2009 1 次提交
  7. 31 8月, 2009 9 次提交
  8. 29 8月, 2009 2 次提交
    • J
      x86: Fix earlyprintk=dbgp for machines without NX · 47d25003
      Jan Beulich 提交于
      Since parse_early_param() may (e.g. for earlyprintk=dbgp)
      involve calls to page table manipulation functions (here
      set_fixmap_nocache()), NX hardware support must be determined
      before calling that function (so that __supported_pte_mask gets
      properly set up).
      
      But the call after parse_early_param() can also not go away, as
      that will honor eventual command line specified disabling of
      the NX functionality.
      
      ( This will then just result in whatever mappings got
        established during parse_early_param() having the NX bit set
        despite it being disabled on the command line, but I think
        that's tolerable).
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      LKML-Reference: <4A97F3BD02000078000121B9@vpn.id2.novell.com>
      [ merged to x86/pat to resolve a conflict. ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      47d25003
    • F
      x86: add arch-specific SFI support · efafc8b2
      Feng Tang 提交于
      arch/x86/kernel/sfi.c serves the dual-purpose of supporting the
      SFI core with arch specific code, as well as a home for the
      arch-specific code that uses SFI.
      
      analogous to ACPI, drivers/sfi/Kconfig is pulled in by arch/x86/Kconfig
      Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Cc: x86@kernel.org
      efafc8b2
  9. 27 8月, 2009 2 次提交
  10. 21 8月, 2009 1 次提交
    • X
      x86: Fix system crash when loading with "reservetop" parameter · 8126dec3
      Xiao Guangrong 提交于
      The system will die if the kernel is booted with "reservetop"
      parameter, in present code, parse "reservetop" parameter after
      early_ioremap_init(), and some function still use
      early_ioremap() after it.
      
      The problem is, "reservetop" parameter can modify
      'FIXADDR_TOP', then the virtual address got by early_ioremap()
      is base on old 'FIXADDR_TOP', but the page mapping is base on
      new 'FIXADDR_TOP', it will occur page fault, and the IDT is not
      prepare yet, so, the system is dead.
      
      So, put parse_early_param() in the front of
      early_ioremap_init() in this patch.
      Signed-off-by: NXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      Cc: yinghai@kernel.org
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <4A8D402F.4080805@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8126dec3
  11. 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
  12. 18 7月, 2009 1 次提交
  13. 23 6月, 2009 1 次提交
    • P
      x86: Move init_gbpages() to setup_arch() · 854c879f
      Pekka J Enberg 提交于
      The init_gbpages() function is conditionally called from
      init_memory_mapping() function. There are two call-sites where
      this 'after_bootmem' condition can be true: setup_arch() and
      mem_init() via pci_iommu_alloc().
      
      Therefore, it's safe to move the call to init_gbpages() to
      setup_arch() as it's always called before mem_init().
      
      This removes an after_bootmem use - paving the way to remove
      all uses of that state variable.
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      LKML-Reference: <Pine.LNX.4.64.0906221731210.19474@melkki.cs.Helsinki.FI>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      854c879f
  14. 12 6月, 2009 1 次提交
  15. 12 5月, 2009 1 次提交
    • H
      x86: add extension fields for bootloader type and version · 5031296c
      H. Peter Anvin 提交于
      A long ago, in days of yore, it all began with a god named Thor.
      There were vikings and boats and some plans for a Linux kernel
      header.  Unfortunately, a single 8-bit field was used for bootloader
      type and version.  This has generally worked without *too* much pain,
      but we're getting close to flat running out of ID fields.
      
      Add extension fields for both type and version.  The type will be
      extended if it the old field is 0xE; the version is a simple MSB
      extension.
      
      Keep /proc/sys/kernel/bootloader_type containing
      (type << 4) + (ver & 0xf) for backwards compatiblity, but also add
      /proc/sys/kernel/bootloader_version which contains the full version
      number.
      
      [ Impact: new feature to support more bootloaders ]
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      5031296c
  16. 11 5月, 2009 1 次提交
  17. 30 4月, 2009 1 次提交
  18. 10 4月, 2009 1 次提交
  19. 30 3月, 2009 1 次提交
  20. 15 3月, 2009 5 次提交
    • J
      x86: allow extend_brk users to reserve brk space · 796216a5
      Jeremy Fitzhardinge 提交于
      Impact: new interface; remove hard-coded limit
      
      Add RESERVE_BRK(name, size) macro to reserve space in the brk
      area.  This should be a conservative (ie, larger) estimate of
      how much space might possibly be required from the brk area.
      Any unused space will be freed, so there's no real downside
      on making the reservation too large (within limits).
      
      The name should be unique within a given file, and somewhat
      descriptive.
      
      The C definition of RESERVE_BRK() ends up being more complex than
      one would expect to work around a cluster of gcc infelicities:
      
        The first attempt was to simply try putting __section(.brk_reservation)
        on a variable.  This doesn't work because it ends up making it a
        @progbits section, which gets actual space allocated in the vmlinux
        executable.
      
        The second attempt was to emit the space into a section using asm,
        but gcc doesn't allow arguments to be passed to file-level asm()
        statements, making it hard to pass in the size.
      
        The final attempt is to wrap the asm() in a function to allow
        it to have arguments, and put the function itself into the
        .discard section, which vmlinux*.lds drops entirely from the
        emitted vmlinux.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      796216a5
    • J
      x86: use brk allocation for DMI · 6de6cb44
      Jeremy Fitzhardinge 提交于
      Impact: use new interface instead of previous ad hoc implementation
      
      Use extend_brk() to allocate memory for DMI rather than having an
      ad-hoc allocator.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      6de6cb44
    • J
      x86-32: use brk segment for allocating initial kernel pagetable · ccf3fe02
      Jeremy Fitzhardinge 提交于
      Impact: use new interface instead of previous ad hoc implementation
      
      Rather than having special purpose init_pg_table_start/end variables
      to delimit the kernel pagetable built by head_32.S, just use the brk
      mechanism to extend the bss for the new pagetable.
      
      This patch removes init_pg_table_start/end and pg0, defines __brk_base
      (which is page-aligned and immediately follows _end), initializes
      the brk region to start there, and uses it for the 32-bit pagetable.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      ccf3fe02
    • H
      x86: move brk initialization out of #ifdef CONFIG_BLK_DEV_INITRD · 5368a2be
      H. Peter Anvin 提交于
      Impact: build fix
      
      The brk initialization functions were incorrectly located inside
      an #ifdef CONFIG_VLK_DEV_INITRD block, causing the obvious build failure in
      minimal configurations.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      5368a2be
    • J
      x86: add brk allocation for very, very early allocations · 93dbda7c
      Jeremy Fitzhardinge 提交于
      Impact: new interface
      
      Add a brk()-like allocator which effectively extends the bss in order
      to allow very early code to do dynamic allocations.  This is better than
      using statically allocated arrays for data in subsystems which may never
      get used.
      
      The space for brk allocations is in the bss ELF segment, so that the
      space is mapped properly by the code which maps the kernel, and so
      that bootloaders keep the space free rather than putting a ramdisk or
      something into it.
      
      The bss itself, delimited by __bss_stop, ends before the brk area
      (__brk_base to __brk_limit).  The kernel text, data and bss is reserved
      up to __bss_stop.
      
      Any brk-allocated data is reserved separately just before the kernel
      pagetable is built, as that code allocates from unreserved spaces
      in the e820 map, potentially allocating from any unused brk memory.
      Ultimately any unused memory in the brk area is used in the general
      kernel memory pool.
      
      Initially the brk space is set to 1MB, which is probably much larger
      than any user needs (the largest current user is i386 head_32.S's code
      to build the pagetables to map the kernel, which can get fairly large
      with a big kernel image and no PSE support).  So long as the system
      has sufficient memory for the bootloader to reserve the kernel+1MB brk,
      there are no bad effects resulting from an over-large brk.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      93dbda7c
  21. 05 3月, 2009 2 次提交
  22. 26 2月, 2009 2 次提交