Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751898AbdF3Ctj (ORCPT ); Thu, 29 Jun 2017 22:49:39 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:2986 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751333AbdF3Ctf (ORCPT ); Thu, 29 Jun 2017 22:49:35 -0400 X-Greylist: delayed 363 seconds by postgrey-1.27 at vger.kernel.org; Thu, 29 Jun 2017 22:49:32 EDT Subject: Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection To: Kees Cook References: <1496180392-98718-1-git-send-email-keescook@chromium.org> <1496180392-98718-4-git-send-email-keescook@chromium.org> <3812aec2-682f-e95c-4d61-8e7eac33cc88@huawei.com> CC: LKML , Christoph Hellwig , Peter Zijlstra , "Eric W. Biederman" , Andrew Morton , Josh Poimboeuf , PaX Team , Jann Horn , Eric Biggers , Elena Reshetova , "Hans Liljestrand" , David Windsor , "Greg KH" , Ingo Molnar , "Alexey Dobriyan" , "Serge E. Hallyn" , , Davidlohr Bueso , Manfred Spraul , "axboe@kernel.dk" , "James Bottomley" , "x86@kernel.org" , Ingo Molnar , Arnd Bergmann , "David S. Miller" , Rik van Riel , linux-arch , "kernel-hardening@lists.openwall.com" , "Wangkai (Morgan, Euler)" From: Li Kun Message-ID: Date: Fri, 30 Jun 2017 10:42:05 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.111.203.133] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.5955BA9A.0037,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 05e1b216e8fdd9daee967610589d5866 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2249 Lines: 54 on 2017/6/30 6:05, Kees Cook wrote: > On Wed, Jun 28, 2017 at 9:13 PM, Li Kun wrote: >> 在 2017/5/31 5:39, Kees Cook 写道: >>> +bool ex_handler_refcount(const struct exception_table_entry *fixup, >>> + struct pt_regs *regs, int trapnr) >>> +{ >>> + int reset; >>> + >>> + /* >>> + * If we crossed from INT_MAX to INT_MIN, the OF flag (result >>> + * wrapped around) and the SF flag (result is negative) will be >>> + * set. In this case, reset to INT_MAX in an attempt to leave the >>> + * refcount usable. Otherwise, we've landed here due to producing >>> + * a negative result from either decrementing zero or operating on >>> + * a negative value. In this case things are badly broken, so we >>> + * we saturate to INT_MIN / 2. >>> + */ >>> + if (regs->flags & (X86_EFLAGS_OF | X86_EFLAGS_SF)) >>> + reset = INT_MAX; >> Should it be like this to indicate that the refcount is wapped from >> INT_MAX to INT_MIN ? >> if (regs->flags & (X86_EFLAGS_OF | X86_EFLAGS_SF) >> == (X86_EFLAGS_OF | X86_EFLAGS_SF)) >> >> reset = INT_MAX; > Ah yes, thanks for the catch. Yeah, that test is expecting both > condition flags to be set. > > I'm still on the fence about the best way to deal with the bad states. > I've been pondering just strictly using a saturation value (INT_MIN / > 2), which should offer the same system state protection (except for > the inherent resource leak), but that means there isn't really a good > way to kill an offending process (since after saturation ALL processes > will look like violators). It can be argued that killing the process > doesn't actually provide any benefit since the system is still safe, > though. An immature idea,can we set the count to INT_MAX/2 when we detect and kill the offending process, and wait to see if there will be another offender touching the fence. Er,not very acurate,but better than killing all the processes doing refcount_add ,i think. >>> + else >>> + reset = INT_MIN / 2; >>> + *(int *)regs->cx = reset; > Thanks for looking at this! > > -Kees > -- Best Regards Li Kun