linux-kernel - MIPS: c17a6554 broke 64BIT_PHYS

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

Message-ID: <5172631E.6050305@corelatus.se>
Date:	Sat, 20 Apr 2013 11:42:54 +0200
From:	Thomas Lange <thomas@...elatus.se>
To:	ralf@...ux-mips.org
CC:	linux-kernel@...r.kernel.org
Subject: MIPS: c17a6554 broke 64BIT_PHYS_ADDR for 32 bit systems

Dear Ralf,

commit c17a6554 unintentionally(?) modified the PAGE_MASK type
from (int) to (long unsigned int).

This breaks ioremap (and possibly more) when using 64BIT_PHYS_ADDR on
32 bit systems.
Example of failing code from ioremap.c:

	phys_addr &= PAGE_MASK;

Since phys_addr is 64 bit (unsigned long long) when 64BIT_PHYS_ADDR and
PAGE_MASK is 32bit (long unsigned int), the upper 32 bits will always
be zeroed which is not what we want/expect.

The code above works if PAGE_MASK is a _signed_ 32bit int though.

Some possible fixes:

A) Simply revert the commit. Makes ioremap work again, but then PAGE_MASK
    is a signed int. Do we really want a mask that is 'signed'?

B) Don't use PAGE_MASK for physical addresses. x86 defines this:

   /* Cast PAGE_MASK to a signed type so that it is sign-extended if
      virtual addresses are 32-bits but physical addresses are larger
      (ie, 32-bit PAE). */
   #define PHYSICAL_PAGE_MASK	(((signed long)PAGE_MASK) & __PHYSICAL_MASK)

   Perhaps mips need something similar?

This is an issue with 3.8 and doesn't seem to be solved in master either.

Regards,
/Thomas
--
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/