[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
x86: insn-eval.c's use of native_store_gdt()
- To: Ricardo Neri <ricardo.neri-calderon@xxxxxxxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Tue, 30 Nov 2021 12:09:15 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wW7XifaUEYXLL4FguvwqN0+Lhg2xtOpvU/gE1fjfuIE=; b=eXCO2MEL1gljxyr4oAyH8I3K+shwPauEU62Jt6vHG+Npj0jYZNNkFtsQ+OjJqQ2EcGLN/Xsk/i5kXWAB4ftcdt2eVh1H3DTiZdljsroDhFbj0p+HYzqoi6BMPJjW2TXZuekWV/C7YOcDozz5NEqhjWJjCuDQWBHzTJHH0pSmr33j/d7uXyA3cp8bLi8ihKJC5+dCMq3Feic0GOxFxihwAsCnHWXol0DGByjHKFo0iYIk3WUjlDWBTntuRoDHevGBrh+4lXT8EBeBkXv3aFe6RayYsS+UJEvSgBhogt4od9C/9igVw/9TQ6koNhRBQI1GlQMMyFrKN3aVxi1VjFUbHg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JMvILX4eLttZ/ZpfTb8/b4nXHW+efh12l7ALvb/LXBR0WSkfR+DGR6CJcIndiGLRC9H4UAu/4ppN+Dd+f19JPRxXNlnPOiJclE+M9EAUQx0Zg18/mfgqOYe+6xR8/DOiLug4VqQVyQt6d1DaeIDeBgQIru2qkP/b63eZlW25CRVquNevx5zlbbtGJ08LeMq26nB5kiywZDxRupLqnFB5/NvRtd+BPCpNqpkLEGeRPog11xer7cZWKWalo9MbFKMu8r1uDwTaRT91kdgdvzhdtR9LT08tCYSae0P9fYLwHowTwaltiE7Y6DAkz8FiwEbTaqfjK4RE81XHEh+Np/8Xgg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>
- Delivery-date: Tue, 30 Nov 2021 11:09:39 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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
|
