From nobody Mon May 6 18:24:42 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1619015800; cv=none; d=zohomail.com; s=zohoarc; b=k5IwLr4TxqwOQB/lBJFuKaAaXCvccN2r+jD4bPs16P2sGZghM+FePTyc7EO10Huq1/Rmt3FomNs4l8BazraQTFW+ISfFKIXsJnKa1cOZV9dXhjD3Vw+xnTMC+IypH9mxw8cws9dubAC+vyeaUdUZaYapVMuVEYAyE9YQbbRdxZ8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1619015800; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=KI3pOg4xxBAkeYRJhSPaXz+5rMBvt81g2cX5nokP3Bg=; b=O5bfex2m1Dehb2s9yjhKomxeZelfTxyN4vZc9Yurbeev6RcsZOgCdZUP7Ecv5M45k/EBI8S4nKHvz8/IEMpPTREd8N4ZW6BrAR5bOqgPVe9kmbgOjXWu2w3CPZmyZCuzx/OlZI/J9Yud19qUxXB3UBgF0+3CBb8Hq7Utrj+F/r0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1619015800603683.3448858773279; Wed, 21 Apr 2021 07:36:40 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.114741.218743 (Exim 4.92) (envelope-from ) id 1lZDxr-00054r-9J; Wed, 21 Apr 2021 14:36:27 +0000 Received: by outflank-mailman (output) from mailman id 114741.218743; Wed, 21 Apr 2021 14:36:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZDxr-00054e-2V; Wed, 21 Apr 2021 14:36:27 +0000 Received: by outflank-mailman (input) for mailman id 114741; Wed, 21 Apr 2021 14:36:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lZDxq-00053X-8d for xen-devel@lists.xenproject.org; Wed, 21 Apr 2021 14:36:26 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 36d0f737-1dc0-45d9-ba99-c2510c95641b; Wed, 21 Apr 2021 14:36:25 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4C29BAF65; Wed, 21 Apr 2021 14:36:24 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 36d0f737-1dc0-45d9-ba99-c2510c95641b X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1619015784; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KI3pOg4xxBAkeYRJhSPaXz+5rMBvt81g2cX5nokP3Bg=; b=bd7bQaK+qdHw9UBTJpFyBctDPnKpImTLE0GmymXOP9hI9PHrwSxWyl6xrHJht9E8GHAVyr D91xrd8WCIYVFFB+2gg0KRYtXtDsJtGesx+IYEvT0ZoFtKDgPZ38jU6NjAPgYJ80dhx048 X/ccwjLgg7jX+IBl+/+QcuzplXXXLUg= From: Jan Beulich Subject: [PATCH v3] evtchn/fifo: don't enforce higher than necessary alignment To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , George Dunlap , Ian Jackson , Julien Grall , Wei Liu , Stefano Stabellini References: <2a08aa31-fdbf-89ee-cd49-813f818b709a@suse.com> Message-ID: Date: Wed, 21 Apr 2021 16:36:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <2a08aa31-fdbf-89ee-cd49-813f818b709a@suse.com> Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) Content-Type: text/plain; charset="utf-8" Neither the code nor the original commit provide any justification for the need to 8-byte align the struct in all cases. Enforce just as much alignment as the structure actually needs - 4 bytes - by using alignof() instead of a literal number. While relaxation of the requirements is intended here, the primary goal is to simply get rid of the hard coded number as well its lack of connection to the structure that is is meant to apply to. Take the opportunity and also - add so far missing validation that native and compat mode layouts of the structures actually match, - tie sizeof() expressions to the types of the fields we're actually after, rather than specifying the type explicitly (which in the general case risks a disconnect, even if there's close to zero risk in this particular case), - use ENXIO instead of EINVAL for the two cases of the address not satisfying the requirements, which will make an issue here better stand out at the call site. Signed-off-by: Jan Beulich --- v3: Adjust version in public header comment. v2: Add comment to public header. Re-base. --- I question the need for the array_index_nospec() here. Or else I'd expect map_vcpu_info() would also need the same. --- a/xen/common/event_fifo.c +++ b/xen/common/event_fifo.c @@ -567,6 +567,16 @@ static void setup_ports(struct domain *d } } =20 +#ifdef CONFIG_COMPAT + +#include + +#define xen_evtchn_fifo_control_block evtchn_fifo_control_block +CHECK_evtchn_fifo_control_block; +#undef xen_evtchn_fifo_control_block + +#endif + int evtchn_fifo_init_control(struct evtchn_init_control *init_control) { struct domain *d =3D current->domain; @@ -586,19 +596,20 @@ int evtchn_fifo_init_control(struct evtc return -ENOENT; =20 /* Must not cross page boundary. */ - if ( offset > (PAGE_SIZE - sizeof(evtchn_fifo_control_block_t)) ) - return -EINVAL; + if ( offset > (PAGE_SIZE - sizeof(*v->evtchn_fifo->control_block)) ) + return -ENXIO; =20 /* * Make sure the guest controlled value offset is bounded even during * speculative execution. */ offset =3D array_index_nospec(offset, - PAGE_SIZE - sizeof(evtchn_fifo_control_block_t)= + 1); + PAGE_SIZE - + sizeof(*v->evtchn_fifo->control_block) + 1= ); =20 - /* Must be 8-bytes aligned. */ - if ( offset & (8 - 1) ) - return -EINVAL; + /* Must be suitably aligned. */ + if ( offset & (alignof(*v->evtchn_fifo->control_block) - 1) ) + return -ENXIO; =20 spin_lock(&d->event_lock); =20 --- a/xen/include/public/event_channel.h +++ b/xen/include/public/event_channel.h @@ -368,6 +368,11 @@ typedef uint32_t event_word_t; =20 #define EVTCHN_FIFO_NR_CHANNELS (1 << EVTCHN_FIFO_LINK_BITS) =20 +/* + * While this structure only requires 4-byte alignment, Xen versions 4.15 = and + * earlier reject offset values (in struct evtchn_init_control) that aren'= t a + * multiple of 8. + */ struct evtchn_fifo_control_block { uint32_t ready; uint32_t _rsvd; --- a/xen/include/xlat.lst +++ b/xen/include/xlat.lst @@ -67,6 +67,7 @@ ? evtchn_bind_virq event_channel.h ? evtchn_close event_channel.h ? evtchn_expand_array event_channel.h +? evtchn_fifo_control_block event_channel.h ? evtchn_init_control event_channel.h ? evtchn_op event_channel.h ? evtchn_reset event_channel.h