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;
Subject: Re: [PATCH v2] xen/x86: fix PV trap handling on secondary processors
To:     Jan Beulich <jbeulich@suse.com>, Juergen Gross <jgross@suse.com>
Cc:     Stefano Stabellini <sstabellini@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>,
        "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
References: <7a266932-092e-b68f-f2bb-1473b61adc6e@suse.com>
From:   Boris Ostrovsky <boris.ostrovsky@oracle.com>
Message-ID: <bbd4188c-32d1-7a5c-110e-18cf2b3223d4@oracle.com>
Date:   Mon, 20 Sep 2021 14:12:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.14.0
In-Reply-To: <7a266932-092e-b68f-f2bb-1473b61adc6e@suse.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SUVva3IzZXdIeXh4SDJ2MEdNQ281T1h4Mko0aHdlN0NXREN4YVU0c3JkMERF?=
 =?utf-8?B?T2wxQVJxRlJ5WDR4alhRQ2VuVk5YSzdkTzBoRkpsRmlyeU45L1NGQk12Tkt3?=
 =?utf-8?B?TFgxVU4wMkw4YkN2Z1RkcFJSbFdhdHovUkhPTVUxYkdnMXVndTh3UjR4Q0lq?=
 =?utf-8?B?c1pIcXZKYXNVVzV1bnF4TmhlQnlyMzNKRHdpNU1HeXZrL0JDaS9IRllYZGUy?=
 =?utf-8?B?V1JlekEzOVZCaklEUytKa3YrN2VkZHl4QlF2YWMzS1YzZzBlNXBTTmM2S0JD?=
 =?utf-8?B?enFNZXl5bGlZUjNxekNLTlZzanhtSFNuT05vM3ZnYWNHc0s0eHdsZmJBUUU1?=
 =?utf-8?B?WGJLNUdLSFZjaTF6R0ZwdnQweG1YZUFDOVNZSDdJN3dXZE1NWnI0QTVCamJ1?=
 =?utf-8?B?aytLVTl6S2hnWG1NanVGdVV6VnNxV2h3b0tDS2oxNGxIRTdVQUlUYzkrTTJz?=
 =?utf-8?B?WWovYmhWQkpVTlJ6STZzZk9wczkzV3EvSkJTRHFJQm0zSnFyb09obTB6NGpT?=
 =?utf-8?B?dWJHaTM1cFd6RCtQZHBjQk1PZFUrNWxyaS83b01kZ0hkSGFsSUtnOWNEUlBv?=
 =?utf-8?B?dEVFbjBCSGlSQlUrVVpvMVV4NFBieHNwSmp5MkZjTS9obnJ3QUp0dXBCZzhv?=
 =?utf-8?B?QU9xeWJxY0RBNHBKZkhUdjVBb2w0RVdGeGYzbUd2ZlV4TzUxK0xrNkZGQmFs?=
 =?utf-8?B?UkxsRURYVXNlVk9pVnR2NWMrNzRvU255YnpYMGpoOEtLMGJlMkV2L1V0bGlj?=
 =?utf-8?B?V2lid2NlV3dPZm5kVW1Xd01BaWtEbHo1VE9XWjRLVWdYVmxZcVU4L0IxUGRn?=
 =?utf-8?B?WUtyTDNIVnpjNkhpMmZtM0tSWDhrSDM4dEFGbVpyUlZWdEdXbVVQZ3F1Nmd3?=
 =?utf-8?B?L1NMRVJ1TWxpMUdtbkcvQzhKeGtsNmJFV3R0YUgrRXgzcmZhRUVXUnU4eGJ5?=
 =?utf-8?B?QjBjSjlIYnFsdFlLbXRNaVFIZkVuRG9Ebkx3eGlOdlgySHFMaGZpRmxGYndO?=
 =?utf-8?B?TTRocVVUdXNnTFlzdjQ0eFBPemRyVHJ2Rm05bVExWFNqaHdrbHhnNWJMY3Rn?=
 =?utf-8?B?VW1YMTR3U05xYUIrZkdRV0Uxb29nd0ZKWnd6V2ZWU3JWYVlxM216Z2VldzR2?=
 =?utf-8?B?N1BoWlQraUF3clBTWDE4RDZDMDFIRGZJNzY2MHFDTFhkUUV6ZCt0V3hBREFL?=
 =?utf-8?B?V1Z4SUpaS0RpeEtvVlN3TENzTnFIeWhnZnhPM0lQbXN5cHdOQVU5LzVYc3No?=
 =?utf-8?B?SUM3T1B4NGV2OGxKTENrRkNZL0pZZzdBRDBwOUJiMFMrLzZ6aEpsZW1BZHM5?=
 =?utf-8?B?cGpsU0QwT3ZCQnRPamNVSXl0ajlXemV3dEdiT0VvVVAyTVUrTjU2ODJNMnFN?=
 =?utf-8?B?TnQxYkdsZTVQLyt3a0t3cTZYM1AzR21TZ1lUb2tGMG93MHlHN2tlSWxic3E5?=
 =?utf-8?B?WmU0b1o2N3FEN2w3Qi9vR2NPVmJJaUk0L0cxaW9YTm5RN3Y5VTdZbVpQRUda?=
 =?utf-8?B?MnVOU1c5Y3R2WTBieVA1eC91TlErUmtiaFZDRmdQMHNhME8rbEFCeHh4VXdR?=
 =?utf-8?B?L0Vha09EUlNkQVBhZFp2T0pEZHIxem9OeE1kVGxmTWJCVGd4U2w4cEI2bmMy?=
 =?utf-8?B?dGZCVTR4amN4QVhGZXZ5QWp6ajZ1bm5pRy9xMERxRjVWUjVrUWxsVldnYkMr?=
 =?utf-8?B?aXFPa3I4aW5qdWE2d2lNZDlXd3dxMUJ1L1lJVlhSRFJLWDdiSWkzN3ZDVkxB?=
 =?utf-8?Q?5NsBnYEZwZNdaTyKDoeJFLWyx+LvtJWBxFPQfu9?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8945a0eb-a59a-418c-610b-08d97c623d81
X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB5009.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2021 18:12:43.1787
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Lma5l6P12UIm9ENV18O7DJH6xNS/YSFjh8dGwdilD5d63i8LxBZOCF3w1IrcjEdf36eUhWNqjvURaSFA/uvxHmS0Esmr0CHn3XPmS1hCGkA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR10MB2835
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10113 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 spamscore=0
 bulkscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109030001
 definitions=main-2109200108
X-Proofpoint-GUID: ALKlUnr9OjrLwS62HuMtlXehF7Ooipoy
X-Proofpoint-ORIG-GUID: ALKlUnr9OjrLwS62HuMtlXehF7Ooipoy
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 9/20/21 12:15 PM, Jan Beulich wrote:
> 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 <jbeulich@suse.com>


Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>