similar to: IDT location safe if > 4GB?

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

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> ---

> 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

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

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

Joerg Roedel <joro at 8bytes.org> writes: > + addq $8, %rsp > + > + /* > + * Make sure we return to __KERNEL_CS - the CS selector on > + * the IRET frame might still be from an old BIOS GDT > + */ > + movq $__KERNEL_CS, 8(%rsp) This doesn't make sense. Either it's running on the correct CS before the exception or not. Likely there's some other problem

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

I am trying to debug the Xen hypervisor from a second computer over the serial port, but nothing seems to work. Using mercurial, I got xen-3.2-testing.hg. I followed the steps in crashdb.txt in the docs/misc/ folder: set debug=y in Config.mk, crash_debug=y in xen/Rules.mk I also added -fno-omit-frame-pointer to these file as well. I compiled with no errors and booted with minicom connected to

Patches that were posted last week - with review comments addressed.

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

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 early, even before the > > kernel has cleared the bss segment. In order to prevent clearing the > >

On 12.02.20 17:23, Andy Lutomirski wrote: > > >> 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>

Hello, additional keywords: MSI Component I am trying to use WiX on updated Fedora Core 8 using wine-1.0-1.fc8 rpm. Using both latest stable (2.0.5805) and beta version (3.0.2925) of WiX I receive error message regarding `codepage.idt'. I attach a testcase with log. I hope I am poking at the right place. It seems that some have successfully ran WiX under Wine so I just hope it is a simple