[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210307151920.GR472138@tassilo.jf.intel.com>
Date: Sun, 7 Mar 2021 07:19:20 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: John Wood <john.wood@....com>
Cc: Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>,
Randy Dunlap <rdunlap@...radead.org>,
Jonathan Corbet <corbet@....net>,
James Morris <jmorris@...ei.org>,
Shuah Khan <shuah@...nel.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-kselftest@...r.kernel.org,
kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v5 7/8] Documentation: Add documentation for the Brute LSM
Sorry for the late answer. I somehow missed your email earlier.
> As a mitigation method, all the offending tasks involved in the attack are
> killed. Or in other words, all the tasks that share the same statistics
> (statistics showing a fast crash rate) are killed.
So systemd will just restart the network daemon and then the attack works
again?
Or if it's a interactive login you log in again.
I think it might be useful even with these limitations, but it would
be good to spell out the limitations of the method more clearly.
I suspect to be useful it'll likely need some user space configuration
changes too.
-Andi
Powered by blists - more mailing lists