linux-kernel - RE: [PATCH] ARCH: Fix 32-bit x86 MSI-X allocation leakage

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 28 Apr 2008 14:27:40 -0700
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	<torvalds@...ux-foundation.org>, <linux-kernel@...r.kernel.org>,
	<netdev@...r.kernel.org>
Subject: RE: [PATCH] ARCH: Fix 32-bit x86 MSI-X allocation leakage

> Thanks Jesse for forwarding this to me.

Yes, Jesse took care of that oversight for me.  I owe him a tasty
beverage.  :-)

> The patch below does looks ok in terms of fixing the issue 
> with respect to MSIs.
> 
> Unfortunately the entire used_vectors concept appears broken. 
>  Rusty is not taking vector_lock.  used_vectors as designed 
> can not work on x86_64 as vectors are allocated to interrupts 
> in a per cpu manner, resulting in unnecessary divergences 
> between the two pieces of code.  used_vectors is an an extra 
> data structure that we have to keep in sync, and failing to 
> keep that data structure in sync is why we have a problem.
> 
> For the concept of allocating a non 0x80 vector for 
> interrupts Rusty was on the right track.  His implementation 
> just appears to be broken in the corner cases, and has a 
> design we can not use long term.
> 
> To fix this my inclination is to revert:
> dbeb2be21d678c49a8d8bbf774903df15dd55474 (the infracture) and 
> c18acd73ffc209def08003a1927473096f66c5ad (the lguest user) as 
> we need to rework those pieces of code anyway, and then work 
> with Rusty to come up with something that we can share on x86 
> and x86_64.

Either way, I'm fine if that gets reverted or not, just as long as we
don't revert back to leaking vectors on device unload.  But if things
are somewhat functional today, I'd say leave the code in there until the
proper solution can be worked out.  Then go ahead and pull it out and
put the new bits in, so anyone currently using the functionality
provided isn't left out in the cold.  That is assuming that these bits
are being used...

Cheers,
-PJ Waskiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/