Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp1629414img; Wed, 27 Feb 2019 02:44:57 -0800 (PST) X-Google-Smtp-Source: AHgI3IYRzMAM7P/OORCX5vBjJ7tWKhRbbLHHuTQxDgp9Gf3GFqzCko6f0tlqN4aqn57fBIitYvJ/ X-Received: by 2002:a63:2c8a:: with SMTP id s132mr2340964pgs.440.1551264297438; Wed, 27 Feb 2019 02:44:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551264297; cv=none; d=google.com; s=arc-20160816; b=0MO15tRDaZYftMzSnhF2DShK15J/SoNQQQad/mVHcW16Q1uxBhfmIzUIb8Ob35fUwC gnsICoabsg0OBnHeoPmJZYjaNic67CpFw9+8FFEKLwmNGQA9fa0zLJi9gEh1nunewul+ 29T5sIHJqwIrEOBMveJPQRCGzHoGP59wLd2lvZEfWSfWrhDq3hzLpaZQZW6bOtSVQIZ8 6PQdXohmroMvUL7gq0scXK+Su9Rmsj7Wj4a83UKVmc6w2HpXAJuZ95sMBjuATSzNCdFA k+GiASdxTReWrx+GapPMv6n7HqiRDpqnIIEDW9MQpe9fDj0Ii6qcWGfj7WIZm//WUfZP Iorg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=qfamyxDnlRBcG3A3wkH+8rA8D5Yb9qMCXNGUxS3wiwA=; b=KYS4DXTLwFfAgQI6MxD/IdibBA3anjpQv2RWE6qo2mANHMpRXaxSPGzpGt4lZDaVAJ kJTAgZ3sjegNbdPzK6gmTc4haKssXzREMzudSud5K3ZKhbofP7gnY9z5XzaBMgeXi8Ws jm2uxX6JQilyhToHBZcmIWxNM3aZR0ijFHcnuVe80+rkOGb+vBRNhd9r75mM13QBVyFc VqlqR4r3L1hlvHl9Q0vC5Li4zdtwhjxzNkcLJf7x8z2wUDUnBMFLdsg6o3CiP79cPcN8 zzQccb6BeKUJgN7aAaycAA4PbRt4weiG8lUQVpeFQyftDnA0HjKTDXd0SmhXlCSH7uyW l4OQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e9si14363348pgg.199.2019.02.27.02.44.42; Wed, 27 Feb 2019 02:44:57 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728939AbfB0KoP (ORCPT + 99 others); Wed, 27 Feb 2019 05:44:15 -0500 Received: from mother.openwall.net ([195.42.179.200]:39049 "HELO mother.openwall.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1725881AbfB0KoP (ORCPT ); Wed, 27 Feb 2019 05:44:15 -0500 Received: (qmail 16154 invoked from network); 27 Feb 2019 10:44:13 -0000 Received: from localhost (HELO pvt.openwall.com) (127.0.0.1) by localhost with SMTP; 27 Feb 2019 10:44:13 -0000 Received: by pvt.openwall.com (Postfix, from userid 503) id EA567AA7D0; Wed, 27 Feb 2019 11:44:07 +0100 (CET) Date: Wed, 27 Feb 2019 11:44:07 +0100 From: Solar Designer To: Kees Cook Cc: Thomas Gleixner , Peter Zijlstra , Jann Horn , Sean Christopherson , Dominik Brodowski , Kernel Hardening , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] x86/asm: Pin sensitive CR0 bits Message-ID: <20190227104407.GA18804@openwall.com> References: <20190226233647.28547-1-keescook@chromium.org> <20190226233647.28547-2-keescook@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190226233647.28547-2-keescook@chromium.org> User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 26, 2019 at 03:36:45PM -0800, Kees Cook wrote: > static inline void native_write_cr0(unsigned long val) > { > - asm volatile("mov %0,%%cr0": : "r" (val), "m" (__force_order)); > + bool warn = false; > + > +again: > + val |= X86_CR0_WP; > + /* > + * In order to have the compiler not optimize away the check > + * in the WARN_ONCE(), mark "val" as being also an output ("+r") This comment is now slightly out of date: the check is no longer "in the WARN_ONCE()". Ditto about the comment for CR4. > + * by this asm() block so it will perform an explicit check, as > + * if it were "volatile". > + */ > + asm volatile("mov %0,%%cr0": "+r" (val) : "m" (__force_order) : ); > + /* > + * If the MOV above was used directly as a ROP gadget we can > + * notice the lack of pinned bits in "val" and start the function > + * from the beginning to gain the WP bit for sure. And do it > + * without first taking the exception for a WARN(). > + */ > + if ((val & X86_CR0_WP) != X86_CR0_WP) { > + warn = true; > + goto again; > + } > + WARN_ONCE(warn, "Attempt to unpin X86_CR0_WP, cr0 bypass attack?!\n"); > } Alexander