linux-kernel - Re: [PATCH] fix __percpu annotation in asm-generic

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, 3 Dec 2019 04:01:08 +0100
From:   Luc Van Oostenryck <luc.vanoostenryck@...il.com>
To:     Dennis Zhou <dennis@...nel.org>
Cc:     Christopher Lameter <cl@...ux.com>,
        Ben Dooks <ben.dooks@...ethink.co.uk>,
        linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        Tejun Heo <tj@...nel.org>, Nicholas Piggin <npiggin@...il.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] fix __percpu annotation in asm-generic

On Mon, Dec 02, 2019 at 02:07:18PM -0500, Dennis Zhou wrote:
> On Sat, Nov 30, 2019 at 01:00:37AM +0100, Luc Van Oostenryck wrote:
> > On Fri, Nov 29, 2019 at 06:11:59PM +0000, Christopher Lameter wrote:
> > > On Wed, 27 Nov 2019, Luc Van Oostenryck wrote:
> > > 
> > > > 1) it would strip any address space, not just __percpu, so:
> > > >    it would need to be combined with __verify_pcpu_ptr() or,
> > > >    * a better name should be used,
> > > 
> > > typeof_cast_kernel() to express the fact that it creates a kernel pointer
> > > and ignored the attributes??
> > 
> > typeof_strip_address_space() would, I think, express this better. 
> > It's not obvious at all to me that 'kernel' in 'typeof_cast_kernel()'
> > relates to the (default) kernel address space.
> > Maybe it's just me. I don't know.
> > 
> 
> I think typeof_cast_kernel() or typeof_force_kernel() are reasonable
> names. I kind of like the idea of cast/force over strip because we're
> really still moving address spaces even if it is moving it back.

Well, 'typeof_cast_kernel()' somehow conveys the idea but sounds
a bit weird as the macro doesn't contain a cast (expression).

> Thanks for debugging this. I'm still inclined to have a macro for either
> cast/force. I do agree it could be misused, but it's no different doing
> it in a macro than by just adding __force __kernel.

I'm glad to help making the kernel type-clean (with the goal of
catching more bugs earlier) but I admit that I absolutely detest
these layers of ugly macros. 

I'm working on a nicer implementation but it's not yet ready.

Best regards,
-- Luc