On Wed, Feb 21, 2018 at 1:03 AM, Ard Biesheuvel
<ard.biesheuvel@xxxxxxxxxx> wrote:
>
> The thing I like about rate limiting (for everyone including root) is
> that it does not break anybody's workflow (unless EFI variable access
> occurs on a hot path, in which case you're either a) asking for it, or
> b) the guy trying to DoS us), and that it can make exploitation of any
> potential Spectre v1 vulnerabilities impractical at the same time.
I do agree that ratelimiting would seem to be the simple solution.
We _would_ presumably need to make it per-user, so that one user
cannot just DoS another user.
But it should be fairly easy to just add a 'struct ratelimit_state' to
'struct user_struct', and then you can easily just use
'&file->f_cred->user->ratelimit'
and you're done. Make sure the initial root user has it unlimited, and
limit it to something reasonable for all other user allocations.
So I think a rate-limiting thing wouldn't be overly complicated. We
could make the rate-limiting be some completely generic thing, not
tying it to efivars itself, but just saying "this is for random
"occasional" things where we are ok with a user doing a hundred
operations per second, but if somebody tries to do millions, they get
shut down".
Realistically, even root is fine with those, but letting root in the
initial namespace be entirely unlimited is obviously a pretty
reasonable thing to do.
So it might be a few tens of lines of code or something, including the
initialization of that new user struct entry.
I think the real issue is testing and just doing it.
Anybody?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
