linux-kernel - Re: IO space memcpy support for userspace.

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: <20081205.122238.12303228.davem@davemloft.net>
Date:	Fri, 05 Dec 2008 12:22:38 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	carlos@...temhalted.org
Cc:	airlied@...il.com, linux-kernel@...r.kernel.org,
	libc-alpha@...rces.redhat.com
Subject: Re: IO space memcpy support for userspace.

From: "Carlos O'Donell" <carlos@...temhalted.org>
Date: Fri, 5 Dec 2008 12:32:04 -0500

> On Thu, Dec 4, 2008 at 10:40 PM, Dave Airlie <airlied@...il.com> wrote:
> > I'm sure this has come up before and I'm sure I'll either wish I never
> > posted this or someone will show me the crisp corpse of the last guy
> > who suggested it.
> 
> Do you plan to prevent the compiler from issuing the same sorts of
> instructions that might appear in an optimized memcpy?
> 
> Isn't it dangerous to have memory that doesn't behave like normal
> memory, and yet try to treat it like normal memory?
> 
> This mismatch of abstractions is a warning that must not be ignored.

This is basically my opinion as well.

You'll pretty much need to surround accesses to these places with
accessor macros that do whatever is necessary on a given platform and
avoids the "dangerous" instructions in cases like IA64.

Treating them like normal memory isn't going to work on all systems.

BTW, the sunffb xorg driver has special code for "graphics copy"
which is essentially just a scanline by scanline GCOPY using the
MMX like stuff sparc64 has.  It also is mindful of avoiding access
patterns that are known to lock up that chip :)

That's just an aside, since sunffb doesn't provide any offscreen
pixmap memory and thus shouldn't be susceptible to this problem being
discussed here.

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