similar to: [PATCH v2] x86: use fixed read-only IDT

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. We already did this on vendor == Intel and family == 5 because of the F0 0F bug -- regardless of if a particular CPU had the F0 0F bug

Make a copy of the IDT (as seen via the "sidt" instruction) read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks, and has the added benefit of also not leaking the kernel base offset, if it has been relocated. We already did this on vendor == Intel and family == 5 because of the F0 0F bug -- regardless of if a particular CPU had the F0 0F bug

This makes the IDT unconditionally read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks. It has an added benefit of also not leaking (via the "sidt" instruction) the kernel base offset, if it has been relocated. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Eric Northup <digitaleric at google.com> ---

This makes the IDT unconditionally read-only. This primarily removes the IDT from being a target for arbitrary memory write attacks. It has an added benefit of also not leaking (via the "sidt" instruction) the kernel base offset, if it has been relocated. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Eric Northup <digitaleric at google.com> ---

identify_cpu() is used to identify both the boot CPU and secondary CPUs, but it performs some actions which only apply to the boot CPU. Those functions are therefore really __init functions, but because they're called by identify_cpu(), they must be marked __cpuinit. This patch splits identify_cpu() into identify_boot_cpu() and identify_secondary_cpu(), and calls the appropriate init

identify_cpu() is used to identify both the boot CPU and secondary CPUs, but it performs some actions which only apply to the boot CPU. Those functions are therefore really __init functions, but because they're called by identify_cpu(), they must be marked __cpuinit. This patch splits identify_cpu() into identify_boot_cpu() and identify_secondary_cpu(), and calls the appropriate init

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hello, Anybody know the reason RedHat decided not to support the VIA Eden Processor? cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 13 model name : VIA Eden Processor 500MHz I am testing, (using ayplus kernel) and get the following during bootup: Linux version 2.6.32-71.24.1.el6.centos.ayplus.1.i686 (build at 6beta32) (gcc versi

Currently number of error reporting register banks is hardcoded to 6 on AMD processors. This may break in virtualized scenarios when a hypervisor prefers to report fewer banks that the physical HW provides. Since number of supported banks is reported in MSR_IA32_MCG_CAP[7:0] that''s what we should use. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> ---

Import upstream git commit e9dff0ee6694b2edd40b1b448cb786f6a7b02336 [PATCH] i386: mark cpu cache functions as __cpuinit Mark i386-specific cpu cache functions as __cpuinit. They are all only called from arch/i386/common.c:display_cache_info() that already is marked as __cpuinit. Signed-off-by: Magnus Damm <magnus@valinux.co.jp> Signed-off-by: Andi Kleen

Please consider this patch to allow x2apic without IR support when running on VMware platform. Tested on top of 3.8-rc3. Thanks, Alok -- Allow x2apic without IR on VMware platform. From: Alok N Kataria <akataria at vmware.com> This patch updates x2apic initializaition code to allow x2apic on VMware platform even without interrupt remapping support. The hypervisor_x2apic_available hook

Please consider this patch to allow x2apic without IR support when running on VMware platform. Tested on top of 3.8-rc3. Thanks, Alok -- Allow x2apic without IR on VMware platform. From: Alok N Kataria <akataria at vmware.com> This patch updates x2apic initializaition code to allow x2apic on VMware platform even without interrupt remapping support. The hypervisor_x2apic_available hook

Currently number of error reporting register banks is hardcoded to 6 on AMD processors. This may break in virtualized scenarios when a hypervisor prefers to report fewer banks than what the physical HW provides. Since number of supported banks is reported in MSR_IA32_MCG_CAP[7:0] that''s what we should use. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> ---

This most curious patch allows the fixmap on i386 to be unfixed. The = result is that we can create a dynamically sizable hole at the top of = kernel linear address space. I know at least some virtualization = developers are interested in being able to achieve this to achieve = run-time sizing of a hole in which a hypervisor can live, or at least to = test out the performance

This most curious patch allows the fixmap on i386 to be unfixed. The = result is that we can create a dynamically sizable hole at the top of = kernel linear address space. I know at least some virtualization = developers are interested in being able to achieve this to achieve = run-time sizing of a hole in which a hypervisor can live, or at least to = test out the performance

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

plain text document attachment (xx-paravirt-boot.patch) Boot up code modifications to get paravirt ops running. Signed-off-by: Steven Rostedt srostedt@redhat.com Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com> Index: clean-start/arch/x86_64/kernel/head.S =================================================================== --- clean-start.orig/arch/x86_64/kernel/head.S +++

All, in the light of erratum #573 I''m wondering if we need to tweak or conditionally suppress fsincos emulation. The question is whether there is any possibility for getting the emulator to hit this instruction on AMD (as no real mode emulation ought to be taking place there), i.e. whether there are places where emulation gets continued eagerly in anticipation of the need for emulation

# HG changeset patch # User Boris Ostrovsky <boris.ostrovsky@amd.com> # Date 1330642361 -3600 # Node ID 99df5c6b2964ceaa73651d7bc02fb1ae820f7691 # Parent a7bacdc5449a2f7bb9c35b2a1334b463fe9f29a9 x86: Use deep C states for off-lined CPUs Currently when a core is taken off-line it is placed in C1 state (unless MONITOR/MWAIT is used). This patch allows a core to go to deeper C states