Re: [PATCH v3 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 17.05.18 at 16:47, wrote: > @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen) > mov %eax,%es > mov %eax,%ss > > + mov $PVH_CANARY_SEL,%eax > + mov %eax,%gs I doubt this is needed for 64-bit (you could equally well load zero or leave in place what's

Re: [PATCH v3 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 17.05.18 at 16:47, wrote: > @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen) > mov %eax,%es > mov %eax,%ss > > + mov $PVH_CANARY_SEL,%eax > + mov %eax,%gs I doubt this is needed for 64-bit (you could equally well load zero or leave in place what's there in that case), and

Re: [RFC 5/8] x86: refcount: prevent gcc distortions

>>> On 16.05.18 at 18:44, <na...@vmware.com> wrote: > Jan Beulich <jbeul...@suse.com> wrote: >>>>> On 15.05.18 at 16:11, <na...@vmware.com> wrote: >>> --- a/arch/x86/include/asm/refcount.h >>> +++ b/arch/x86/include/asm/refco

Re: [RFC 5/8] x86: refcount: prevent gcc distortions

>>> On 16.05.18 at 18:44, wrote: > Jan Beulich wrote: >>>>> On 15.05.18 at 16:11, wrote: >>> --- a/arch/x86/include/asm/refcount.h >>> +++ b/arch/x86/include/asm/refcount.h >>> @@ -14,34 +14,43 @@ >>> * central refcount ex

Re: [RFC 5/8] x86: refcount: prevent gcc distortions

>>> On 15.05.18 at 16:11, wrote: > --- a/arch/x86/include/asm/refcount.h > +++ b/arch/x86/include/asm/refcount.h > @@ -14,34 +14,43 @@ > * central refcount exception. The fixup address for the exception points > * back to the regular execution flow in .text. > */ >

Re: [RFC 5/8] x86: refcount: prevent gcc distortions

>>> On 15.05.18 at 16:11, wrote: > --- a/arch/x86/include/asm/refcount.h > +++ b/arch/x86/include/asm/refcount.h > @@ -14,34 +14,43 @@ > * central refcount exception. The fixup address for the exception points > * back to the regular execution flow in .text. > */ > -#define

Re: [Xen-devel] [PATCH v2 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 09.05.18 at 22:33, wrote: > @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen) > mov %eax,%es > mov %eax,%ss > > + /* Set base address in stack canary descriptor. */ > + movl _pa(gdt_start),%eax > + movl $_pa(canary),%ecx > + movw %cx,

Re: [Xen-devel] [PATCH v2 1/2] xen/PVH: Set up GS segment for stack canary

>>> On 09.05.18 at 22:33, wrote: > @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen) > mov %eax,%es > mov %eax,%ss > > + /* Set base address in stack canary descriptor. */ > + movl _pa(gdt_start),%eax > + movl $_pa(canary),%ecx > + movw %cx, (PVH_GDT_ENTRY_CANARY * 8) +

Re: [PATCH] x86-64/Xen: fix stack switching

>>> On 08.05.18 at 04:38, <l...@kernel.org> wrote: > On Mon, May 7, 2018 at 5:16 AM Jan Beulich <jbeul...@suse.com> wrote: > >> While on native entry into the kernel happens on the trampoline stack, >> PV Xen kernels are being entered with the current t

Re: [PATCH] x86-64/Xen: fix stack switching

>>> On 08.05.18 at 04:38, wrote: > On Mon, May 7, 2018 at 5:16 AM Jan Beulich wrote: > >> While on native entry into the kernel happens on the trampoline stack, >> PV Xen kernels are being entered with the current thread stack right >> away. Hence source and

[PATCH] x86-64/Xen: fix stack switching

path is unreachable when running an PV Xen guest afaict. Signed-off-by: Jan Beulich <jbeul...@suse.com> Cc: sta...@kernel.org --- There would certainly have been the option of using alternatives patching, but afaict the patching code isn't NMI / #MC safe, so I'd rather stay away from pa

[PATCH] x86-64/Xen: fix stack switching

path is unreachable when running an PV Xen guest afaict. Signed-off-by: Jan Beulich Cc: sta...@kernel.org --- There would certainly have been the option of using alternatives patching, but afaict the patching code isn't NMI / #MC safe, so I'd rather stay away from patching the NMI path. And I

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 02.05.18 at 19:29, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 11:41 AM, Jan Beulich wrote: >>>>> On 02.05.18 at 17:22, <boris.ostrov...@oracle.com> wrote: >>> On 05/02/2018 11:01 AM, Jan Beulich wrote: >>>>>>> On

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 02.05.18 at 19:29, wrote: > On 05/02/2018 11:41 AM, Jan Beulich wrote: >>>>> On 02.05.18 at 17:22, wrote: >>> On 05/02/2018 11:01 AM, Jan Beulich wrote: >>>>>>> On 02.05.18 at 17:00, wrote: >>>>> On 05/02/

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 02.05.18 at 17:22, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 11:01 AM, Jan Beulich wrote: >>>>> On 02.05.18 at 17:00, <boris.ostrov...@oracle.com> wrote: >>> On 05/02/2018 04:16 AM, Jan Beulich wrote: >>>>

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 02.05.18 at 17:22, wrote: > On 05/02/2018 11:01 AM, Jan Beulich wrote: >>>>> On 02.05.18 at 17:00, wrote: >>> On 05/02/2018 04:16 AM, Jan Beulich wrote: >>>>>>> On 30.04.18 at 18:23, wrote: >>>>> --- a/arch/x

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

>>> On 02.05.18 at 17:08, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 11:00 AM, Jan Beulich wrote: >>>>> On 02.05.18 at 16:57, <boris.ostrov...@oracle.com> wrote: >>> On 05/02/2018 04:05 AM, Jan Beulich wrote: >>>>>>> O

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

>>> On 02.05.18 at 17:08, wrote: > On 05/02/2018 11:00 AM, Jan Beulich wrote: >>>>> On 02.05.18 at 16:57, wrote: >>> On 05/02/2018 04:05 AM, Jan Beulich wrote: >>>>>>> On 30.04.18 at 18:23, wrote: >>>>> Signed-off-by: Bor

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

>>> On 02.05.18 at 17:06, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 04:26 AM, Jan Beulich wrote: >>>>> On 01.05.18 at 14:34, <boris.ostrov...@oracle.com> wrote: >>> On 05/01/2018 04:00 AM, Roger Pau Monné wrote: >>>> On

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

>>> On 02.05.18 at 17:06, wrote: > On 05/02/2018 04:26 AM, Jan Beulich wrote: >>>>> On 01.05.18 at 14:34, wrote: >>> On 05/01/2018 04:00 AM, Roger Pau Monné wrote: >>>> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote: >>>

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 02.05.18 at 17:00, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 04:16 AM, Jan Beulich wrote: >>>>> On 30.04.18 at 18:23, <boris.ostrov...@oracle.com> wrote: >>> --- a/arch/x86/xen/xen-pvh.S >>> +++ b/arch/x86/xen/xen-pvh.S &g

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 02.05.18 at 17:00, wrote: > On 05/02/2018 04:16 AM, Jan Beulich wrote: >>>>> On 30.04.18 at 18:23, wrote: >>> --- a/arch/x86/xen/xen-pvh.S >>> +++ b/arch/x86/xen/xen-pvh.S >>> @@ -54,6 +54,9 @@ >>> * charge of sett

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

>>> On 02.05.18 at 16:57, <boris.ostrov...@oracle.com> wrote: > On 05/02/2018 04:05 AM, Jan Beulich wrote: >>>>> On 30.04.18 at 18:23, <boris.ostrov...@oracle.com> wrote: >>> Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

>>> On 02.05.18 at 16:57, wrote: > On 05/02/2018 04:05 AM, Jan Beulich wrote: >>>>> On 30.04.18 at 18:23, wrote: >>> Signed-off-by: Boris Ostrovsky >> Reviewed-by: Jan Beulich >> >> But to understand why things have been working neverth

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

>>> On 01.05.18 at 14:34, wrote: > On 05/01/2018 04:00 AM, Roger Pau Monné wrote: >> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote: >>> And without it we can't use _BOOT_XX macros any longer so define new ones. >> >> Not being that familiar with

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

>>> On 01.05.18 at 14:34, wrote: > On 05/01/2018 04:00 AM, Roger Pau Monné wrote: >> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote: >>> And without it we can't use _BOOT_XX macros any longer so define new ones. >> >> Not being that familiar with Linux internals I'm not sure I

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

>>> On 30.04.18 at 18:23, wrote: > And without it we can't use _BOOT_XX macros any longer so define new ones. Ah, here we go. Perhaps this should be moved earlier in the series? Assuming you really want to go this route in the first place, taking Roger's comment into

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

>>> On 30.04.18 at 18:23, wrote: > And without it we can't use _BOOT_XX macros any longer so define new ones. Ah, here we go. Perhaps this should be moved earlier in the series? Assuming you really want to go this route in the first place, taking Roger's comment into consideration. Jan

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 30.04.18 at 18:23, wrote: > --- a/arch/x86/xen/xen-pvh.S > +++ b/arch/x86/xen/xen-pvh.S > @@ -54,6 +54,9 @@ > * charge of setting up it's own stack, GDT and IDT. > */ > > +#define PVH_GDT_ENTRY_CANARY4 > +#define PVH_CANARY_SEL

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 30.04.18 at 18:23, wrote: > --- a/arch/x86/xen/xen-pvh.S > +++ b/arch/x86/xen/xen-pvh.S > @@ -54,6 +54,9 @@ > * charge of setting up it's own stack, GDT and IDT. > */ > > +#define PVH_GDT_ENTRY_CANARY4 > +#define PVH_CANARY_SEL (PVH_GDT_ENTRY_CANARY * 8) I can only

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

>>> On 30.04.18 at 18:23, <boris.ostrov...@oracle.com> wrote: > Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Reviewed-by: Jan Beulich <jbeul...@suse.com> But to understand why things have been working nevertheless it would have been nice if t

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

>>> On 30.04.18 at 18:23, wrote: > Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich But to understand why things have been working nevertheless it would have been nice if the commit message wasn't empty, but instead said something like "The two happen to be identical on 64-bit." Jan

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

>>> On 30.04.18 at 18:23, wrote: > Latest binutils release (2.29.1) will no longer allow proper computation > of GDT entries on 32-bits, with warning: > > arch/x86/xen/xen-pvh.S: Assembler messages: > arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

>>> On 30.04.18 at 18:23, wrote: > Latest binutils release (2.29.1) will no longer allow proper computation > of GDT entries on 32-bits, with warning: > > arch/x86/xen/xen-pvh.S: Assembler messages: > arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not > between 0 and 31) >

Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

>>> On 02.05.18 at 03:56, <douly.f...@cn.fujitsu.com> wrote: > At 04/27/2018 08:09 PM, Jan Beulich wrote: >> I'm afraid I don't understand: Limiting the number of disabled CPUs is >> certainly desirable when those can never be used, but why would you >> want

Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

>>> On 02.05.18 at 03:56, wrote: > At 04/27/2018 08:09 PM, Jan Beulich wrote: >> I'm afraid I don't understand: Limiting the number of disabled CPUs is >> certainly desirable when those can never be used, but why would you >> want to do this when they might later

Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

>>> On 27.04.18 at 10:32, <douly.f...@cn.fujitsu.com> wrote: > At 04/27/2018 03:21 PM, Jan Beulich wrote: >> I've just stumbled across this commit, and I'm wondering if that's actually >> correct (I too have at least one system where such IDs are reported in >

Re: recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

>>> On 27.04.18 at 10:32, wrote: > At 04/27/2018 03:21 PM, Jan Beulich wrote: >> I've just stumbled across this commit, and I'm wondering if that's actually >> correct (I too have at least one system where such IDs are reported in >> MADT): For offline/absent C

recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

Hello, I've just stumbled across this commit, and I'm wondering if that's actually correct (I too have at least one system where such IDs are reported in MADT): For offline/absent CPUs, the firmware may not know the APIC IDs at the point MADT is built, so I think it is quite reasonable to put ~0

recent patch "x86/acpi: Prevent X2APIC id 0xffffffff from being accounted"

Hello, I've just stumbled across this commit, and I'm wondering if that's actually correct (I too have at least one system where such IDs are reported in MADT): For offline/absent CPUs, the firmware may not know the APIC IDs at the point MADT is built, so I think it is quite reasonable to put ~0

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

>>> On 12.04.18 at 09:32, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> >>> On 11.04.18 at 13:53, <mi...@kernel.org> wrote: >> > * Jan Beulich <jbeul...@suse.com> wrote: >> > >> >

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

>>> On 12.04.18 at 09:32, wrote: > * Jan Beulich wrote: > >> >>> On 11.04.18 at 13:53, wrote: >> > * Jan Beulich wrote: >> > >> >> Additionally, x86 maintainers: is there a particular reason this (or >> >> any functio

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

>>> On 11.04.18 at 13:53, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> Additionally, x86 maintainers: is there a particular reason this (or >> any functionally equivalent patch) isn't upstream yet? As indicated >> befor

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

>>> On 11.04.18 at 13:53, wrote: > * Jan Beulich wrote: > >> Additionally, x86 maintainers: is there a particular reason this (or >> any functionally equivalent patch) isn't upstream yet? As indicated >> before, I had not been able to find any discussion,

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

>>> On 11.04.18 at 09:08, <jgr...@suse.com> wrote: > On 14/03/18 09:48, Jan Beulich wrote: >>>>> On 26.02.18 at 15:08, <jgr...@suse.com> wrote: >>> @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled) >>&

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

>>> On 11.04.18 at 09:08, wrote: > On 14/03/18 09:48, Jan Beulich wrote: >>>>> On 26.02.18 at 15:08, wrote: >>> @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled) >>> >>> static void xen_vcpu_notify_restore(void *da

Re: [PATCH] [v3] xen: remove pre-xen3 fallback handlers

>>> On 14.03.18 at 23:47, wrote: > On 03/13/2018 05:06 PM, Arnd Bergmann wrote: >> The legacy hypercall handlers were originally added with >> a comment explaining that "copying the argument structures in >> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op()

Re: [PATCH] [v3] xen: remove pre-xen3 fallback handlers

>>> On 14.03.18 at 23:47, wrote: > On 03/13/2018 05:06 PM, Arnd Bergmann wrote: >> The legacy hypercall handlers were originally added with >> a comment explaining that "copying the argument structures in >> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local >> variable is

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

>>> On 26.02.18 at 15:08, wrote: > @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled) > > static void xen_vcpu_notify_restore(void *data) > { > + if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) > + wrmsrl(MSR_IA32_SPEC_CTRL,

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

>>> On 26.02.18 at 15:08, wrote: > @@ -35,6 +40,9 @@ void xen_arch_post_suspend(int cancelled) > > static void xen_vcpu_notify_restore(void *data) > { > + if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) > + wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl)); > +

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

Juergen Gross 03/01/18 8:29 AM >>> >On 28/02/18 19:28, Maran Wilson wrote: >> The start info structure that is defined as part of the x86/HVM direct boot >> ABI and used for starting Xen PVH guests would be more versatile if it also >> included a way to pass information

Re: [RFC PATCH v4 6/7] xen/pvh: Add memory map pointer to hvm_start_info struct

Juergen Gross 03/01/18 8:29 AM >>> >On 28/02/18 19:28, Maran Wilson wrote: >> The start info structure that is defined as part of the x86/HVM direct boot >> ABI and used for starting Xen PVH guests would be more versatile if it also >> included a way to pass information about the memory map

[tip:x86/urgent] x86/asm: Add instruction suffixes to bitops

Commit-ID: 22636f8c9511245cb3c8412039f1dd95afb3aa59 Gitweb: https://git.kernel.org/tip/22636f8c9511245cb3c8412039f1dd95afb3aa59 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 26 Feb 2018 04:11:51 -0700 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Wed,

[tip:x86/urgent] x86/asm: Add instruction suffixes to bitops

Commit-ID: 22636f8c9511245cb3c8412039f1dd95afb3aa59 Gitweb: https://git.kernel.org/tip/22636f8c9511245cb3c8412039f1dd95afb3aa59 Author: Jan Beulich AuthorDate: Mon, 26 Feb 2018 04:11:51 -0700 Committer: Thomas Gleixner CommitDate: Wed, 28 Feb 2018 15:18:41 +0100 x86/asm: Add

[tip:x86/urgent] x86/entry/64: Add instruction suffix

Commit-ID: a368d7fd2a3c6babb852fe974018dd97916bcd3b Gitweb: https://git.kernel.org/tip/a368d7fd2a3c6babb852fe974018dd97916bcd3b Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 26 Feb 2018 04:11:21 -0700 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Wed,

[tip:x86/urgent] x86/entry/64: Add instruction suffix

Commit-ID: a368d7fd2a3c6babb852fe974018dd97916bcd3b Gitweb: https://git.kernel.org/tip/a368d7fd2a3c6babb852fe974018dd97916bcd3b Author: Jan Beulich AuthorDate: Mon, 26 Feb 2018 04:11:21 -0700 Committer: Thomas Gleixner CommitDate: Wed, 28 Feb 2018 15:18:40 +0100 x86/entry/64: Add

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

@vger.kernel.org > Signed-off-by: Juergen Gross <jgr...@suse.com> Reviewed-by: Jan Beulich <jbeul...@suse.com>

Re: [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

> Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich

[PATCH] x86/include: add instruction suffixes

some operations change from being 32-bit to 64-bit. Signed-off-by: Jan Beulich <jbeul...@suse.com> --- If the operand size change for 64-bit is undesirable, further transformations would be necessary. Likely the best route would be to fully separate the constant and variable bit position case

[PATCH] x86/include: add instruction suffixes

some operations change from being 32-bit to 64-bit. Signed-off-by: Jan Beulich --- If the operand size change for 64-bit is undesirable, further transformations would be necessary. Likely the best route would be to fully separate the constant and variable bit position cases from one another

[PATCH] x86-64/entry: add instruction suffix

Omitting suffixes from instructions in AT mode is bad practice when operand size cannot be determined by the assembler from register operands, and is likely going to be warned about by upstream gas in the future (mine does already). Add the single missing suffix here. Signed-off-by: Jan Beulich

[PATCH] x86-64/entry: add instruction suffix

Omitting suffixes from instructions in AT mode is bad practice when operand size cannot be determined by the assembler from register operands, and is likely going to be warned about by upstream gas in the future (mine does already). Add the single missing suffix here. Signed-off-by: Jan Beulich

Re: [tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

>>> On 26.02.18 at 11:47, <aryabi...@virtuozzo.com> wrote: > > On 02/26/2018 01:08 PM, Jan Beulich wrote: >>>>> On 26.02.18 at 11:00, <aryabi...@virtuozzo.com> wrote: >>> On 02/26/2018 11:48 AM, tip-bot for Jan Beulich wrote: >>>>

Re: [tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

>>> On 26.02.18 at 11:47, wrote: > > On 02/26/2018 01:08 PM, Jan Beulich wrote: >>>>> On 26.02.18 at 11:00, wrote: >>> On 02/26/2018 11:48 AM, tip-bot for Jan Beulich wrote: >>>> @@ -351,7 +362,7 @@ static inline bool kasan_page_tab

Re: [tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

>>> On 26.02.18 at 11:00, <aryabi...@virtuozzo.com> wrote: > On 02/26/2018 11:48 AM, tip-bot for Jan Beulich wrote: >> @@ -351,7 +362,7 @@ static inline bool kasan_page_table(struct seq_file *m, >> struct pg_state *st, >> (pgtable_l5_enable

Re: [tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

>>> On 26.02.18 at 11:00, wrote: > On 02/26/2018 11:48 AM, tip-bot for Jan Beulich wrote: >> @@ -351,7 +362,7 @@ static inline bool kasan_page_table(struct seq_file *m, >> struct pg_state *st, >> (pgtable_l5_enabled && __pa(pt) == __pa(kasan_zero

[tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

Commit-ID: 672c0ae09b33a11d8f31fc61526632e96301164c Gitweb: https://git.kernel.org/tip/672c0ae09b33a11d8f31fc61526632e96301164c Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Fri, 23 Feb 2018 01:27:37 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 26 Fe

[tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

Commit-ID: 672c0ae09b33a11d8f31fc61526632e96301164c Gitweb: https://git.kernel.org/tip/672c0ae09b33a11d8f31fc61526632e96301164c Author: Jan Beulich AuthorDate: Fri, 23 Feb 2018 01:27:37 -0700 Committer: Ingo Molnar CommitDate: Mon, 26 Feb 2018 08:43:21 +0100 x86/mm: Consider effective

[tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

Commit-ID: 6e558c9d10146ebe7f04917af2f8533b811f9c25 Gitweb: https://git.kernel.org/tip/6e558c9d10146ebe7f04917af2f8533b811f9c25 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Fri, 23 Feb 2018 01:27:37 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 23 Fe

[tip:x86/mm] x86/mm: Consider effective protection attributes in W+X check

Commit-ID: 6e558c9d10146ebe7f04917af2f8533b811f9c25 Gitweb: https://git.kernel.org/tip/6e558c9d10146ebe7f04917af2f8533b811f9c25 Author: Jan Beulich AuthorDate: Fri, 23 Feb 2018 01:27:37 -0700 Committer: Ingo Molnar CommitDate: Fri, 23 Feb 2018 09:51:38 +0100 x86/mm: Consider effective

[PATCH v3] x86: consider effective protection attributes in W+X check

_NX is set in L2. Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Juergen Gross <jgr...@suse.com> --- v3: Fix build issue with CONFIG_KASAN. v2: Re-base onto tip tree. Add Xen related paragraph to description. --- arch/x86/mm/dump_pagetables.c | 94 +++

[PATCH v3] x86: consider effective protection attributes in W+X check

_NX is set in L2. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- v3: Fix build issue with CONFIG_KASAN. v2: Re-base onto tip tree. Add Xen related paragraph to description. --- arch/x86/mm/dump_pagetables.c | 94 +- 1 file changed, 58 inserti

Re: [PATCH v2] x86: consider effective protection attributes in W+X check

>>> On 23.02.18 at 08:49, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> >>> On 21.02.18 at 17:53, <mi...@kernel.org> wrote: >> >> > * Jan Beulich <jbeul...@suse.com> wrote: >> >

Re: [PATCH v2] x86: consider effective protection attributes in W+X check

>>> On 23.02.18 at 08:49, wrote: > * Jan Beulich wrote: > >> >>> On 21.02.18 at 17:53, wrote: >> >> > * Jan Beulich wrote: >> > >> >> Using just the leaf page table entry flags would cause a false warning >>

Re: [PATCH v2] x86: consider effective protection attributes in W+X check

>>> On 21.02.18 at 17:53, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> Using just the leaf page table entry flags would cause a false warning >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. >>

Re: [PATCH v2] x86: consider effective protection attributes in W+X check

>>> On 21.02.18 at 17:53, wrote: > * Jan Beulich wrote: > >> Using just the leaf page table entry flags would cause a false warning >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. >> Hand through both the current entry's flags as wel

Re: [PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

>>> On 21.02.18 at 22:39, <keesc...@chromium.org> wrote: > On Mon, Feb 19, 2018 at 6:49 AM, Jan Beulich <jbeul...@suse.com> wrote: >> Commit df3405245a ("x86/asm: Add suffix macro for GEN_*_RMWcc()") >> introduced "suffix" RMWcc operati

Re: [PATCH] x86/asm: improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

>>> On 21.02.18 at 22:39, wrote: > On Mon, Feb 19, 2018 at 6:49 AM, Jan Beulich wrote: >> Commit df3405245a ("x86/asm: Add suffix macro for GEN_*_RMWcc()") >> introduced "suffix" RMWcc operations, adding bogus clobber specifiers: >> For one,

[PATCH v2] x86: consider effective protection attributes in W+X check

_NX is set in L2. Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Juergen Gross <jgr...@suse.com> --- v2: Re-base onto tip tree. Add Xen related paragraph to description. --- arch/x86/mm/dump_pagetables.c | 92 ++ 1 file changed

[PATCH v2] x86: consider effective protection attributes in W+X check

_NX is set in L2. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- v2: Re-base onto tip tree. Add Xen related paragraph to description. --- arch/x86/mm/dump_pagetables.c | 92 ++ 1 file changed, 57 insertions(+), 35 deletions(-) --- a/a

Re: [PATCH RESEND] x86: consider effective protection attributes in W+X check

>>> On 20.02.18 at 11:17, wrote: > I assume the Xen fix got merged meanwhile? Yes (that's the commit I've referred to in an earlier reply). Jan

Re: [PATCH RESEND] x86: consider effective protection attributes in W+X check

>>> On 20.02.18 at 11:17, wrote: > I assume the Xen fix got merged meanwhile? Yes (that's the commit I've referred to in an earlier reply). Jan

[tip:x86/pti] x86/LDT: Avoid warning in 32-bit builds with older gcc

Commit-ID: f2f18b16c779978ece4a04f304a92ff9ac8fbce5 Gitweb: https://git.kernel.org/tip/f2f18b16c779978ece4a04f304a92ff9ac8fbce5 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 07:52:10 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

[tip:x86/pti] x86/LDT: Avoid warning in 32-bit builds with older gcc

Commit-ID: f2f18b16c779978ece4a04f304a92ff9ac8fbce5 Gitweb: https://git.kernel.org/tip/f2f18b16c779978ece4a04f304a92ff9ac8fbce5 Author: Jan Beulich AuthorDate: Mon, 19 Feb 2018 07:52:10 -0700 Committer: Ingo Molnar CommitDate: Tue, 20 Feb 2018 09:33:40 +0100 x86/LDT: Avoid warning

[tip:x86/pti] x86-64/realmode: Add instruction suffix

Commit-ID: 8554004a0231dedf44d4d62147fb3d6a6db489aa Gitweb: https://git.kernel.org/tip/8554004a0231dedf44d4d62147fb3d6a6db489aa Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 08:06:14 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

[tip:x86/pti] x86-64/realmode: Add instruction suffix

Commit-ID: 8554004a0231dedf44d4d62147fb3d6a6db489aa Gitweb: https://git.kernel.org/tip/8554004a0231dedf44d4d62147fb3d6a6db489aa Author: Jan Beulich AuthorDate: Mon, 19 Feb 2018 08:06:14 -0700 Committer: Ingo Molnar CommitDate: Tue, 20 Feb 2018 09:33:41 +0100 x86-64/realmode: Add

[tip:x86/pti] x86/IO-APIC: Avoid warning in 32-bit builds

Commit-ID: 6262b6e78ce5ba62be47774ca80f5b0a6f0eb428 Gitweb: https://git.kernel.org/tip/6262b6e78ce5ba62be47774ca80f5b0a6f0eb428 Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 07:50:23 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

[tip:x86/pti] x86/IO-APIC: Avoid warning in 32-bit builds

Commit-ID: 6262b6e78ce5ba62be47774ca80f5b0a6f0eb428 Gitweb: https://git.kernel.org/tip/6262b6e78ce5ba62be47774ca80f5b0a6f0eb428 Author: Jan Beulich AuthorDate: Mon, 19 Feb 2018 07:50:23 -0700 Committer: Ingo Molnar CommitDate: Tue, 20 Feb 2018 09:33:40 +0100 x86/IO-APIC: Avoid warning

[tip:x86/pti] x86/asm: Improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

Commit-ID: 700b7c5409c3e9da279fbea78cf28a78fbc176cd Gitweb: https://git.kernel.org/tip/700b7c5409c3e9da279fbea78cf28a78fbc176cd Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 07:49:12 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

[tip:x86/pti] x86/asm: Improve how GEN_*_SUFFIXED_RMWcc() specify clobbers

Commit-ID: 700b7c5409c3e9da279fbea78cf28a78fbc176cd Gitweb: https://git.kernel.org/tip/700b7c5409c3e9da279fbea78cf28a78fbc176cd Author: Jan Beulich AuthorDate: Mon, 19 Feb 2018 07:49:12 -0700 Committer: Ingo Molnar CommitDate: Tue, 20 Feb 2018 09:33:39 +0100 x86/asm: Improve how GEN_

[tip:x86/pti] x86/mm: Fix {pmd,pud}_{set,clear}_flags()

Commit-ID: 842cef9113c2120f74f645111ded1e020193d84c Gitweb: https://git.kernel.org/tip/842cef9113c2120f74f645111ded1e020193d84c Author: Jan Beulich <jbeul...@suse.com> AuthorDate: Mon, 19 Feb 2018 07:48:11 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue, 20 Fe

[tip:x86/pti] x86/mm: Fix {pmd,pud}_{set,clear}_flags()

Commit-ID: 842cef9113c2120f74f645111ded1e020193d84c Gitweb: https://git.kernel.org/tip/842cef9113c2120f74f645111ded1e020193d84c Author: Jan Beulich AuthorDate: Mon, 19 Feb 2018 07:48:11 -0700 Committer: Ingo Molnar CommitDate: Tue, 20 Feb 2018 09:33:39 +0100 x86/mm: Fix {pmd,pud}_{set

Re: [PATCH RESEND] x86: consider effective protection attributes in W+X check

>>> On 20.02.18 at 09:37, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: > >> I'll see what I can do; it's a pity that the change here, which had >> been sent weeks ago and is a bug fix, hadn't gone in before that >> other cha

Re: [PATCH RESEND] x86: consider effective protection attributes in W+X check

>>> On 20.02.18 at 09:37, wrote: > * Jan Beulich wrote: > >> I'll see what I can do; it's a pity that the change here, which had >> been sent weeks ago and is a bug fix, hadn't gone in before that >> other change (being more an improvement than a bug fix)

Re: [PATCH RESEND] x86: consider effective protection attributes in W+X check

>>> On 20.02.18 at 09:10, <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@suse.com> wrote: >> Using just the leaf page table entry flags would cause a false warning >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. > > Under wha

Re: [PATCH RESEND] x86: consider effective protection attributes in W+X check

>>> On 20.02.18 at 09:10, wrote: > * Jan Beulich wrote: >> Using just the leaf page table entry flags would cause a false warning >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry. > > Under what circumstances did you see false positive wa

[PATCH RESEND] x86: consider effective protection attributes in W+X check

entry's value). Signed-off-by: Jan Beulich <jbeul...@suse.com> Reviewed-by: Juergen Gross <jgr...@suse.com> --- arch/x86/mm/dump_pagetables.c | 92 ++ 1 file changed, 57 insertions(+), 35 deletions(-) --- 4.16-rc2/arch/x86/mm/dump_pagetable

[PATCH RESEND] x86: consider effective protection attributes in W+X check

entry's value). Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- arch/x86/mm/dump_pagetables.c | 92 ++ 1 file changed, 57 insertions(+), 35 deletions(-) --- 4.16-rc2/arch/x86/mm/dump_pagetables.c +++ 4.16-rc2-x86-dumppgt-effective-prot/arch

Re: [PATCH] x86: fix {pmd,pud}_{set,clear}_flags()

>>> On 19.02.18 at 17:23, <jgr...@suse.com> wrote: > On 19/02/18 15:48, Jan Beulich wrote: >> Just like pte_{set,clear}_flags() their PMD and PUD counterparts should >> not do any address translation. This was outright wrong under Xen >> (causing a dead boo

Re: [PATCH] x86: fix {pmd,pud}_{set,clear}_flags()

>>> On 19.02.18 at 17:23, wrote: > On 19/02/18 15:48, Jan Beulich wrote: >> Just like pte_{set,clear}_flags() their PMD and PUD counterparts should >> not do any address translation. This was outright wrong under Xen >> (causing a dead boot with no usefu

<    1   2   3   4   5   6   7   8   9   10   >