linux-kernel - Re: [RFC PATCH v1 00/17] ban the use of _PAGE_XXX flags outside platform specific code

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: <8736uneylc.fsf@linux.ibm.com>
Date:   Thu, 06 Sep 2018 15:28:55 +0530
From:   "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
To:     Christophe Leroy <christophe.leroy@....fr>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>, npiggin@...il.com,
        aneesh.kumar@...ux.vnet.ibm.com
Cc:     linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC PATCH v1 00/17] ban the use of _PAGE_XXX flags outside platform specific code

Christophe Leroy <christophe.leroy@....fr> writes:

> Today flags like for instance _PAGE_RW or _PAGE_USER are used through
> common parts of code.
> Using those directly in common parts of code have proven to lead to
> mistakes or misbehaviour, because their use is not always as trivial
> as one could think.
>
> For instance, (flags & _PAGE_USER) == 0 isn't enough to tell
> that a page is a kernel page, because some targets are using
> _PAGE_PRIVILEDGED and not _PAGE_USER, so the test has to be 
> (flags & (_PAGE_USER | _PAGE_PRIVILEDGED)) == _PAGE_PRIVILEDGED
> This has to (bad) consequences:
>
>  - All targets must define every bit, even the unsupported ones,
>    leading to a lot of useless #define _PAGE_XXX 0
>  - If someone forgets to take into account all possible _PAGE_XXX bits
>    for the case, we can get unexpected behaviour on some targets.
>
> This becomes even more complex when we come to using _PAGE_RW.
> Testing (flags & _PAGE_RW) is not enough to test whether a page
> if writable or not, because:
>
>  - Some targets have _PAGE_RO instead, which has to be unset to tell
>    a page is writable
>  - Some targets have _PAGE_R and _PAGE_W, in which case
>    _PAGE_RW = _PAGE_R | _PAGE_W
>  - Even knowing whether a page is readable is not always trivial because:
>    - Some targets requires to check that _PAGE_R is set to ensure page
>    is readable
>    - Some targets requires to check that _PAGE_NA is not set
>    - Some targets requires to check that _PAGE_RO or _PAGE_RW is set
>
> Etc ....
>
> In order to work around all those issues and minimise the risks of errors,
> this serie aims at removing all use of _PAGE_XXX flags from powerpc code
> and always use pte_xxx() and pte_mkxxx() accessors instead. Those accessors
> are then defined in target specific parts of the kernel code.

The series is really good. It also helps in code readability. Few things
i am not sure there is a way to reduce the overhead

-		access = _PAGE_EXEC;
+		access = pte_val(pte_mkexec(__pte(0)));

Considering we have multiple big endian to little endian coversion there
for book3s 64.

Other thing is __ioremap_at where we do

+       pte_t pte = __pte(flags);
 
        /* Make sure we have the base flags */
-       if ((flags & _PAGE_PRESENT) == 0)
+       if (!pte_present(pte))

-               err = map_kernel_page(v+i, p+i, flags);
+               err = map_kernel_page(v + i, p + i, pte_val(pte));


But otherwise for the series.

Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@...ux.ibm.com>