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

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

powerpc/pseries: Fix to handle slb resize across migration

2009-09-24T15:47:37+00:00

commit 46db2f86a3b2a94e0b33e0b4548fb7b7b6bdff66 upstream.

The SLB can change sizes across a live migration, which was not
being handled, resulting in possible machine crashes during
migration if migrating to a machine which has a smaller max SLB
size than the source machine. Fix this by first reducing the
SLB size to the minimum possible value, which is 32, prior to
migration. Then during the device tree update which occurs after
migration, we make the call to ensure the SLB gets updated. Also
add the slb_size to the lparcfg output so that the migration
tools can check to make sure the kernel has this capability
before allowing migration in scenarios where the SLB size will change.

BenH: Fixed #include  ->  to avoid
      breaking ppc32 build

Signed-off-by: Brian King 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman