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

Denial of service discussion issue #10

Open
LLFourn opened this issue Apr 19, 2023 · 1 comment
Open

Denial of service discussion issue #10

LLFourn opened this issue Apr 19, 2023 · 1 comment

Comments

@LLFourn
Copy link
Collaborator

LLFourn commented Apr 19, 2023

I think we should address denial of service and resource usage from the beginning.

General ideas

  1. Resource usage should be subjective even when federations become possible. There's no need for every carol node within a federation to agree on how much X costs or whether it's free or not. Also the amount of work done by each node is not necessarily the same (they can be activated independently).
  2. Since we have the tooling already I think it makes sense for node operators to define their policy in WASM itself. Simply point to a WASM binary in the config file that will be invoked to make decisions about things e.g. validate a macaroon.

Binary/Machine/Activation abuse

  1. An attacker can upload large binaries repeatedly to exhaust memory (or disk in the future). We can limit the number and size of binaries. We can also delete those not being used. This kind of uploading can be throttled globally and/or specifically by IP address or macaroon id.
  2. An attacker can upload a single binary that just loops forever or makes many http requests. Both can be stopped after executing for too long. HTTP requests can be throttled on a per binary basis too.
  3. We must make tools for honest developers to specify how to limit the resources of the machine and inform the host of possible abuse. For example a machine that needs to make a request at time T to do its job can tell the host if it is activated before time T to simply deny all activations before T. The machine can also inform the host if an activation was simply invalid so the host can throttle further activations by that user.
  4. Machine creation is also a vector for abuse e.g. uploading large parameterization vectors or just parameterizing a machine many times (i.e. creating lots of machines). An honestly developed machine should have a limited number of valid paramterization vectors I suppose. Creation of machines should be tightly monitored and throttled just as uploading new binaries.

All these things together hopefully mean that (i) you are limited in the number of binaries you can upload globally (ii) malicious binaries are halted before they do too much damage and (iii) honestly developed binaries are hard to abuse to consume more resources than necessary.

@LLFourn
Copy link
Collaborator Author

LLFourn commented Jun 21, 2023

Tools in wasmtime to help with this:

  • ResourceLimiter allows us to constrain memory, tables and number of instances
  • epoch_interuption allows us to make a currently running guest yield its future to make space on the scheduler for another. An idea for CPU accounting would be to check for how many epochs a guest is running for (and how many instances).

We will likely want to account for HTTP requests (and in the future) storage in some way too.

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

No branches or pull requests

1 participant