linux-kernel - Re: xen/evtchn.c: Interrupt for port 32, but apparently not enabled; per-user 0000000012b765d1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZqIKnydM6hjt/CEG@dingwall.me.uk>
Date: Thu, 25 Jul 2024 09:19:43 +0100
From: James Dingwall <james@...gwall.me.uk>
To: Juergen Gross <jgross@...e.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: xen/evtchn.c: Interrupt for port 32, but apparently not enabled;
 per-user 0000000012b765d1

On Wed, Jul 24, 2024 at 03:55:40PM +0200, Juergen Gross wrote:
> On 24.07.24 15:25, James Dingwall wrote:
> > I have built a kernel derived from Ubuntu's Ubuntu-hwe-6.8-6.8.0-40.40_22.04.1
> > tag.  The logs are quiet until I start the first guest which has two network
> > cards passed through.  At this point the kernel log gets flooded with the
> > warning below.  This appears to the same warning which this commit was
> > supposed to suppress:
> > 
> > 51c23bd691c0f1fb95b29731c356c6fd69925d17: xen/evtchn: avoid WARN() when unbinding an event channel
> > 
> > The tag already includes that commit and in my config:
> > 
> > $ grep CONFIG_DEBUG_SHIRQ /boot/config-6.8.0-40-generic
> > # CONFIG_DEBUG_SHIRQ is not set
> > 
> > Could there be a related change which also needs to be picked or is there
> > the possibility that there is another trigger?
> 
> As the original reporter of the issue tested the patch to fix it,
> there seems to be another trigger. :-(

I've done some more testing, if I don't pass through a pci device then the
warning does not get emitted.  It looks like the existing patch works for
actions via the xen/evtchn device.  Does xen-pciback perform operations which
bypass the functions where either `evtchn->unbinding = true` or
`evtchn->enabled = true` get set?  Perhaps when xen-pcifront is being
initialised in the guest?

Thanks,
James