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]
Message-Id: <200703011450.50935.arnd@arndb.de>
Date:	Thu, 1 Mar 2007 14:50:50 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	cbe-oss-dev@...abs.org, michael@...erman.id.au
Cc:	linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org
Subject: Re: [Cbe-oss-dev] [PATCH 14/22] spufs: use SPU master control to prevent wild	SPU execution

On Thursday 01 March 2007, Michael Ellerman wrote:
> On Mon, 2006-11-20 at 18:45 +0100, Arnd Bergmann wrote:
> > plain text document attachment (spufs-master-control.diff)
> > When the user changes the runcontrol register, an SPU might be
> > running without a process being attached to it and waiting for
> > events. In order to prevent this, make sure we always disable
> > the priv1 master control when we're not inside of spu_run.
> 
> Hi Arnd,
> 
> Sorry I didn't comment on this when you sent it, I wasn't paying enough
> attention. This patch confuses me, you say we should make sure we always
> disable the master control when we're not inside spu_run, but I see
> several exit paths where we leave the master run bit enabled - or maybe
> I'm reading it wrong.

I think you're right, there is at least one path that I now saw
getting out of spufs_run_spu incorrectly. In particular, when
spu_reacquire_runnable() fails, we never call the master stop,
which is a bug, but should happen very infrequently in practice.
Do you see another case where we end up with the same problem?

If not, I'll prepare a patch to fix this one case.

	Arnd <><

-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ