linux-kernel - Re: alpha: potential race around hae_cache in RESTORE

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: <20100927124624.GC19804@ZenIV.linux.org.uk>
Date:	Mon, 27 Sep 2010 13:46:24 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>, rth@...ddle.net,
	linux-kernel@...r.kernel.org
Subject: Re: alpha: potential race around hae_cache in RESTORE_ALL

On Mon, Sep 27, 2010 at 01:12:28PM +0100, Al Viro wrote:
> On Mon, Sep 27, 2010 at 11:58:28AM +0400, Ivan Kokshaysky wrote:
> > On Sat, Sep 25, 2010 at 08:25:09PM +0100, Al Viro wrote:
> > > BTW, am I right assuming that HAE modifications is UP-only thing?  It would
> > > be obviously b0rken on any SMP box, since alpha_mv is not per-CPU thing...
> > 
> > The only SMP system that does HAE modifications at runtime is T2, so it has
> > a spinlock protection around set_hae() - see core_t2.h. Others are either
> > limited to use HAE window 0 only, or do not have HAE hardware at all.
> 
> Um?  Pardon me, but that makes no sense; how would a spinlock taken in
> e.g. readl() stop another process from leaving a syscall, getting to
> RESTORE_ALL and overwriting HAE register while we are halfway through
> the spinlock-protected area?

AFAICS, we have 3 variants:
	1) alpha_mv.hae_register == &alpha_mv.hae_cache; all that code
becomes a no-op.
	2) UP boxen with hae_register pointing someplace real; we save
HAE in SAVE_ALL, restore it in RESTORE_ALL and disable interrupts around
the updates of hae_cache/*hae_register to keep them in sync.  readl()
et.al. set HAE, then do memory access and rely on not giving CPU up between
these moments.  Since alpha doesn't do PREEMPT, we are OK (otherwise we'd
needed to disable preempt in those places; also not a big deal)
	3) SMP t2 boxen; we protect the entire sequence from setting HAE to
memory access with spinlock and with disabling interrupts.  We don't rely on
interrupts not modifying the damn thing, but we *do* rely on other CPU not
messing with HAE on syscall paths outside of spinlock-protected area.  And
we have RESTORE_ALL hit us on all exits to userland, interrupt, trap and
syscall alike.

	Looks like (3) has always been broken...
--
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/