codec/types: avoid unnecessary allocations for NewAnyWithCustomTypeURL on error

[odeke-em]

Avoids a bleed out attack in which a node can be made to allocate
memory slowly or very fast in small strides, by sending bad data
to code that invokes NewAnyWithCustomTypeURL, in which we
unconditionally returned a new Any object. On a 64-bit machine,
this would waste 96 bytes per invocation even on error.

Added a test to ensure zero allocations with a fixed error returned.
Also added a benchmark which shows reduction in wasted allocations and
wasted CPU time:

$ benchstat before.txt after.txt
name                                            old time/op    new time/op    delta
NewAnyWithCustomTypeURLWithErrorReturned-8      142ns ± 6%      55ns ±12%   -61.65%  (p=0.000 n=9+10)

name                                            old alloc/op   new alloc/op   delta
NewAnyWithCustomTypeURLWithErrorReturned-8      96.0B ± 0%      0.0B       -100.00%  (p=0.000 n=10+10)

name                                            old allocs/op  new allocs/op  delta
NewAnyWithCustomTypeURLWithErrorReturned-8      1.00 ± 0%      0.00       -100.00%  (p=0.000 n=10+10)

Fixes #8537

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[odeke-em]

I kindly request that we backport this change too.

[tac0turtle]

LGTM

[tac0turtle]

@Mergifyio backport release/v0.41.x

[mergify]

Command backport release/v0.41.x: pending

Waiting for the pull request to get merged

[tac0turtle]

I kindly request that we backport this change too.

on merge the backport should be handled unless conflicts arise.

[odeke-em]

Gotcha, thanks Marko!

…

On Wed, Feb 17, 2021 at 1:54 AM Marko ***@***.***> wrote: I kindly request that we backport this change too. on merge the backport should be handled unless conflicts arise. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8605 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFL3VZCNTKOUQ65YNXFTY3S7OG4XANCNFSM4XYA6RLQ> .

[codecov]

Codecov Report

Merging #8605 (4ff4fcb) into master (47dd07d) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #8605   +/-   ##
=======================================
  Coverage   61.47%   61.47%           
=======================================
  Files         658      658           
  Lines       37583    37585    +2     
=======================================
+ Hits        23104    23106    +2     
  Misses      12067    12067           
  Partials     2412     2412           

Impacted Files	Coverage Δ
codec/types/any.go	62.50% <100.00%> (+3.40%)	⬆️

[mergify]

Command backport release/v0.41.x: success

Backports have been created

• #8606 codec/types: avoid unnecessary allocations for NewAnyWithCustomTypeURL on error (bp #8605) has been created for branch release/v0.41.x

[robert-zaremba]

Good job.

PS: I thought we backport only fixes and significant changes? This is a micro optimization of an unhappy path
PS2: All optimizations are always good 👏

[odeke-em]

Great question Robert! I asked for a backport as it isn’t just an optimization but supposedly if someone could trivially send unmarshallable data in a fast loop they could cause memory to be allocated unnecessarily, which is why I called it a slow bleed — better for security to seal off such seemingly simple paths but that can cause unnecessary allocations.

…

On Wed, Feb 17, 2021 at 5:32 AM Robert Zaremba ***@***.***> wrote: Good job. PS: I thought we backport only fixes and significant changes? This is a micro optimization of an *unhappy* path PS2: All optimizations are always good 👏 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8605 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFL3VZ2AJNWINUGZHSNO2TS7PAOVANCNFSM4XYA6RLQ> .

[alessio]

Stable release updates are for improvements and bugfixes that don't break user code. And no, not all optimizations are always welcome. Only low risk optimizations are welcome, e.g. this one ;-)

[robert-zaremba]

if someone could trivially send unmarshallable data in a fast loop

How that can happen? Is there a way a user could exploit it? I think any TX will go out of gas and other allocations would be way more significant before something here will happen.

[odeke-em]

In relation to the motivations, it came up on my radar as a path that could be taken when ensuring that code related to ADR 20 was working alright. In regards to users exploiting it, am not too sure to craft up a direct answer but the subtlety is that if there is any adversary, assume that given the BFT properties of Tendermint, that they’ll be willing to play the long game, and any path that can be exploited will be exploited. Also it is a low risk and correctness change.

…

On Wed, Feb 17, 2021 at 5:39 AM Robert Zaremba ***@***.***> wrote: if someone could trivially send unmarshallable data in a fast loop How that can happen? Is there a way a user could exploit it? I think any TX will go out of gas and other allocations would be way more significant before something here will happen. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8605 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFL3V3QGJ3TUQ3DIZ3H6W3S7PBILANCNFSM4XYA6RLQ> .