search for: gs_base

From: Joerg Roedel <jroedel at suse.de> When stack-protector is enabled a valid GS_BASE is needed before calling any C code function, because the stack canary is loaded from per-cpu data. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/head64.c | 7 +++++++ arch/x86/kernel/head_64.S | 8 ++++++++ 2 files changed, 15 insertions(+) diff --git a/arch/x86/ke...

From: Joerg Roedel <jroedel at suse.de> When stack-protector is enabled a valid GS_BASE is needed before calling any C code function, because the stack canary is loaded from per-cpu data. Signed-off-by: Joerg Roedel <jroedel at suse.de> Reviewed-by: Kees Cook <keescook at chromium.org> Link: https://lore.kernel.org/r/20200724160336.5435-31-joro at 8bytes.org --- arch/x86...

...->fs_sel = __vmread(GUEST_FS_SELECTOR); + c->fs_limit = __vmread(GUEST_FS_LIMIT); + c->fs_base = __vmread(GUEST_FS_BASE); + c->fs_arbytes = __vmread(GUEST_FS_AR_BYTES); + + c->gs_sel = __vmread(GUEST_GS_SELECTOR); + c->gs_limit = __vmread(GUEST_GS_LIMIT); + c->gs_base = __vmread(GUEST_GS_BASE); + c->gs_arbytes = __vmread(GUEST_GS_AR_BYTES); + + c->tr_sel = __vmread(GUEST_TR_SELECTOR); + c->tr_limit = __vmread(GUEST_TR_LIMIT); + c->tr_base = __vmread(GUEST_TR_BASE); + c->tr_arbytes = __vmread(GUEST_TR_AR_BYTES); + + c->ldtr_sel...

On Tue, Apr 28, 2020 at 05:16:45PM +0200, Joerg Roedel wrote: > From: Joerg Roedel <jroedel at suse.de> > > The code inserted by the stack protector does not work in the early > boot environment because it uses the GS segment, at least with memory > encryption enabled. Can you elaborate on why is that a problem? The stack cookie is not generated that early yet so it should

...iret_user) + UNWIND_HINT_IRET_REGS offset=8 + /* + * The kernel jumps here directly from + * swapgs_restore_regs_and_return_to_usermode. %rsp points already to + * trampoline stack, but %cr3 is still from kernel. User-regs are live + * except %rdi. Switch to user CR3, restore user %rdi and user gs_base + * and single-step over IRET + */ + SWITCH_TO_USER_CR3_STACK scratch_reg=%rdi + popq %rdi + SWAPGS + /* + * Enable single-stepping and execute IRET. When IRET is + * finished the resulting #DB exception will cause a #VC + * exception to be raised. The #VC exception handler will send a + * NM...

Better use of VMX execution controls MSR. Signed-off-by: Xin Li<xin.b.li@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Changes: - patch v3: - Update on message to describe longer term PIE goal. - Minor change on ftrace if condition. - Changed code using xchgq. - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

...ream Linux and include the necessary changes. Changes to v4 are in particular: - Moved early IDT setup code to idt.c, because the idt_descr and the idt_table are now static - This required to make stack protector work early (or disable it for idt.c, but I didn't go that road), so MSR_GS_BASE is now set up very early too, before calling into any C code that has stack protector checks. - As a result I decided to move the setup code which is needed before the kernel switches to virtual addresses into a C function as well. This should be much easier to maintain. - paranoid_...

...ased VC Exception handler x86/boot/compressed/64: Unmap GHCB page before booting the kernel x86/fpu: Move xgetbv()/xsetbv() into separate header x86/idt: Move IDT to data segment x86/idt: Split idt_data setup out of set_intr_gate() x86/head/64: Install startup GDT x86/head/64: Setup MSR_GS_BASE before calling into C code x86/head/64: Load GDT after switch to virtual addresses x86/head/64: Load segment registers earlier x86/head/64: Switch to initial stack earlier x86/head/64: Make fixup_pointer() static inline x86/head/64: Load IDT earlier x86/head/64: Move early exception dis...

Hi, here is the first public post of the patch-set to enable Linux to run under SEV-ES enabled hypervisors. The code is mostly feature-complete, but there are still a couple of bugs to fix. Nevertheless, given the size of the patch-set, I think it is about time to ask for initial feedback of the changes that come with it. To better understand the code here is a quick explanation of SEV-ES first.

Hi, here is the first public post of the patch-set to enable Linux to run under SEV-ES enabled hypervisors. The code is mostly feature-complete, but there are still a couple of bugs to fix. Nevertheless, given the size of the patch-set, I think it is about time to ask for initial feedback of the changes that come with it. To better understand the code here is a quick explanation of SEV-ES first.

A character device for accessing (in user-space) pages that have been granted by other domains. Signed-off-by: Derek Murray <Derek.Murray@cl.cam.ac.uk> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel