similar to: [PATCH] x86: make IDT read-only

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

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. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Eric Northup <digitaleric at google.com> --- v2: - clarify commit

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. Signed-off-by: Kees Cook <keescook at chromium.org> Cc: Eric Northup <digitaleric at google.com> --- v2: - clarify commit

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for

Descriptor and trap table cleanups. Add cleanly written accessors for IDT and GDT gates so the subarch may override them. Note that this allows the hypervisor to transparently tweak the DPL of the descriptors as well as the RPL of segments in those descriptors, with no unnecessary kernel code modification. It also allows the hypervisor implementation of the VMI to tweak the gates, allowing for

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Joerg Roedel <jroedel at suse.de> > > With SEV-ES, exception handling is needed very early, even before the > kernel has cleared the bss segment. In order to prevent clearing the > currently used IDT, move the IDT to the data segment. Ugh. At the very least this needs a comment in the

On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel <joro at 8bytes.org> wrote: > > From: Joerg Roedel <jroedel at suse.de> > > With SEV-ES, exception handling is needed very early, even before the > kernel has cleared the bss segment. In order to prevent clearing the > currently used IDT, move the IDT to the data segment. Ugh. At the very least this needs a comment in the

> On Feb 12, 2020, at 3:55 AM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Tue, Feb 11, 2020 at 02:41:25PM -0800, Andy Lutomirski wrote: >>> On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel <joro at 8bytes.org> wrote: >>> >>> From: Joerg Roedel <jroedel at suse.de> >>> >>> With SEV-ES, exception handling is needed very

> On Feb 12, 2020, at 3:55 AM, Joerg Roedel <joro at 8bytes.org> wrote: > > ?On Tue, Feb 11, 2020 at 02:41:25PM -0800, Andy Lutomirski wrote: >>> On Tue, Feb 11, 2020 at 5:53 AM Joerg Roedel <joro at 8bytes.org> wrote: >>> >>> From: Joerg Roedel <jroedel at suse.de> >>> >>> With SEV-ES, exception handling is needed very

[mod: The first message would''ve been rejected on the grounds "no security related information", but it gives ME a warm feeling too, so I''m allowing it to piggyback on the announcement of the "fix". Note that Linux-2.1.63 simply implements a fix for the problem, instead of applying this fix, upgrading to 2.1.63 might be an option for you. Linus indicated that

Are there any known or potential problems with Xen''s xmallocing the secondary cores'' IDT tables from a memory region whose physical address is higher than 4GB? Thanks Roger R. Cruz _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

I am having problems installing a custom int3 handler from a com32 app. Here is what I have tried: void int3_handler() { put_str("int3!!!"); __asm__("iret"); } void init_handlers() { struct { unsigned long limit : 16; unsigned long base : 32; } __attribute__((packed)) idtr; __asm__("sidt

In a recent conversation one of my coworkers raised a concern about memory limitations when running 32-bit guests on top of the 64-bit hypervisor. At this point the discussion is academic; I don''t know when/if we''ll ever be able to get system resources to test it, to see if the concerns that he expressed are real. So I decided to post this in hope of getting comments from the

On Tue, Apr 28, 2020 at 05:16:23PM +0200, Joerg Roedel wrote: > diff --git a/arch/x86/boot/compressed/idt_handlers_64.S b/arch/x86/boot/compressed/idt_handlers_64.S > new file mode 100644 > index 000000000000..f86ea872d860 > --- /dev/null > +++ b/arch/x86/boot/compressed/idt_handlers_64.S > @@ -0,0 +1,69 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Early

On Tue, Apr 28, 2020 at 05:16:23PM +0200, Joerg Roedel wrote: > diff --git a/arch/x86/boot/compressed/idt_handlers_64.S b/arch/x86/boot/compressed/idt_handlers_64.S > new file mode 100644 > index 000000000000..f86ea872d860 > --- /dev/null > +++ b/arch/x86/boot/compressed/idt_handlers_64.S > @@ -0,0 +1,69 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Early

From: Joerg Roedel <jroedel at suse.de> With SEV-ES, exception handling is needed very early, even before the kernel has cleared the bss segment. In order to prevent clearing the currently used IDT, move the IDT to the data segment. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/idt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

From: Joerg Roedel <jroedel at suse.de> With SEV-ES, exception handling is needed very early, even before the kernel has cleared the bss segment. In order to prevent clearing the currently used IDT, move the IDT to the data segment. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/idt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

From: Joerg Roedel <jroedel at suse.de> Move these two functions from kernel/idt.c to include/asm/desc.h: * init_idt_data() * idt_init_desc() These functions are needed to setup IDT entries very early and need to be called from head64.c. To be usable this early these functions need to be compiled without instrumentation and the stack-protector feature. These features need to be kept

From: Joerg Roedel <jroedel at suse.de> Load the IDT right after switching to virtual addresses in head_64.S so that the kernel can handle #VC exceptions. Signed-off-by: Joerg Roedel <jroedel at suse.de> Link: https://lore.kernel.org/r/20200724160336.5435-36-joro at 8bytes.org --- arch/x86/include/asm/setup.h | 3 +++ arch/x86/kernel/head64.c | 3 +++ arch/x86/kernel/head_64.S