[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jan 2016 00:51:17 +0100
From: Jann Horn <jann@...jh.net>
To: Daniel Axtens <dja@...ens.net>
Cc: kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
HATAYAMA Daisuke <d.hatayama@...fujitsu.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>, Baoquan He <bhe@...hat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: [RFC] kernel/panic: place an upper limit on number of oopses
On Wed, Jan 13, 2016 at 10:34:39AM +1100, Daniel Axtens wrote:
> Jann Horn <jann@...jh.net> writes:
> > + * limit is reached, just panic.
> > + * The constant used as limit should be low enough to
> > + * mitigate this kind of exploitation attempt, but high
> > + * enough to avoid unnecessary panics.
> > + */
> > + if (atomic_inc_return(&oops_counter) >= 0x100000 &&
> > + panic_on_oops == 0) {
> Do you need to check panic_on_oops? If it was 1 you'd already have
> paniced, right?
[...]
> > + pr_emerg("oopsed too often, setting panic_on_oops=1\n");
> > + panic_on_oops = 1;
> Would it be easier to just panic here, rather than wait for another oops?
Ah, yes. So the code would be just this, apart from the definition of
oops_counter:
if (atomic_inc_return(&oops_counter) >= 0x100000)
panic("oopsed too often\n");
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
