linux-kernel - Re: ARM unaligned MMIO access with attribute((packed))

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] [day] [month] [year] [list]

Message-Id: <201104281616.40253.arnd@arndb.de>
Date:	Thu, 28 Apr 2011 16:16:40 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Rabin Vincent <rabin@....in>, linux-arm-kernel@...ts.infradead.org,
	linux-usb@...r.kernel.org,
	Ulrich Weigand <Ulrich.Weigand@...ibm.com>,
	linux-kernel@...r.kernel.org, gcc@....gnu.org,
	Peter Maydell <peter.maydell@...aro.org>
Subject: Re: ARM unaligned MMIO access with attribute((packed))

On Thursday 28 April 2011, Alan Stern wrote:
> > The compiler does not complain, it just silently assumes that it needs
> > to do byte accesses. There is no way to tell the compiler to ignore
> > what it knows about the alignment, other than using inline assembly
> > for the actual pointer dereference. Most architectures today do that,
> > but on ARM it comes down to "*(u32 *)status_reg = temp".
> 
> Ah -- so the compiler associates the alignment attribute with the data 
> value and not with the variable's type?  I didn't know that.

The behavior here is unspecified because the underlying typecase
is not valid. Gcc apparently uses some heuristics trying to do
the right thing, and in recent versions that heuristic seems to
have changed.

	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/