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
