linux-kernel - Re: [PATCH resend 5/9] MIPS: sync after cacheflush

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:	Tue, 19 Oct 2010 21:11:51 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Ralf Baechle <ralf@...ux-mips.org>
cc:	Kevin Cernekee <cernekee@...il.com>,
	Shinya Kuribayashi <skuribay@...ox.com>,
	linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH resend 5/9] MIPS: sync after cacheflush

On Tue, 19 Oct 2010, Ralf Baechle wrote:

> See R4000 User's Manual Version 2, page 326, "Uncached Loads and Stores".
> Of course this can only happen on cache coherent or multiprocessor systems.
> I guess none of the supported DEC MIPS systems is affected.

 Since none of the R4k DECstations is coherent or MP, I have not 
considered these implications.  The only MP DECsystem (there was no 
workstation variation), that is the 5800, was built with R3k chips in the 
first place and the chance we ever come across one, let alone support it, 
is epsilon.

 That said, R4k DECstations seem to perform aggressive write buffering in 
the chipset and to make sure a write has propagated to an MMIO register a 
SYNC and an uncached read operation are necessary.  The read may be from 
elsewhere apparently -- RAM at 0 seems just fine -- so the chipset seems 
to obey the SYNC semantics.

 I haven't investigated DMA dependencies and I think we currently only 
have one TURBOchannel device/driver only (that is the DEFTA/defxx FDDI 
thingy) making use of the generic DMA API on DECstations.  It seemed to 
work correctly the last time I tried; presumably either because the API 
Does The Right Thing, or by pure luck and right timings.  Note that the 
DEC/Motorola CAMEL FDDI chipset was quite an aggressive DMA agent for its 
time, certainly capable of saturating some lower-clocked implementations 
of the I/O bus.

 Then I think the onboard devices that do third-party DMA via the IOASIC 
such as the LANCE Ethernet are too obscure/arcane to consider them here 
and get any useful results -- any inconsistencies may well be masked by 
the odd sequences used to access the respective chips.  There were some 
hardly documented chipset errata too, making the whole thing yet more 
complicated and causing some "impossible" error scenarios.

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