netdev - Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

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:   Fri, 08 Oct 2021 09:13:58 +0200
From:   Sebastien Laveze <sebastien.laveze@....nxp.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        yangbo.lu@....com, yannick.vignon@....nxp.com,
        rui.sousa@....nxp.com
Subject: Re: [PATCH net-next] ptp: add vclock timestamp conversion IOCTL

On Thu, 2021-10-07 at 13:19 -0700, Richard Cochran wrote:
> On Thu, Oct 07, 2021 at 03:31:43PM +0200, Sebastien Laveze wrote:
> > For example:
> > Let's take a worst case, the PHC is adjusted every 10 ms, vclock every
> > 1 sec with 1 ppm error.
> 
> You can't justify adjusting the HW clock and the vclocks
> asynchronously with a single, isolated example.

This was a single worst case example, many asynchronous PHC adjustments
impacting vclocks.

> If two independent processes are both adjusting a clock concurrently,
> asynchronously, and at different control rates, the result will be
> chaos.

This is especially what we want to prove feasible and we think it's
posssible with the following conditions:
-limited frequency adjustments
-offset adjustment in software

> It does not matter that it *might* work for some random setup of
> yours.
> 
> The kernel has to function correctly in general, not just in some
> special circumstances.

Of course, so what tests and measurements can we bring on the table to
convince you that it doesn't lead to chaos ?

Thanks,
Sebastien