[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.