Opened 2 weeks ago

Last modified 11 days ago

#24815 assigned defect

Validate shared random state dates before each voting period

Reported by: teor Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor Version: Tor: 0.2.9.1-alpha
Severity: Normal Keywords: tor-sr, tor-ddos
Cc: Actual Points:
Parent ID: Points: 1
Reviewer: Sponsor:

Description

When tor's clock jumps, the shared random state can get out of sync with the current round.

This happens to me on a test authority on a laptop that sleeps regularly. But it could also happen to authorities that miss a voting round because they are under heavy load. (I have seen clock jumps happen on Linux and BSD under the recent heavy load.)

I see this message when I restart my authority:

Jan 07 09:48:13.179 [info] or_state_load: Loaded state from "/Users/USER/tor/auth/auth-sr-3e/state"
Jan 07 09:48:14.977 [info] disk_state_validate: SR: Disk state valid after/until times are invalid.
Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal (counters: 0 commit & 1 reveal rounds).
Jan 07 09:48:16.026 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"

Even though this message was logged just before I killed it:

Jan 07 09:47:45.328 [info] or_state_save: Saved state to "/Users/USER/tor/auth/auth-sr-3e/state"

Child Tickets

TicketStatusOwnerSummaryComponent
#24849newAdded -1 signatures to consensusCore Tor/Tor

Change History (5)

comment:1 Changed 12 days ago by dgoulet

Status: newneeds_information

I suppose you are talking about the log on Jan 7th but the upcoming round on Jan 6th:

Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal (counters: 0 commit & 1 reveal rounds).

That time (2018-01-06 23:00:00) is the valid_after from the consensus and the SR subsystem only uses the time from the consensus to take every timing decision. It updates the state when loading from disk (at bootup) or when a new consensus has just been computed.

In this case, it is when booting up (sr_init()) I presume? So it takes the consensus from disk (very old), and tries to vote with that information. Ultimately it will fail but then once your dirauth gets the latest consensus, it should sync up again with the whole dance at the next voting round.

Do you see that or I'm misunderstanding the issue or ?

comment:2 in reply to:  1 ; Changed 12 days ago by teor

Replying to dgoulet:

I suppose you are talking about the log on Jan 7th but the upcoming round on Jan 6th:

Jan 07 09:48:14.984 [info] sr_state_update: SR: State prepared for upcoming voting period (2018-01-06 23:00:00). Upcoming phase is reveal (counters: 0 commit & 1 reveal rounds).

That time (2018-01-06 23:00:00) is the valid_after from the consensus and the SR subsystem only uses the time from the consensus to take every timing decision. It updates the state when loading from disk (at bootup) or when a new consensus has just been computed.

In this case, it is when booting up (sr_init()) I presume?

No, waking from sleep.

So it takes the consensus from disk (very old), and tries to vote with that information. Ultimately it will fail but then once your dirauth gets the latest consensus, it should sync up again with the whole dance at the next voting round.

Do you see that or I'm misunderstanding the issue or ?

There are times when it never syncs up.
Sometimes it will be out of sync for hours, and other times it won't get back in sync until I restart the Tor process.

I need to do some debugging to find out why it produces a different consensus to everyone else.
I assumed it was shared random because of these warning messages.

comment:3 in reply to:  2 Changed 11 days ago by dgoulet

Replying to teor:

There are times when it never syncs up.
Sometimes it will be out of sync for hours, and other times it won't get back in sync until I restart the Tor process.

If you can attach the info logs when it is out of sync, I can look at it, in theory if the consensus you download is the latest from the network, this shouldn't happened :S.

comment:4 Changed 11 days ago by dgoulet

Owner: set to dgoulet
Status: needs_informationassigned

comment:5 Changed 11 days ago by teor

I can't do that, because the network addresses are supposed to be secret.
I'll email them instead.

Note: See TracTickets for help on using tickets.