linux-kernel - Re: UIO support for >32-bit physical addresses on 32-bit platforms

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100223194946.GA1941@local>
Date:	Tue, 23 Feb 2010 20:49:47 +0100
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Greg KH <gregkh@...e.de>
Cc:	Kumar Gala <galak@...nel.crashing.org>, hjk@...utronix.de,
	"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>
Subject: Re: UIO support for >32-bit physical addresses on 32-bit platforms

On Tue, Feb 23, 2010 at 07:01:41AM -0800, Greg KH wrote:
> On Tue, Feb 23, 2010 at 08:54:16AM -0600, Kumar Gala wrote:
> > Hans, Greg,
> > 
> > We are looking at using UIO for some driver work and noticed it
> > assumes the address for MMIO regions is an 'unsigned long'.  This is a
> > problem for the platforms we have in which we support a 36-bit
> > physical address in a 32-bit machine.
> > 
> > Should we just change addr/size in struct uio_mem to u64 always?

No, if I didn't miss something important, it's not feasible IMHO.

> > At
> > first I was thinking phys_addr_t but realized the addr could be PHYS,
> > LOGICAL, or VIRTUAL.
> 
> I think that would work out fine, Hans, any ideas if this would cause
> any problems with existing code or not?

It won't work. This is not a UIO problem. UIO just passes addr to other
system functions, and all of them use "unsigned long" for these addresses.
You'd have to change the whole memory management code.

Note that members vm_start and vm_end in struct vm_area_struct are
also unsigned long. Having an u64 in the UIO core doesn't help at all.

Memory above the 4G border can only be accessed through himem mechanisms
or be mapped to an address below that border in lowlevel arch code.

In most cases, I'd say it's bad board design to have memory-mapped hardware
above the 4G border on a 32-bit machine.

Thanks,
Hans

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