Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guard against system clock moving backwards. #3679

Merged
merged 2 commits into from
Feb 27, 2020

Conversation

kormat
Copy link
Contributor

@kormat kormat commented Feb 27, 2020

The timestamp returned from the kernel is in system time. This means
it's possible for the kernel received time to appear after the
application receives the packet, which then can cause logic errors to
occur in code that depends on the ordering of these timestamps.

Also guard against this in the BR's packet processing time metric
calculation, as system time could move backwards during the processing
of a packet.


This change is Reviewable

Copy link
Contributor

@sgmonroy sgmonroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 2 of 2 files at r1.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved

Copy link
Contributor

@sgmonroy sgmonroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion (waiting on @kormat and @sgmonroy)


go/lib/overlay/conn/conn.go, line 319 at r1 (raw file):

			// Guard against the system clock moving backwards.
			if meta.Recvd.After(readTime) {
				meta.Recvd = readTime

Just note to self: this is done because meta.Recvd is effectively `rp.TimeIn.

Copy link
Contributor

@sgmonroy sgmonroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 1 of 1 files at r2.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved

The timestamp returned from the kernel is in system time. This means
it's possible for the kernel received time to appear after the
application receives the packet, which then can cause logic errors to
occur in code that depends on the ordering of these timestamps.

Also guard against this in the BR's packet processing time metric
calculation, as system time could move backwards during the processing
of a packet.
@kormat kormat merged commit 56503e2 into scionproto:master Feb 27, 2020
@kormat kormat deleted the br_clock_jump branch February 27, 2020 11:30
stygerma pushed a commit to stygerma/scion that referenced this pull request Mar 26, 2020
The timestamp returned from the kernel is in system time. This means
it's possible for the kernel received time to appear after the
application receives the packet, which then can cause logic errors to
occur in code that depends on the ordering of these timestamps.

Also guard against this in the BR's packet processing time metric
calculation, as system time could move backwards during the processing
of a packet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants