Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752989AbeAFSKl (ORCPT + 1 other); Sat, 6 Jan 2018 13:10:41 -0500 Received: from mail-ot0-f196.google.com ([74.125.82.196]:43662 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752821AbeAFSKj (ORCPT ); Sat, 6 Jan 2018 13:10:39 -0500 X-Google-Smtp-Source: ACJfBouw3Xypu6xGZsS73nWOmJoAgeaEaasHeqDP+Em187TdtdYQszKTwvVtSsHNEMjD7Iymr3fgdS5RNIeTZ7TLQws= MIME-Version: 1.0 In-Reply-To: References: <151520099201.32271.4677179499894422956.stgit@dwillia2-desk3.amr.corp.intel.com> <151520107001.32271.12149241186695668220.stgit@dwillia2-desk3.amr.corp.intel.com> <20180106090154.GE4380@kroah.com> <20180106122347.7a5c8ee6@alans-desktop> <20180106151424.GA17924@kroah.com> From: Dan Williams Date: Sat, 6 Jan 2018 10:10:38 -0800 Message-ID: Subject: Re: [PATCH 14/18] ipv4: prevent bounds-check bypass via speculative execution To: Greg KH Cc: Alan Cox , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Hideaki YOSHIFUJI , Netdev , Peter Zijlstra , Alexey Kuznetsov , Thomas Gleixner , Linus Torvalds , "David S. Miller" , Elena Reshetova , Alan Cox Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Sat, Jan 6, 2018 at 8:29 AM, Dan Williams wrote: > On Sat, Jan 6, 2018 at 7:14 AM, Greg KH wrote: >> On Sat, Jan 06, 2018 at 12:23:47PM +0000, Alan Cox wrote: >>> On Sat, 6 Jan 2018 10:01:54 +0100 >>> Greg KH wrote: >>> >>> > On Fri, Jan 05, 2018 at 05:11:10PM -0800, Dan Williams wrote: >>> > > Static analysis reports that 'offset' may be a user controlled value >>> > >>> > Can I see the rule that determined that? It does not feel like that is >>> > correct, given the 3+ levels deep that this function gets this value >>> > from... >>> >>> On a current x86 you can execute something upwards of 150 instructions in >>> a speculation window. >> >> Yeah, I agree, it's deep :( >> >> But for this patch, I thought the prior review determined that it was >> not a problem. Was that somehow proven incorrect? > > I kept it in the series to get a re-review with the wider netdev > because I missed the discussion leading up to that 'drop the patch' > decision. Sorry, I should have noted that in the changelog or cover > letter. Is there a microbenchmark that can stress this path. If the cost is negligible why play games with it being "probably ok"? Unless someone can say 100% 'offset' is always bounded to something safe by the time we get here just use nospec_array_ptr().