netdev - Re: [PATCH net] ptp_qoriq: Don't write system time into PHC at boot

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: <20191001023742.GE1497@localhost>
Date:   Mon, 30 Sep 2019 19:37:42 -0700
From:   Richard Cochran <richardcochran@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     yangbo.lu@....com, davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net] ptp_qoriq: Don't write system time into PHC at boot

On Sun, Sep 29, 2019 at 01:22:28AM +0300, Vladimir Oltean wrote:
> But I couldn't find a justification to just move the spin_lock_init a
> few lines above, because I don't see why the ptp_qoriq_settime call
> should be done at all at probe time. Writing a CLOCK_REALTIME value into
> a timer that is supposed to track CLOCK_TAI means there will be a 37
> second offset that's going to render it useless for any practical
> purpose.

Rhetorical question:  Is off-by-37 more wrong than 1970?

Some PHC drivers start counting from zero (1970), and some from the
system time (which might be any value at all).  It really doesn't
matter what the initial value is, IMHO, because it will always be
wrong.

> So just remove the ptp_qoriq_settime call and let the clock tick in 1970
> until user space does something about it. Most other PTP drivers do the
> same, except chelsio cxgb4 and maybe a few others.

Not sure about "most".

Please fix the actual bug, the spin lock issue, and don't worry about
changing the initial value.

Thanks,
Richard