3 ms·
Incidentally, iteration limits are a good idea for production code anyway. If you don't imagine any input needing more than 50 k iterations, throw a user-friend
by kqr 4y ago
Incidentally, iteration limits are a good idea for production code anyway. If you don't imagine any input needing more than 50 k iterations, throw a user-friendly exception after something like 10 M iterations. Prevents much more annoying problems than it causes.
- blipvert 4y agoNice. Be good if the language had an easy way to handle it, eg.: while(condition)[1000 label]{…}
- guenthert 4y ago> If you don't imagine any input needing more than 50 k iterations What could possibly go wrong.
- kqr 4y agoYou get an error is the worst that happens. Way better than running a denial of service attack on your own systems or those of your customer's.
- deleted 4y ago[deleted]
- guenthert 4y ago> You get an error is the worst that happens. That certainly depends on what eBPF is used for. If your load balancer errors out at [greatest number of connections envisioned] and an adversary manages to establish [greatest number of connections envisioned] then the result is a denial of service. Not every operator is confident in making code changes in 3rd party software or might even be allowed to make such changes. Increasing resources o.t.o.h., e.g. adding RAM, is rarely banned. I sure would want a system to make best use of available resources.
- kqr 4y agoI still think a denial of service due to tripping some sort of circuit breaker is preferable to one due to resource exhaustion. If the code is intended to use as a library or the binary distributed to third parties one will have to handle it differently. For libraries taking a parameter indicating the maximum expected is common, for example. See e.g. man 3 read.