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]
Date:	Wed, 1 Apr 2009 22:10:45 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	"Herrera-Bendezu, Luis" <lherrera@...ris.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: UIO: uio_mem does not handle devices above 4 GB address

On Wed, Apr 01, 2009 at 01:20:49PM -0400, Herrera-Bendezu, Luis wrote:
> I am working on a PPC440EPx board with some FPGAs located at
> addresses above 4 GB

That's not exactly a good idea on a 32-bit processor. Can't you remap
that chip select to a decent address?

> and kernel version 2.6.28.7. The UIO driver is
> used to access the FPGAs. I get following error when trying to read
> FPGA registers:
> Machine check in kernel mode.
> Data Read PLB Error
> 
> The problem is traced to member addr in struct uio_mem:
> struct uio_mem {
>     unsigned long     addr;
>     unsigned long     size;
>     int               memtype;
>     void __iomem      *internal_addr;
>     struct uio_map    *map;
> };
> 
> When UIO_MEM_PHYS is used with device address > 32-bit then
> uio_mmap_physical() remaps address using idev->info->mem[mi].addr
> thus loosing high address bits.
> 
> One way to solve this problem is to change addr member to:
>     phys_addr_t       addr;

That alone won't solve the problem.

> 
> and modify corresponding attributes in uio.c. Only concern is that
> uio_vma_fault() calls virt_to_page() and vmalloc_to_page() where both
> have addr arg (unsigned long) and (const void *) respectively for
> powerpc. But these functions are only used for UIO_MEM_LOGICAL and
> UIO_MEM_VIRTUAL.

That probably won't work without large modifications.

> 
> Any alternative approach?

Yes, fix your hardware design.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ