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

quick fix for OOM panic that has been plaguing us #1181

Merged
merged 1 commit into from
May 5, 2015
Merged

Conversation

whyrusleeping
Copy link
Member

I'm pretty sure this is the right way to address this, but it could definitely use a look over and some thought.

@whyrusleeping whyrusleeping added kind/bug A bug in existing code (including security flaws) topic/libp2p Topic libp2p status/in-progress In progress labels May 2, 2015
@@ -130,6 +134,10 @@ func (r *etmReader) Read(buf []byte) (int, error) {
return 0, err
}

if fullLen > MaxMsgSize {
return 0, ErrMaxMessageSize
}
Copy link
Member

Choose a reason for hiding this comment

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

oh this makes sense. we may want to bump it even lower. what's going on here is that length prefix may receive random input from the other side, interpreting it as a length.

what's weird to me is that this happens after encryption has been setup correctly. it would make more sense if we were seeing this before the handshake finished-- meaning we're speaking to something else entirely.

This problem suggests we should use a well-defined small header as the first message (i.e. like the protocol-stream idea), before reading "length prefixes" from the network. (that, or cap the lengths to a reasonable size always. (e.g. handshake messages should be below 4KB)

@cryptix
Copy link
Contributor

cryptix commented May 2, 2015

Yeah, not great but LGTM. We might want to merge the go-msgio quickfix, too.

@jbenet
Copy link
Member

jbenet commented May 2, 2015

This LGTM. see my comment above o/ -- the problem is larger. perhaps we should make msgio readers have a tunable max size. the handshake messages shouldn't be very large.

@cryptix jbenet/go-msgio#4 is merged. we may want to make it tunable, because most msgio messages will be well below 512MB. (even well below 1MB)

@cryptix
Copy link
Contributor

cryptix commented May 2, 2015

@cryptix jbenet/go-msgio#4 is merged. we may want to make it tunable, because most msgio messages will be well below 512MB. (even well below 1MB)

Yup, but we need update our godep here, I think. I also think that 512mb is too much, just wanted something that doesn't instantly oom every maschine.

@whyrusleeping
Copy link
Member Author

@cryptix Think of the Pis!

@jbenet
Copy link
Member

jbenet commented May 2, 2015

8MB should be a good upper limit


Sent from Mailbox

On Sat, May 2, 2015 at 1:42 PM, Jeromy Johnson notifications@github.com
wrote:

@cryptix Think of the Pis!

Reply to this email directly or view it on GitHub:
#1181 (comment)

@whyrusleeping
Copy link
Member Author

@jbenet what do you want done here?

@jbenet
Copy link
Member

jbenet commented May 4, 2015

@whyrusleeping happy to merge this but it's a bandaid -- larger fix needed.

@whyrusleeping
Copy link
Member Author

@jbenet what larger fix are you thinking about?

@jbenet
Copy link
Member

jbenet commented May 4, 2015

The larger fix needed is to (any or maybe all):

  • drop down msgio limit to ~8MB or so.
  • add a header prefix to the handshake protocol that must match (not a roundtrip, just a prefix that should match before any allocation from a varint given by the network is made)
  • make sure the allocations done by the handshake protocol are well below some limits, else i can feed a protobuf with an enormous varint in the bytes field, and force a huge allocation client side.

jbenet added a commit that referenced this pull request May 5, 2015
quick fix for OOM panic that has been plaguing us
@jbenet jbenet merged commit b71b727 into master May 5, 2015
@jbenet jbenet deleted the fix/mega-read branch May 5, 2015 04:58
@jbenet jbenet removed the status/in-progress In progress label May 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws) topic/libp2p Topic libp2p
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants