From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755689AbcCPVO3 (ORCPT ); Wed, 16 Mar 2016 17:14:29 -0400 Received: from mail.kernel.org ([198.145.29.136]:37885 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751390AbcCPVO2 (ORCPT ); Wed, 16 Mar 2016 17:14:28 -0400 From: Andy Lutomirski To: x86@kernel.org, Andrew Cooper , Jan Beulich Cc: Borislav Petkov , David Vrabel , Boris Ostrovsky , linux-kernel@vger.kernel.org, Andy Lutomirski Subject: [PATCH v4 0/3] Xen iopl fixes Date: Wed, 16 Mar 2016 14:14:19 -0700 Message-Id: X-Mailer: git-send-email 2.5.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all- For those who are seeing this for the first time: any 64-bit Xen PV domain with IO port access privileges (in practice, this means dom0 AFAIK) and any user programs that use iopl(3) (various old X drivers, presumably) is probably vulnerable to privilege escalations by unprivileged programs running in the same PV domain. There's a long public description of the issue here: http://xenbits.xen.org/xsa/advisory-171.html Changes from v3: - Add Jan's R-b. - No longer embargoed Changes from v2: Pretend v2 never happened... Changes from v1: Use xen/hypervisor.h instead of xen-ops.h (Jan) Andy Lutomirski (3): selftests/x86: Add a iopl test x86/iopl/64: Properly context-switch IOPL on Xen PV x86/iopl: Fix iopl capability check on Xen PV arch/x86/include/asm/xen/hypervisor.h | 2 + arch/x86/kernel/ioport.c | 12 ++- arch/x86/kernel/process_64.c | 12 +++ arch/x86/xen/enlighten.c | 2 +- tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/iopl.c | 135 ++++++++++++++++++++++++++++++++++ 6 files changed, 160 insertions(+), 5 deletions(-) create mode 100644 tools/testing/selftests/x86/iopl.c -- 2.5.0