linux-toradex.git/arch/x86_64, branch v2.6.16.11

[PATCH] i386/x86-64: Fix x87 information leak between processes (CVE-2006-1056)

2006-04-19T05:54:44+00:00

AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE
when an exception is pending.  This means the value leak through context
switches and allow processes to observe some x87 instruction state of
other processes.

This was actually documented by AMD, but nobody recognized it as being
different from Intel before.

The fix first adds an optimization: instead of unconditionally calling
FNCLEX after each FXSAVE test if ES is pending and skip it when not
needed. Then do a x87 load from a kernel variable to clear FOP/FIP/FDP.

This means other processes always will only see a constant value defined
by the kernel in their FP state.

I took some pain to make sure to chose a variable that's already in L1
during context switch to make the overhead of this low.

Also alternative() is used to patch away the new code on CPUs who don't
need it.

Patch for both i386/x86-64.

The problem was discovered originally by Jan Beulich. Richard Brunner
provided the basic code for the workarounds, with contribution from Jan.

This is CVE-2006-1056

Cc: richard.brunner@amd.com
Cc: jbeulich@novell.com
Signed-off-by: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman

[PATCH] x86_64: When user could have changed RIP always force IRET (CVE-2006-0744)

2006-04-12T20:06:54+00:00

Intel EM64T CPUs handle uncanonical return addresses differently from
AMD CPUs.

The exception is reported in the SYSRET, not the next instruction.
Thgis leads to the kernel exception handler running on the user stack
with the wrong GS because the kernel didn't expect exceptions on this
instruction.

This version of the patch has the teething problems that plagued an
earlier version fixed.

This is CVE-2006-0744

Thanks to Ernie Petrides and Asit B. Mallick for analysis and initial
patches.

Signed-off-by: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman

[PATCH] x86_64: Clean up execve

2006-04-12T20:06:53+00:00

Just call IRET always, no need for any special cases.

Needed for the next bug fix.

Signed-off-by: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman

Revert "[PATCH] x86-64: Fix up handling of non canonical user RIPs"

2006-03-14T16:01:47+00:00

This reverts commit c33d4568aca9028a22857f94f5e0850012b6444b.

Andrew Clayton and Hugh Dickins report that it's broken for them and
causes strange page table and slab corruption, and spontaneous reboots.

Let's get it right next time.

Cc: Andrew Clayton 
Cc: Hugh Dickins 
Cc: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] x86-64: Fix up handling of non canonical user RIPs

2006-03-13T06:56:29+00:00

EM64T CPUs have somewhat weird error reporting for non canonical RIPs in
SYSRET.

We can't handle any exceptions there because the exception handler would
end up running on the user stack which is unsafe.

To avoid problems any code that might end up with a user touched pt_regs
should return using int_ret_from_syscall.  int_ret_from_syscall ends up
using IRET, which allows safe exceptions.

Cc: Ernie Petrides 
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] fix kexec asm

2006-03-08T22:15:04+00:00

While testing kexec and kdump we hit problems where the new kernel would
freeze or instantly reboot.  The easiest way to trigger it was to kexec a
kernel compiled for CONFIG_M586 on an athlon cpu.  Compiling for CONFIG_MK7
instead would work fine.

The patch fixes a few problems with the kexec inline asm.

Signed-off-by: Chris Mason 
Acked-by: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Revert "[PATCH] x86_64: Only do the clustered systems have unsynchronized TSC assumption on IBM systems"

2006-02-28T04:41:56+00:00

This reverts commit 13a229abc25640813f1480c0478dfc6bdbc1c19e.

Quoth Andi:
  "After some consideration and feedback from various people it turns
   out this wasn't that good an idea.  It has some problems and needs
   more work.  Since it was only an optimization anyways it's best to
   just back it out again for now."

Signed-off-by: Linus Torvalds

Make Kprobes depend on modules

2006-02-27T04:24:40+00:00

Commit 9ec4b1f356b3bad928ae8e2aa9caebfa737d52df made kprobes not compile
without module support, so just make that clear in the Kconfig file.

Also, since it's marked EXPERIMENTAL, make that dependency explicit too.

Signed-off-by: Linus Torvalds

[PATCH] fix build on x86_64 with !CONFIG_HOTPLUG_CPU

2006-02-27T03:07:42+00:00

The commit e2c0388866dc12bef56b178b958f9b778fe6c687 added
setup_additional_cpus to setup.c but this is only defined if
CONFIG_HOTPLUG_CPU is set.  This patch changes the #ifdef to reflect that.

Signed-off-by: Brian Magnuson 
Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds

[PATCH] x86_64: Better ATI timer fix

2006-02-26T17:53:31+00:00

The previous experiment for using apicmaintimer on ATI systems didn't
work out very well.  In particular laptops with C2/C3 support often
don't let it tick during idle, which makes it useless.  There were also
some other bugs that made the apicmaintimer often not used at all.

I tried some other experiments - running timer over RTC and some other
things but they didn't really work well neither.

I rechecked the specs now and it turns out this simple change is
actually enough to avoid the double ticks on the ATI systems.  We just
turn off IRQ 0 in the 8254 and only route it directly using the IO-APIC.

I tested it on a few ATI systems and it worked there.  In fact it worked
on all chipsets (NVidia, Intel, AMD, ATI) I tried it on.

According to the ACPI spec routing should always work through the
IO-APIC so I think it's the correct thing to do anyways (and most of the
old gunk in check_timer should be thrown away for x86-64).

But for 2.6.16 it's best to do a fairly minimal change:
 - Use the known to be working everywhere-but-ATI IRQ0 both over 8254
   and IO-APIC setup everywhere
 - Except on ATI disable IRQ0 in the 8254
 - Remove the code to select apicmaintimer on ATI chipsets
 - Add some boot options to allow to override this (just paranoia)

In 2.6.17 I hope to switch the default over to this for everybody.

Signed-off-by: Andi Kleen 
Signed-off-by: Linus Torvalds