1. 04 9月, 2009 1 次提交
    • J
      x86/i386: Make sure stack-protector segment base is cache aligned · 1ea0d14e
      Jeremy Fitzhardinge 提交于
      The Intel Optimization Reference Guide says:
      
      	In Intel Atom microarchitecture, the address generation unit
      	assumes that the segment base will be 0 by default. Non-zero
      	segment base will cause load and store operations to experience
      	a delay.
      		- If the segment base isn't aligned to a cache line
      		  boundary, the max throughput of memory operations is
      		  reduced to one [e]very 9 cycles.
      	[...]
      	Assembly/Compiler Coding Rule 15. (H impact, ML generality)
      	For Intel Atom processors, use segments with base set to 0
      	whenever possible; avoid non-zero segment base address that is
      	not aligned to cache line boundary at all cost.
      
      We can't avoid having a non-zero base for the stack-protector
      segment, but we can make it cache-aligned.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: <stable@kernel.org>
      LKML-Reference: <4AA01893.6000507@goop.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1ea0d14e
  2. 08 8月, 2009 1 次提交
  3. 20 7月, 2009 1 次提交
  4. 11 2月, 2009 1 次提交
    • T
      x86: fix x86_32 stack protector bugs · 5c79d2a5
      Tejun Heo 提交于
      Impact: fix x86_32 stack protector
      
      Brian Gerst found out that %gs was being initialized to stack_canary
      instead of stack_canary - 20, which basically gave the same canary
      value for all threads.  Fixing this also exposed the following bugs.
      
      * cpu_idle() didn't call boot_init_stack_canary()
      
      * stack canary switching in switch_to() was being done too late making
        the initial run of a new thread use the old stack canary value.
      
      Fix all of them and while at it update comment in cpu_idle() about
      calling boot_init_stack_canary().
      Reported-by: NBrian Gerst <brgerst@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5c79d2a5
  5. 10 2月, 2009 2 次提交
    • T
      x86: implement x86_32 stack protector · 60a5317f
      Tejun Heo 提交于
      Impact: stack protector for x86_32
      
      Implement stack protector for x86_32.  GDT entry 28 is used for it.
      It's set to point to stack_canary-20 and have the length of 24 bytes.
      CONFIG_CC_STACKPROTECTOR turns off CONFIG_X86_32_LAZY_GS and sets %gs
      to the stack canary segment on entry.  As %gs is otherwise unused by
      the kernel, the canary can be anywhere.  It's defined as a percpu
      variable.
      
      x86_32 exception handlers take register frame on stack directly as
      struct pt_regs.  With -fstack-protector turned on, gcc copies the
      whole structure after the stack canary and (of course) doesn't copy
      back on return thus losing all changed.  For now, -fno-stack-protector
      is added to all files which contain those functions.  We definitely
      need something better.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      60a5317f
    • T
      x86: stackprotector.h misc update · 76397f72
      Tejun Heo 提交于
      Impact: misc udpate
      
      * wrap content with CONFIG_CC_STACK_PROTECTOR so that other arch files
        can include it directly
      
      * add missing includes
      
      This will help future changes.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      76397f72
  6. 20 1月, 2009 2 次提交
    • B
      x86: move stack_canary into irq_stack · 947e76cd
      Brian Gerst 提交于
      Impact: x86_64 percpu area layout change, irq_stack now at the beginning
      
      Now that the PDA is empty except for the stack canary, it can be removed.
      The irqstack is moved to the start of the per-cpu section.  If the stack
      protector is enabled, the canary overlaps the bottom 48 bytes of the irqstack.
      
      tj: * updated subject
          * dropped asm relocation of irq_stack_ptr
          * updated comments a bit
          * rebased on top of stack canary changes
      Signed-off-by: NBrian Gerst <brgerst@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      947e76cd
    • T
      x86: cleanup stack protector · c6e50f93
      Tejun Heo 提交于
      Impact: cleanup
      
      Make the following cleanups.
      
      * remove duplicate comment from boot_init_stack_canary() which fits
        better in the other place - cpu_idle().
      
      * move stack_canary offset check from __switch_to() to
        boot_init_stack_canary().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      c6e50f93