[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for-4.22 1/2] xen/arm: validate IRQs before descriptor lookup


  • To: Mykola Kvach <mykola_kvach@xxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: "Orzel, Michal" <michal.orzel@xxxxxxx>
  • Date: Fri, 10 Jul 2026 12:10:50 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=epam.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=eUsa9Mbd+fx4ThZAf+bSccMSz/Od22pJBafQPExtXdQ=; b=a52Iu/Rwze5xNDoxlJdhumu4QQs7E9X3QMk5FNnAnZr4NECbQk8cfqWX2TXPUFRVUWi/SduNnHgDLzTBWVvPvN3uhICgGx/dRB6BT7qoKY88Dj1J20iZhsZCF4Iig0/dpQYqkLBBG3ixhFJomBfzIILmjyFyj1d92ggnF1272UDdnf5CYnicDlQ2TOLiTHE+Ug8SV/BBaB7lpqpj6ibv2hFor9nuIlBlyp3tXj1i8QWTjDs1yCEDJCEgKiBEISgZPO8kxVsp0N8H7MHCHyAQAkam4TP+VcMs1K4yoePDW6/algk0N0U18x1UXdMkFE0HkVvm/1z6pBUjTC432nORqw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bPcSPNWXEY/6pmMuprSdiMAfg7HgTbjqlrNhDo53rNeHlSn7mx66c8XAs4V22DRvTbgaTGXOQa9SRe9NvPCWA/i+QdDTNteD8/qLcWRzcTYplkrhgmw9AUmotYAVPniMxghWxh/CVvQ5U9K84420ZceOHO2W74Wqi3hqdIQL5F5h7EElvqZ3gTXTXttECkR2Uzf8gyUP0H2L6BReHSjcWWtQ3aXO/ObbWta71+UjrGfCF6vtsv4d7rNqY2Fkr+A0Ytw/amnjKyP1ADQAQ8UGdqUhLpa8v2eTE5S8AROy6sFB+69OltcHY0FId7JtqiOJ7OKmYEViyO5TE0+Q6dCrdQ==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Fri, 10 Jul 2026 10:11:07 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


On 10-Jul-26 10:31, Mykola Kvach wrote:
> With GICv3 eSPI support, nr_irqs covers the architectural INTID
> namespace up to ESPI_MAX_INTID. That namespace is not backed by a
> single dense irq_desc[] array: regular SPIs use irq_desc[], eSPIs use
> espi_desc[], and the INTIDs in between must not be treated as
> descriptor indices.
> 
> A firmware-provided interrupt in the sparse range can therefore pass
> checks based only on nr_irqs and reach irq_to_desc().
What are the possible consequences? You should explain it in the commit msg.
Also, what is your criteria behind protecting irq_to_desc()? There are other
places, where we have unprotected irq_to_desc(). Last but not least I think we
should have an ASSERT in __irq_to_desc() to prevent the indexing failure if we
end up there with a sparse IRQ accidentally.

The change itself looks ok.

~Michal
> 
> Validate IRQs with the GIC line helpers before looking up descriptors
> in setup_irq(). Also validate SPI type configuration with gic_is_spi()
> before irq_set_spi_type() obtains the descriptor, covering the
> platform_get_irq() -> irq_set_type() path. The route-to-Xen assert
> becomes redundant because setup_irq() now rejects invalid IRQs before
> routing.
> 
> Fixes: 98f7060b9ed ("xen/arm/irq: add handling for IRQs in the eSPI range")
> Signed-off-by: Mykola Kvach <mykola_kvach@xxxxxxxx>
> ---
>  xen/arch/arm/gic.c | 2 --
>  xen/arch/arm/irq.c | 9 +++++++--
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index ee75258fc3..ed9870c1bd 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -111,8 +111,6 @@ static void gic_set_irq_priority(struct irq_desc *desc, 
> unsigned int priority)
>  void gic_route_irq_to_xen(struct irq_desc *desc, unsigned int priority)
>  {
>      ASSERT(priority <= 0xff);     /* Only 8 bits of priority */
> -    /* Can't route interrupts that don't exist */
> -    ASSERT(gic_is_valid_line(desc->irq));
>      ASSERT(test_bit(_IRQ_DISABLED, &desc->status));
>      ASSERT(spin_is_locked(&desc->lock));
>  
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 73e58a5108..0314cf0b6e 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -416,6 +416,9 @@ int setup_irq(unsigned int irq, unsigned int irqflags, 
> struct irqaction *new)
>      struct irq_desc *desc;
>      bool disabled;
>  
> +    if ( !gic_is_valid_line(irq) )
> +        return -EINVAL;
> +
>      desc = irq_to_desc(irq);
>  
>      spin_lock_irqsave(&desc->lock, flags);
> @@ -647,13 +650,15 @@ static bool irq_validate_new_type(unsigned int curr, 
> unsigned int new)
>  int irq_set_spi_type(unsigned int spi, unsigned int type)
>  {
>      unsigned long flags;
> -    struct irq_desc *desc = irq_to_desc(spi);
> +    struct irq_desc *desc;
>      int ret = -EBUSY;
>  
>      /* This function should not be used for other than SPIs */
> -    if ( spi < NR_LOCAL_IRQS )
> +    if ( !gic_is_spi(spi) )
>          return -EINVAL;
>  
> +    desc = irq_to_desc(spi);
> +
>      spin_lock_irqsave(&desc->lock, flags);
>  
>      if ( !irq_validate_new_type(desc->arch.type, type) )




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.