[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+uNU+wqWoCV+Kpdp+DQer4E3VuwO0mtXiW3Dtw_61QKA@mail.gmail.com>
Date: Wed, 30 Aug 2017 21:01:55 -0700
From: Kees Cook <keescook@...omium.org>
To: Mike Galbraith <efault@....de>,
"David S. Miller" <davem@...emloft.net>
Cc: LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
Network Development <netdev@...r.kernel.org>
Subject: Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement
fast refcount overflow protection
On Wed, Aug 30, 2017 at 8:12 PM, Mike Galbraith <efault@....de> wrote:
> On Wed, 2017-08-30 at 19:27 -0700, Kees Cook wrote:
>
>> Interesting! Can you try with 633547973ffc3 ("net: convert
>> sk_buff.users from atomic_t to refcount_t") reverted? I'll see if
>> running haveged will help me trigger this on my system...
>
> With that (plus 230cd1279d001 fix to it) reverted, vbox boots.
Wonderful! Thank you so much for helping track this down.
So, it seems that sk_buff.users will need some more special attention
before we can convert it to refcount.
x86-refcount will saturate with refcount_dec_and_test() if the result
is negative. But that would mean at least starting at 0. FULL should
have WARNed in this case, so I remain slightly confused why it was
missed by FULL.
Ingo, I'm not sure the best path for this. It seems we need to revert
230cd1279d001 and 633547973ffc3 and then we can restore
ARCH_HAS_REFCOUNT.
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists