linux-kernel - Re: [PATCH v3 05/12] arm: vdso: do calculations outside reader loops

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

Message-ID: <20171031103615.urjintbmv4i5cw4a@lakrids.cambridge.arm.com>
Date:   Tue, 31 Oct 2017 10:36:16 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Mark Salyzyn <salyzyn@...roid.com>
Cc:     linux-kernel@...r.kernel.org, James Morse <james.morse@....com>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Andy Lutomirski <luto@...capital.net>,
        Dmitry Safonov <dsafonov@...tuozzo.com>,
        John Stultz <john.stultz@...aro.org>,
        Laura Abbott <labbott@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Andy Gross <andy.gross@...aro.org>,
        Kevin Brodsky <kevin.brodsky@....com>,
        Andrew Pinski <apinski@...ium.com>,
        linux-arm-kernel@...ts.infradead.org,
        Mark Salyzyn <salyzyn@...gle.com>
Subject: Re: [PATCH v3 05/12] arm: vdso: do calculations outside reader loops

On Mon, Oct 30, 2017 at 01:27:22PM -0700, Mark Salyzyn wrote:
> Thanks for the review, am taking all the points into consideration.
> 
> On 10/30/2017 07:15 AM, Mark Rutland wrote:
> > > +
> > > +	typeof(((struct vdso_data *)vd)->xtime_clock_sec) sec;
> > Why do we need to do this typeof() magic?
> > 
> > Can't we settle on a consistent type across arches, or have a typedef in
> > a header?
> 
> Would you accept 'because I do not want to standardize the sizes yet'?

Well, a typedef would solve that issue. e.g. each arch can have:

  typedef u64 vdso_xtime_sec_t;

... or

  typedef u32 vdso_xtime_sec_t;

... in headers for native/compat, and the above can be:

  vdso_xtime_sec_t sec

... with the same type in the relevant struct.

That way the type can differ per arch. If we want to do something more
complicated later, we can always rework the code.

Thanks,
Mark.