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: <482af7c4-ad9e-6054-db45-ec05249a2517@oracle.com>
Date:   Wed, 11 Aug 2021 11:05:33 -0400
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Maximilian Heyne <mheyne@...zon.de>
Cc:     Amit Shah <aams@...zon.de>, Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        Wei Liu <wei.liu@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jan Beulich <jbeulich@...e.com>,
        Malcolm Crossley <malcolm.crossley@...rix.com>,
        David Vrabel <david.vrabel@...rix.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] xen/events: Fix race in set_evtchn_to_irq


On 8/11/21 10:08 AM, Maximilian Heyne wrote:
>
> This patch sets evtchn_to_irq rows via a cmpxchg operation so that they
> will be set only once. Clearing the row was moved up before writing the
> row to evtchn_to_irq in order to not create a race once the row is
> visible for other threads. Accesses to the rows are now guarded by
> READ_ONCE and WRITE_ONCE just as for the columns in the data structure.


Is this last part really needed? We needed to do that for array elements to avoid an interrupt handler from seeing a partially updated entry but I am not sure I see how this can happen to the row pointer. The only place where it might be important is when we update the pointer to the new page but you are using cmpxchg there already.


>  
> -		evtchn_to_irq[row] = (int *)get_zeroed_page(GFP_KERNEL);
> -		if (evtchn_to_irq[row] == NULL)
> +		evtchn_row = (int *) get_zeroed_page(GFP_KERNEL);


Not directly related to this patch but I don't think we need to get a zeroed page --- we will initialize it to -1 immediately below.



-boris

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ