linux-kernel - Re: [PATCH] x86: Remove readq()/writeq() on 32-bit

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: <4A0B3BF3.1050804@garzik.org>
Date:	Wed, 13 May 2009 17:30:27 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Hitoshi Mitake <h.mitake@...il.com>,
	Roland Dreier <rdreier@...co.com>, Ingo Molnar <mingo@...e.hu>,
	David Miller <davem@...emloft.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	tglx@...utronix.de, rpjday@...shcourse.ca,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Remove readq()/writeq() on 32-bit

H. Peter Anvin wrote:
> Jeff Garzik wrote:
>> Roland's patch was acked, apparently, _in spite of_ the commonly 
>> accepted readq() definition already being in use!
>>
>> Thusfar, I see two things:
>>
>> (1) years of history has shown that non-atomic readq/writeq on 32-bit 
>> platforms has been sufficient, based on testing and experience.  In 
>> fact, in niu's case, a common readq/writeq would have PREVENTED a bug.
>>
>> (2) unspecified fears continue to linger about non-atomicity
>>
>> We should not base decisions on fear, particularly when the weight of 
>> evidence and experience points in the other direction.
>>
> 
> I have personally dealt with at least one device who'd want to opt out
> of a standard readq/writeq (it's not in-tree because it never shipped,
> unfortunately.)  Doing the opt-in headers seems like a reasonable thing
> to do to me, but perhaps I'm just being overly paranoid.

Isn't that a variant of "punish all sane hardware, because bizarre 
unshipped hardware exists"?

IMO the best fix is to document existing readq assumptions, and 
standardize that definition on other platforms.

The burden of special casing for bizarre hardware should not fall on 
/sane/ drivers and hardware, who should be the ones opting _out_ of the 
standard regime.

	Jeff



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