linux-kernel - Re: [VDSO]: vdso_test failing on arm 32 bit

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: <CAOuPNLj8k0AdsOUJSgdZFNKPM0Q5bbjkSxrOCcCo+tniiXOCCw@mail.gmail.com>
Date:   Thu, 8 Feb 2018 22:23:20 +0530
From:   Pintu Kumar <pintu.ping@...il.com>
To:     "Lynch, Nathan" <Nathan_Lynch@...tor.com>
Cc:     Russell King - ARM Linux <linux@...linux.org.uk>,
        "david.brown@...aro.org" <david.brown@...aro.org>,
        open list <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [VDSO]: vdso_test failing on arm 32 bit

On Thu, Feb 8, 2018 at 9:41 PM, Lynch, Nathan <Nathan_Lynch@...tor.com> wrote:
>> I commented the device tree reading property:
>> arm,cpu-registers-not-fw-configured , from the arch/arm/kernel/vdso.c
>
> Don't do that, please. The presence of that property indicates that the counter is not suitable for use by the OS. There is nothing we can do in Linux to make the VDSO useful on this system; that is why it gets disabled at runtime.
>
> The timing measurements you get are likely tainted by garbage results from the VDSO itself.

OK thank you for your feedback.

But, we wanted to know, why vdso call timing is very high here. What
does this timing indicates?
gettimeofday: vdso: 4171 nsec/call

1) How to decide whether to enable or disable VDSO in the system, if
its not suitable.
Because in a VDSO enabled system, when we use gettimeofday API, we see
that its not falling back to the systemically, but may rather return a
garbage value from vdso itself.
If that is the case, shall we disable CONFIG_VDSO itself or keep it as it is ?

Please suggest your opinion.

2) Can you list down 1-2 arm 32-bit board, where VDSO can work perfectly ?

This will be really helpful for us to take some decision.

Thank You!
Pintu