linux-kernel - Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock

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: <CAOFt0_AvGQcxHAToEevTFt5JGiuhN03XnPxxjQizbZ3dC-06mg@mail.gmail.com>
Date:	Wed, 28 Oct 2015 19:04:50 +0000
From:	Alex Smith <alex@...x-smith.me.uk>
To:	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
Cc:	David Daney <ddaney.cavm@...il.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Markos Chandras <markos.chandras@...tec.com>,
	linux-mips <linux-mips@...ux-mips.org>,
	Alex Smith <alex.smith@...tec.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()

On 28 October 2015 at 18:57, Leonid Yegoshin <Leonid.Yegoshin@...tec.com> wrote:
> On 10/28/2015 11:30 AM, Alex Smith wrote:
>>
>> On 28 October 2015 at 18:21, Leonid Yegoshin <Leonid.Yegoshin@...tec.com>
>> wrote:
>>>
>>>
>>>
>>> 1) I don't see that in code - there is no check that kernel uses actually
>>> uses R4K clocksource as primary (A), and if kernel uses R4K count as a
>>> clocksource and later switches to some more precise clocksource then there
>>> is no change in VDSO gettimeofday handling (B).
>>
>> Incorrect. The vdso_clock_mode flag in arch_clocksource_data that I
>> mentioned in my previous email is copied into the VDSO data page by
>> update_vsyscall(), which is called when the clocksource changes.
>
>
> OK, I see this, good.
>
>>
>>> 2) The fact that MIPS kernel as today uses CP0_COUNT in any core as the
>>> same clocksource is correct only until first power saving event with CPU
>>> clock disabled (skipping Octeon). After that it is an incorrect use without
>>> an accurate synchronization and that synchronization doesn't exist.
>>>
>>> And I remember that today kernel uses only CPU0 CP0_COUNT to update
>>> time... may be wrong, need to check, but that could be a good code.
>>>
>>>> Maybe I'm missing something but I don't see anything in the generic
>>>> timekeeping code that handles the same clocksource being
>>>> unsynchronised or running at a different rate on different CPUs.
>>>
>>>
>>> (I would like to skip here the generic timekeeping code capabilities,
>>> just to restrict a discussion to HW capabilities)
>>>
>>>> Given that, if you think there is an issue that prevents the VDSO from
>>>> using it then that would surely affect the kernel as well and needs to
>>>> be fixed separately?
>>>>
>>>> If it really is necessary to prevent the VDSO from using a certain
>>>> clocksource even though the kernel is using it, it should be a simple
>>>> matter of setting clocksource.archdata.vdso_clock_mode to
>>>> VDSO_CLOCK_NONE. This is how this patch stops it using the CP0 count
>>>> when RDHWR is broken.
>>>
>>>
>>> OK, just put kernel-build time check that it is not SMP without GIC
>>> clocksource or it is Octeon. It would be enough to stop a mess.
>>
>> If you feel it's necessary then please do.
>
>
> Please resend a patch with this fix.

As I've explained the VDSO will only use the CP0 counter in the same
situations that the kernel would when it is the active clocksource.
Any issue that makes the counter unreliable affects the kernel as well
and is unrelated to the VDSO, so a fix does not belong in this patch.

Alex

>
> - Leonid.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/