linux-hardening - Re: [RFC PATCH 4/6] powerpc/powernv: Convert pointers to physical addresses in OPAL call args

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:   Tue, 8 Nov 2022 16:21:12 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Andrew Donnellan <ajd@...ux.ibm.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
CC:     "ruscur@...sell.cc" <ruscur@...sell.cc>,
        "cmr@...escreens.de" <cmr@...escreens.de>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: [RFC PATCH 4/6] powerpc/powernv: Convert pointers to physical
 addresses in OPAL call args



Le 04/11/2022 à 18:27, Andrew Donnellan a écrit :
> A number of OPAL calls take addresses as arguments (e.g. buffers with
> strings to print, etc). These addresses need to be physical addresses, as
> OPAL runs in real mode.
> 
> Since the hardware ignores the top two bits of the address in real mode,
> passing addresses in the kernel's linear map works fine even if we don't
> wrap them in __pa().
> 
> With VMAP_STACK, however, we're going to have to use vmalloc_to_phys() to
> convert addresses from the stack into an address that OPAL can use.


I think you should then avoid using the stack for all those parameters. 
It should be handled just like DMA in drivers : Don't use the stack, use 
kmalloc memory instead.

> 
> Introduce a new macro, stack_pa(), that uses vmalloc_to_phys() for
> addresses in the vmalloc area, and __pa() for linear map addresses. Add it
> to all the existing callsites where we pass pointers to OPAL.

You should avoid that. Instead, just use kmalloc for local data. If 
that's data you get from outside the function, use kmemdup().

Christophe