|
|
Subscribe / Log in / New account

Averting excessive oopses

Averting excessive oopses

Posted Nov 18, 2022 19:38 UTC (Fri) by xi0n (subscriber, #138144)
Parent article: Averting excessive oopses

If the concern is about an attacker who can rapidly trigger a large number of oopses to exploit some counter vulnerability, then wouldn’t it be better to track the oopses over a time window instead?

Granted, I don’t have a good mental model as to how severe an oops is. But if something like a faulty driver for an obscure device can trigger it consistently without much harm for the rest of the kernel, then I can imagine a long running system may eventually hit the limit and panic seemingly out of the blue.


to post comments

Averting excessive oopses

Posted Nov 18, 2022 20:31 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

If I were doing this kind of stuff, I'd want to involve as few components as possible. Timers seem fundamental, but not as fundamental as a simple counter.

Averting excessive oopses

Posted Nov 19, 2022 5:26 UTC (Sat) by developer122 (guest, #152928) [Link]

A timer means that an attacker merely needs to wait longer to succeed. It doesn't prevent the attack.

Meanwhile, a timer is terrible for catching normal oops, because if the problem is infrequent enough it goes completely unnoticed while the corruption it causes persists.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds