From patchwork Sat Jan 20 06:58:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dan Williams X-Patchwork-Id: 10176307 X-Patchwork-Delegate: kvalo@adurom.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5657460386 for ; Sat, 20 Jan 2018 06:59:01 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 46E1628801 for ; Sat, 20 Jan 2018 06:59:01 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3A0002880F; Sat, 20 Jan 2018 06:59:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BD7AA28801 for ; Sat, 20 Jan 2018 06:59:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754066AbeATG6s (ORCPT ); Sat, 20 Jan 2018 01:58:48 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:35715 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751064AbeATG6p (ORCPT ); Sat, 20 Jan 2018 01:58:45 -0500 Received: by mail-oi0-f66.google.com with SMTP id b11so2685435oif.2 for ; Fri, 19 Jan 2018 22:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5duuZthlYGtXdNk0ZxfpuxdlQ4qplnUXYm42b0sAres=; b=03zLxkwoVJUuZGcxHrAbNztNO2YVYAP1Th7jLQnMgpgNsGCF+iNMF8Do37pDBJun1o y4cdm+E6DbmjYegf5jwGxX7jyF6E7EItdM91TC0oS7JNC1wsDmlr9vTdiDavoHmOrGol tf9nwfwHLvsDcYaDVsvn3mJlg4SWL9MJWAOKu+4XVCvWeLrSv3a15D0jZ5ztan3vfv1O EZwMQ7Ktx+To6cpQS+b28ubVtxWaeMfdiExJnswhDlixIdSmhCDCsaE1WvFNQOKl/vvx hyO8N7WxHy7zoOvj1b5JUMwptJdh81Jqu0BIGEbelYhppIYZ/2b7LPjNndQhUK/BOslw GwSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5duuZthlYGtXdNk0ZxfpuxdlQ4qplnUXYm42b0sAres=; b=Ho1RAW7N/pe3n8WSHsUgFsDp2vul8tp+PcdwkGpLqlOJjBtMRr2vSb+vhJcYBoJFG9 1eHpb8B4GV1/a9oIQOodezpayo92e9cZ++SOCpkZmNoo38ry6jeJCpUkV01hCgC5uogg 1o/lfvns5DC7tkcFKMlUhz1uBgaNsBo7UrEhEjAyxB9jCnD2Sfwskq/mpkf3SXsUwWhN e7XChruCMtzHs8uC57+xWPqpXXwthaxXvVSM1tTrd+IKClxtR6/NV1KlCVwC3/sBQMeh raFQkcnUzVC6mPJ/wNjnfQZB0sbUaUxbmbHnqjTgJQ/mVq8dAMX3WCKyI0/BW+q9JAoy OrQg== X-Gm-Message-State: AKwxytfidRzKGPPYLt+VtLZEjdeOCsKjDtZdY+diuVbg5Zt/E5uxJlZk SqtSwGKLoZwIJVwmH+dsbhnh+s9y7Vq48i9xTsmlmA== X-Google-Smtp-Source: AH8x22608pxYGTTh17Dxk0SQT7rmoYvFw9scHB2B4W0hVflZQZAwpm8E+aHCHtHt64XnniPRsM/GIlm5qiIuSZwCVms= X-Received: by 10.202.171.14 with SMTP id u14mr475117oie.187.1516431524595; Fri, 19 Jan 2018 22:58:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.62.72 with HTTP; Fri, 19 Jan 2018 22:58:44 -0800 (PST) In-Reply-To: <151632009605.21271.11304291057104672116.stgit@dwillia2-desk3.amr.corp.intel.com> References: <151632009605.21271.11304291057104672116.stgit@dwillia2-desk3.amr.corp.intel.com> From: Dan Williams Date: Fri, 19 Jan 2018 22:58:44 -0800 Message-ID: Subject: Re: [PATCH v4 00/10] prevent bounds-check bypass via speculative execution To: Linux Kernel Mailing List Cc: Mark Rutland , Kernel Hardening , Peter Zijlstra , Catalin Marinas , Will Deacon , "H. Peter Anvin" , Elena Reshetova , linux-arch , Andi Kleen , Jonathan Corbet , X86 ML , Russell King , Ingo Molnar , Andrew Honig , Alan Cox , Tom Lendacky , Kees Cook , Al Viro , Andy Lutomirski , Thomas Gleixner , Andrew Morton , Jim Mattson , Christian Lamparter , Greg KH , Linux Wireless List , stable@vger.kernel.org, Paolo Bonzini , Johannes Berg , Linus Torvalds , "David S. Miller" Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Jan 18, 2018 at 4:01 PM, Dan Williams wrote: > Changes since v3 [1] > * Drop 'ifence_array_ptr' and associated compile-time + run-time > switching and just use the masking approach all the time. > > * Convert 'get_user' to use pointer sanitization via masking rather than > lfence. '__get_user' and associated paths still rely on > lfence. (Linus) > > "Basically, the rule is trivial: find all 'stac' users, and use > address masking if those users already integrate the limit > check, and lfence they don't." > > * At syscall entry sanitize the syscall number under speculation > to remove a user controlled pointer de-reference in kernel > space. (Linus) > > * Fix a raw lfence in the kvm code (added for v4.15-rc8) to use > 'array_ptr'. > > * Propose 'array_idx' as a way to sanitize user input that is > later used as an array index, but where the validation is > happening in a different code block than the array reference. > (Christian). > > * Fix grammar in speculation.txt (Kees) > > --- > > Quoting Mark's original RFC: > > "Recently, Google Project Zero discovered several classes of attack > against speculative execution. One of these, known as variant-1, allows > explicit bounds checks to be bypassed under speculation, providing an > arbitrary read gadget. Further details can be found on the GPZ blog [2] > and the Documentation patch in this series." > > A precondition of using this attack on the kernel is to get a user > controlled pointer de-referenced (under speculation) in privileged code. > The primary source of user controlled pointers in the kernel is the > arguments passed to 'get_user' and '__get_user'. An example of other > user controlled pointers are user-controlled array / pointer offsets. > > Better tooling is needed to find more arrays / pointers with user > controlled indices / offsets that can be converted to use 'array_ptr' or > 'array_idx'. A few are included in this set, and these are not expected > to be complete. That said, the 'get_user' protections raise the bar on > finding a vulnerable gadget in the kernel. > > These patches are also available via the 'nospec-v4' git branch here: > > git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v4 I've pushed out a nospec-v4.1 with the below minor cleanup, a fixup of the changelog for "kvm, x86: fix spectre-v1 mitigation", and added Paolo's ack. git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v4.1 }) diff --git a/include/linux/nospec.h b/include/linux/nospec.h index 8af35be1869e..b8a9222e34d1 100644 --- a/include/linux/nospec.h +++ b/include/linux/nospec.h @@ -37,7 +37,7 @@ static inline unsigned long array_ptr_mask(unsigned long idx, unsigned long sz) unsigned long _i = (idx); \ unsigned long _mask = array_ptr_mask(_i, (sz)); \ \ - __u._ptr = _arr + (_i & _mask); \ + __u._ptr = _arr + _i; \ __u._bit &= _mask; \ __u._ptr; \