x86: insn-eval.c's use of native_store_gdt()
Hello, I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") which uncovered an issue with get_desc() trying to access the GDT, as introduced by 670f928ba09b ("x86/insn-eval: Add utility function to get segment descriptor"). When running in a PV domain under Xen, the (hypervisor's) GDT isn't accessible; with UMIP enabled by Xen even SGDT wouldn't work, as the kernel runs in ring 3. There's currently no hypercall to retrieve a descriptor from the GDT. It is instead assumed that kernels know where their present GDT lives. Can the native_store_gdt() be replaced there, please? For context (I don't think it should matter much here) I'm observing this with the kernel put underneath a rather old distro, where hwclock triggers this path. Thanks, Jan
Re: x86: insn-eval.c's use of native_store_gdt()
On 30.11.2021 12:09, Jan Beulich wrote: > I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") > which uncovered an issue with get_desc() trying to access the GDT, as > introduced by 670f928ba09b ("x86/insn-eval: Add utility function to > get segment descriptor"). When running in a PV domain under Xen, the > (hypervisor's) GDT isn't accessible; with UMIP enabled by Xen even > SGDT wouldn't work, as the kernel runs in ring 3. > > There's currently no hypercall to retrieve a descriptor from the GDT. > It is instead assumed that kernels know where their present GDT > lives. Can the native_store_gdt() be replaced there, please? > > For context (I don't think it should matter much here) I'm observing > this with the kernel put underneath a rather old distro, where > hwclock triggers this path. I'd like to note that the issue still exists in 5.16. Jan
Re: x86: insn-eval.c's use of native_store_gdt()
On Fri, Feb 04 2022 at 10:23, Jan Beulich wrote: > On 30.11.2021 12:09, Jan Beulich wrote: >> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") >> which uncovered an issue with get_desc() trying to access the GDT, as >> introduced by 670f928ba09b ("x86/insn-eval: Add utility function to >> get segment descriptor"). When running in a PV domain under Xen, the >> (hypervisor's) GDT isn't accessible; with UMIP enabled by Xen even >> SGDT wouldn't work, as the kernel runs in ring 3. >> >> There's currently no hypercall to retrieve a descriptor from the GDT. >> It is instead assumed that kernels know where their present GDT >> lives. Can the native_store_gdt() be replaced there, please? >> >> For context (I don't think it should matter much here) I'm observing >> this with the kernel put underneath a rather old distro, where >> hwclock triggers this path. > > I'd like to note that the issue still exists in 5.16. I'd like to note, that I've seen no patches to that effect. Thanks, tglx
Re: x86: insn-eval.c's use of native_store_gdt()
On 04.02.2022 15:08, Thomas Gleixner wrote: > On Fri, Feb 04 2022 at 10:23, Jan Beulich wrote: >> On 30.11.2021 12:09, Jan Beulich wrote: >>> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") >>> which uncovered an issue with get_desc() trying to access the GDT, as >>> introduced by 670f928ba09b ("x86/insn-eval: Add utility function to >>> get segment descriptor"). When running in a PV domain under Xen, the >>> (hypervisor's) GDT isn't accessible; with UMIP enabled by Xen even >>> SGDT wouldn't work, as the kernel runs in ring 3. >>> >>> There's currently no hypercall to retrieve a descriptor from the GDT. >>> It is instead assumed that kernels know where their present GDT >>> lives. Can the native_store_gdt() be replaced there, please? >>> >>> For context (I don't think it should matter much here) I'm observing >>> this with the kernel put underneath a rather old distro, where >>> hwclock triggers this path. >> >> I'd like to note that the issue still exists in 5.16. > > I'd like to note, that I've seen no patches to that effect. I could have worded it that way as well, yes. Jan
Re: x86: insn-eval.c's use of native_store_gdt()
On Fri, Feb 04, 2022 at 03:13:52PM +0100, Jan Beulich wrote: > On 04.02.2022 15:08, Thomas Gleixner wrote: > > On Fri, Feb 04 2022 at 10:23, Jan Beulich wrote: > >> On 30.11.2021 12:09, Jan Beulich wrote: > >>> I think it is b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") > >>> which uncovered an issue with get_desc() trying to access the GDT, as > >>> introduced by 670f928ba09b ("x86/insn-eval: Add utility function to > >>> get segment descriptor"). When running in a PV domain under Xen, the > >>> (hypervisor's) GDT isn't accessible; with UMIP enabled by Xen even > >>> SGDT wouldn't work, as the kernel runs in ring 3. > >>> > >>> There's currently no hypercall to retrieve a descriptor from the GDT. > >>> It is instead assumed that kernels know where their present GDT > >>> lives. Can the native_store_gdt() be replaced there, please? > >>> > >>> For context (I don't think it should matter much here) I'm observing > >>> this with the kernel put underneath a rather old distro, where > >>> hwclock triggers this path. > >> > >> I'd like to note that the issue still exists in 5.16. > > > > I'd like to note, that I've seen no patches to that effect. > > I could have worded it that way as well, yes. Hi Jan, I am sorry I missed your email. I'll look at the issue you describe and get back to you. Thanks and BR, Ricardo