linux-kernel - Re: [PATCH] ptp/ptp_clock.c: Correct input parameter range check

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: <CAGtA63dqBVQNzUMphSKTy_jH98YYVaxVAKYpWDFu3eCXJ0-ykQ@mail.gmail.com>
Date:   Fri, 5 Apr 2019 15:53:52 +0530
From:   Siddaraju DH <siddarajudh@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     john.stultz@...aro.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ptp/ptp_clock.c: Correct input parameter range check

Sorry if there are duplicate emails in your inbox. Trying to solve "We
accept plain text only response but the message has HTML subpart"
error from mail delivery subsystem.

Thank you for the response with example Richard.
Agree, it works. So I take back the statement in my commit message
"Since the tv_sec field will be ZERO in this range, the user will not
be able to specify the signedness of adjustment through the tv_sec
field".

Specifying a -1 ns adjustment like
    tv_sec = 0
    tv_nsec = -1
looks pretty straight forward than specifying it like
    tv_sec = -1
    tv_nsec = 999999999.

And the former way of specifying the adjustment is consistent with how
we specify the values for positive adjustments.

So, the question is "why are we blocking -ve number in tv_nsec"? As
you mentioned, end of the day it's sum of tv_sec & tv_nsec.
If there is really an advantage, just to keep things clear, we could
have made tv_nsec/usec as "unsigned long" instead of "long". Right?
For me, it doesn't look good to expect/restrict a signed input to be unsigned.

Thanks,
Siddaraju DH