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: <1202461453.5469.217.camel@pmac.infradead.org>
Date:	Fri, 08 Feb 2008 09:04:13 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Marcin Juszkiewicz <openembedded@...rwu.biz>,
	Christoph Hellwig <hch@...radead.org>,
	Greg KH <greg@...ah.com>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arch/arm/Kconfig: Make UIO available on ARM
	architecture


On Thu, 2008-02-07 at 21:23 +0100, Sam Ravnborg wrote:
> Both situations are trivially fixable by introducing
> HAVE_IDE and HAVE_MTD.
> See attached patch.

HAVE_MTD is wrong. The actual problem we're trying to solve is that when
the architecture lacks alignment fixups, certain patterns of write
access to 16-bit or 32-bit NOR flash arrays are broken. So it's not
'MTD' which should be conditional -- but only certain configurations of
NOR flash, which could perhaps be prevented by disallowing any of the
MTD_MAP_BANK_WIDTH_* options other than MTD_MAP_BANK_WIDTH_1 from being
set.

And it's not just an ARM-specific problem; a number of our MMU-less
architectures also lack alignment traps now. It _used_ to be the case
that platforms without alignment fixups were simply considered to be
broken -- if the hardware didn't support unaligned access, either
natively or through traps, it just wasn't supported by Linux. But since
that isn't really the case any more, perhaps we should seek a better
option than just disabling certain functionality (or _not_ disabling it,
in the case of the network stack, and just kind of praying that it works
even though we don't really think it does).

We could add get_unaligned() in certain places in the code, but that
isn't ideal for the majority of architectures. What we really want, I
suppose, is get_something_which_may_be_but_probably_is_not_unaligned().

With a better name.

-- 
dwmw2

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