linux-toradex.git/arch, branch v2.6.27.41

Enable ACPI PDC handshake for VIA/Centaur CPUs

2009-12-08T19:17:17+00:00

commit d77b81974521c82fa6fda38dfff1b491dcc62a32 upstream.

In commit 0de51088e6a82bc8413d3ca9e28bbca2788b5b53, we introduced the
use of acpi-cpufreq on VIA/Centaur CPU's by removing a vendor check for
VENDOR_INTEL.  However, as it turns out, at least the Nano CPU's also
need the PDC (processor driver capabilities) handshake in order to
activate the methods required for acpi-cpufreq.

Since arch_acpi_processor_init_pdc() contains another vendor check for
Intel, the PDC is not initialized on VIA CPU's.  The resulting behavior
of a current mainline kernel on such systems is:  acpi-cpufreq
loads and it indicates CPU frequency changes.  However, the CPU stays at
a single frequency

This trivial patch ensures that init_intel_pdc() is called on Intel and
VIA/Centaur CPU's alike.

Signed-off-by: Harald Welte 
Signed-off-by: Dave Jones 
Signed-off-by: Greg Kroah-Hartman

x86/amd-iommu: Workaround for erratum 63

2009-11-10T00:52:48+00:00

commit c5cca146aa03e1f60fb179df65f0dbaf17bc64ed upstream.

There is an erratum for IOMMU hardware which documents
undefined behavior when forwarding SMI requests from
peripherals and the DTE of that peripheral has a sysmgt
value of 01b. This problem caused weird IO_PAGE_FAULTS in my
case.
This patch implements the suggested workaround for that
erratum into the AMD IOMMU driver.  The erratum is
documented with number 63.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

x86/amd-iommu: Un__init function required on shutdown

2009-11-10T00:52:46+00:00

commit ca0207114f1708b563f510b7781a360ec5b98359 upstream.

The function iommu_feature_disable is required on system
shutdown to disable the IOMMU but it is marked as __init.
This may result in a panic if the memory is reused. This
patch fixes this bug.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

KVM: Prevent overflow in KVM_GET_SUPPORTED_CPUID (CVE-2009-3638)

2009-11-10T00:52:26+00:00

commit 6a54435560efdab1a08f429a954df4d6c740bddf upstream.

The number of entries is multiplied by the entry size, which can
overflow on 32-bit hosts.  Bound the entry count instead.

Reported-by: David Wagner 
Signed-off-by: Avi Kivity 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86-64: Fix register leak in 32-bit syscall audting

2009-11-10T00:52:19+00:00

commit 81766741fe1eee3884219e8daaf03f466f2ed52f upstream.

Restoring %ebp after the call to audit_syscall_exit() is not
only unnecessary (because the register didn't get clobbered),
but in the sysenter case wasn't even doing the right thing: It
loaded %ebp from a location below the top of stack (RBP <
ARGOFFSET), i.e. arbitrary kernel data got passed back to user
mode in the register.

Signed-off-by: Jan Beulich 
Acked-by: Roland McGrath 
LKML-Reference: <4AE5CC4D020000780001BD13@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

tty: Mark generic_serial users as BROKEN

2009-11-10T00:52:18+00:00

commit 412145947adfca60a4b5b4893fbae82dffa25edd upstream.

There isn't much else I can do with these. I can find no hardware for any
of them and no users. The code is broken.

Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

KVM: x86: Disallow hypercalls for guest callers in rings > 0 [CVE-2009-3290]

2009-10-12T18:33:20+00:00

[ backport to 2.6.27 by Chuck Ebbert  ]

commit 07708c4af1346ab1521b26a202f438366b7bcffd upstream.

So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random addresses.

To close the hole, this patch considers hypercalls valid only if issued
from guest ring 0. This may still be relaxed on a per-hypercall base in
the future once required.

Signed-off-by: Jan Kiszka 
Signed-off-by: Avi Kivity 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86: Increase MIN_GAP to include randomized stack

2009-10-12T18:33:15+00:00

[ trivial backport to 2.6.27: Chuck Ebbert  ]

commit 80938332d8cf652f6b16e0788cf0ca136befe0b5 upstream.

Currently we are not including randomized stack size when calculating
mmap_base address in arch_pick_mmap_layout for topdown case. This might
cause that mmap_base starts in the stack reserved area because stack is
randomized by 1GB for 64b (8MB for 32b) and the minimum gap is 128MB.

If the stack really grows down to mmap_base then we can get silent mmap
region overwrite by the stack values.

Let's include maximum stack randomization size into MIN_GAP which is
used as the low bound for the gap in mmap.

Signed-off-by: Michal Hocko 
LKML-Reference: <1252400515-6866-1-git-send-email-mhocko@suse.cz>
Acked-by: Jiri Kosina 
Signed-off-by: H. Peter Anvin 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86: Don't leak 64-bit kernel register values to 32-bit processes

2009-10-12T18:32:58+00:00

commit 24e35800cdc4350fc34e2bed37b608a9e13ab3b6 upstream

x86: Don't leak 64-bit kernel register values to 32-bit processes

While 32-bit processes can't directly access R8...R15, they can
gain access to these registers by temporarily switching themselves
into 64-bit mode.

Therefore, registers not preserved anyway by called C functions
(i.e. R8...R11) must be cleared prior to returning to user mode.

Signed-off-by: Jan Beulich 
LKML-Reference: <4AC34D73020000780001744A@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86-64: slightly stream-line 32-bit syscall entry code

2009-10-12T18:32:51+00:00

commit 295286a89107c353b9677bc604361c537fd6a1c0 upstream

x86-64: slightly stream-line 32-bit syscall entry code

[ required for following patch to apply properly ]

Avoid updating registers or memory twice as well as needlessly loading
or copying registers.

Signed-off-by: Jan Beulich 
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman