linux-kernel - Re: [PATCH] lib/vdso: Use __arch_use

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: <alpine.DEB.2.21.1910191156240.2098@nanos.tec.linutronix.de>
Date:   Sat, 19 Oct 2019 12:01:32 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Huacai Chen <chenhc@...ote.com>
cc:     Andy Lutomirski <luto@...nel.org>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
        Paul Burton <paul.burton@...s.com>,
        "open list:MIPS" <linux-mips@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] lib/vdso: Use __arch_use_vsyscall() to indicate
 fallback

On Sat, 19 Oct 2019, Huacai Chen wrote:
> On Fri, Oct 18, 2019 at 11:15 AM Andy Lutomirski <luto@...nel.org> wrote:
> >
> > On Thu, Oct 17, 2019 at 7:57 PM Huacai Chen <chenhc@...ote.com> wrote:
> > >
> > > In do_hres(), we currently use whether the return value of __arch_get_
> > > hw_counter() is negtive to indicate fallback, but this is not a good
> > > idea. Because:
> > >
> > > 1, ARM64 returns ULL_MAX but MIPS returns 0 when clock_mode is invalid;
> > > 2, For a 64bit counter, a "negtive" value of counter is actually valid.
> >
> > s/negtive/negative
> >
> > What's the actual bug?  Is it that MIPS is returning 0 but the check
> > is < 0?  Sounds like MIPS should get fixed.
> My original bug is what Vincenzo said, MIPS has a boot failure if no
> valid clock_mode, and surely MIPS need to fix. However, when I try to
> fix it, I found that clock_getres() has another problem, because
> __cvdso_clock_getres_common() get vd[CS_HRES_COARSE].hrtimer_res, but
> hrtimer_res is set in update_vdso_data() which relies on
> __arch_use_vsyscall().

__arch_use_vsyscall() is a pointless exercise TBH. The VDSO data should be
updated unconditionally so all the trivial interfaces like time() and
getres() just work independently of the functions which depend on the
underlying clocksource.

This functions have a fallback operation already:

Let __arch_get_hw_counter() return U64_MAX and the syscall fallback is
invoked.

__arch_use_vsyscall() should just be removed.

Thanks,

	tglx