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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 9 Oct 2021 11:24:14 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Sebastien Laveze <sebastien.laveze@....nxp.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 Fri, Oct 08, 2021 at 09:13:58AM +0200, Sebastien Laveze wrote:
> On Thu, 2021-10-07 at 13:19 -0700, Richard Cochran wrote:

> > 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

Sorry, the kernel still must function correctly, even when user space
does crazy stuff.

> > 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 ?

Show that it always works, even with worst case crazy adjustments.

Thanks,
Richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ