Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp4136482pxb; Mon, 27 Sep 2021 10:07:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzyQrqbp3oNLNk+5wx59n4k3dUsVcQa/3YSHBDMxUSakWfFlOYU350sZyy1i1iR+T5Ec8lc X-Received: by 2002:a17:906:a195:: with SMTP id s21mr1184420ejy.181.1632762461358; Mon, 27 Sep 2021 10:07:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632762461; cv=none; d=google.com; s=arc-20160816; b=HQekbwP5zJ17yROWKrzDzbCRbkKCq+c8cX251lGTi7Kjcw3S3zXGUJP7ziEFVwvbFZ TQwI/owtW/P1FnpvjDHUdnEENW13JLDnAhDrxEWtMbGzX3ZbGnRB7crs0IAeBi9335wb wfZv16yPZ77ddTzk0e1x9auGO4MY2phh77cXBPOt2asi/lGPuvF//viy2cgl5PSSmeS6 B5WthzsWlZFXnNctH01/s8pLVBkNb/kdlTpm3s+nhFsmnavaA/PisEXYTTaKZcTW0tJP +pNO68YcceBYBXkWryCM0LYiS9JQleo6eOuYMUTXQFzWT1Kz6R2akbRBccicHgamMywX BPmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=/QJr79qFm4wqf6dli2g8C07IT9oXtsucZY+0DW+bQes=; b=jAfyDEKUskbcSy2oE9koxR9gkl2eQ3atUO7GxB9d2mJrvqfGgBnQ5NgL0U1DneHCkS i4wVave+QcDHpNmYx9iPnbEHuTQSeIPd/ba3uP729okaNgl45izH3rJsQp7+INElXKpD P7oWkPqIzNwp0qciOWKj7mqCCGoTJAggbn8x03W88jJ0Ld6vxJ0G6rwwS9aDjgoSUJvb Lr9EA4WUE8T8JkxV4PE4j2j05RdL9s2CXwVL7QbP+Xh/5n9bq1R+8xUla6A2Yu5FhanS dJC07SDq6L5rWDy9bweDGwhP8IR6ipXPmTz0fMoH9IohmqXudQyT5u3P6dRylh4c+bZl ySOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=fv19cLGP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k27si19706647eji.724.2021.09.27.10.07.15; Mon, 27 Sep 2021 10:07:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=fv19cLGP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235875AbhI0RHG (ORCPT + 99 others); Mon, 27 Sep 2021 13:07:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:45282 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236045AbhI0RGb (ORCPT ); Mon, 27 Sep 2021 13:06:31 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id CA72C60F46; Mon, 27 Sep 2021 17:04:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1632762293; bh=0bfjiDnLESLQVkxYvEfjNJpXlKTuywxREWJMFkHMcLw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fv19cLGPJNoFWvLRwlTu8xrLDc7S2lNDF+oPncgYrZXtPJOIYPR0DJVtB1PJulzpc a1EKOViYcrhGLVPAUkCkRKaAwYb4IV2W9fldyXjzfW1XI2v/4Bfjv/BmuaMV6GHhns 7lOajqhWFVO8OSi9Yl/QYukE/F3Wm9/1aGZGI1es= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jan Beulich , Boris Ostrovsky , Juergen Gross Subject: [PATCH 5.4 07/68] xen/x86: fix PV trap handling on secondary processors Date: Mon, 27 Sep 2021 19:02:03 +0200 Message-Id: <20210927170220.159930827@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210927170219.901812470@linuxfoundation.org> References: <20210927170219.901812470@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jan Beulich commit 0594c58161b6e0f3da8efa9c6e3d4ba52b652717 upstream. The initial observation was that in PV mode under Xen 32-bit user space didn't work anymore. Attempts of system calls ended in #GP(0x402). All of the sudden the vector 0x80 handler was not in place anymore. As it turns out up to 5.13 redundant initialization did occur: Once from cpu_initialize_context() (through its VCPUOP_initialise hypercall) and a 2nd time while each CPU was brought fully up. This 2nd initialization is now gone, uncovering that the 1st one was flawed: Unlike for the set_trap_table hypercall, a full virtual IDT needs to be specified here; the "vector" fields of the individual entries are of no interest. With many (kernel) IDT entries still(?) (i.e. at that point at least) empty, the syscall vector 0x80 ended up in slot 0x20 of the virtual IDT, thus becoming the domain's handler for vector 0x20. Make xen_convert_trap_info() fit for either purpose, leveraging the fact that on the xen_copy_trap_info() path the table starts out zero-filled. This includes moving out the writing of the sentinel, which would also have lead to a buffer overrun in the xen_copy_trap_info() case if all (kernel) IDT entries were populated. Convert the writing of the sentinel to clearing of the entire table entry rather than just the address field. (I didn't bother trying to identify the commit which uncovered the issue in 5.14; the commit named below is the one which actually introduced the bad code.) Fixes: f87e4cac4f4e ("xen: SMP guest support") Cc: stable@vger.kernel.org Signed-off-by: Jan Beulich Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/7a266932-092e-b68f-f2bb-1473b61adc6e@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman --- arch/x86/xen/enlighten_pv.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -727,8 +727,8 @@ static void xen_write_idt_entry(gate_des preempt_enable(); } -static void xen_convert_trap_info(const struct desc_ptr *desc, - struct trap_info *traps) +static unsigned xen_convert_trap_info(const struct desc_ptr *desc, + struct trap_info *traps, bool full) { unsigned in, out, count; @@ -738,17 +738,18 @@ static void xen_convert_trap_info(const for (in = out = 0; in < count; in++) { gate_desc *entry = (gate_desc *)(desc->address) + in; - if (cvt_gate_to_trap(in, entry, &traps[out])) + if (cvt_gate_to_trap(in, entry, &traps[out]) || full) out++; } - traps[out].address = 0; + + return out; } void xen_copy_trap_info(struct trap_info *traps) { const struct desc_ptr *desc = this_cpu_ptr(&idt_desc); - xen_convert_trap_info(desc, traps); + xen_convert_trap_info(desc, traps, true); } /* Load a new IDT into Xen. In principle this can be per-CPU, so we @@ -758,6 +759,7 @@ static void xen_load_idt(const struct de { static DEFINE_SPINLOCK(lock); static struct trap_info traps[257]; + unsigned out; trace_xen_cpu_load_idt(desc); @@ -765,7 +767,8 @@ static void xen_load_idt(const struct de memcpy(this_cpu_ptr(&idt_desc), desc, sizeof(idt_desc)); - xen_convert_trap_info(desc, traps); + out = xen_convert_trap_info(desc, traps, false); + memset(&traps[out], 0, sizeof(traps[0])); xen_mc_flush(); if (HYPERVISOR_set_trap_table(traps))