Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp386414ybi; Fri, 7 Jun 2019 09:38:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyuDoNxDRZSfFeMw6+qzFPsIqAdwKyv6FDNFZ3OYkhiyTCjouCnaOLdhLdvkSvZ/4TkuvI6 X-Received: by 2002:a17:902:824:: with SMTP id 33mr58346712plk.29.1559925503429; Fri, 07 Jun 2019 09:38:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559925503; cv=none; d=google.com; s=arc-20160816; b=pDg/zuP3l6QzYkeXMUTc+IgAfVcVMYQVSSFff/RTuN5srntrprX4DfGyh7GQveSTzv xhZt+N734Ic2tKK2vSwbTQciLLhJ7HVjaFucezo0reXPWbV/JhpR31dU34zeH1F9o53a ZlACpvr5V4OtjlfELKd+FRwNetQBZbuf150qe1P5TEB4i2/Qo3giH/gy2k++OrkiKImq O+Pnp5By+ea2c36kMsLRjwaR3D7pNdtQp3sJ77HZ4WYIRRYPMykn3N1zmVfFGlgi02Iv Odwea123iZScBvbboJc/fz+XYCKwVML+wGPaYOZPz5QXeKFDJ87zo37/3Ts5JEy7remn QquA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=0wvMqjnLfHeibHfnd5Vo60J3T+kOUBskArwKAN9PGMQ=; b=Fj2Lwj00aYGuSbRGoX4izXnlO0+l87LcmetkIdXN8iDRq1bE8hluOdB4Qb3sFaCuqC wqd9w/2At0taey/qy5FUlCC1RsWiP1bGNNBCSbO0T12ky5CwkprKM8qA51WhQS5VqOFK vkPAOADEYL97KycnWpzl4KtyMm9V0ft9bP7JqMOava4ch5U9DHMHcoFzkgG8f1hfgou9 W7WKJ86HQs3eMLaD6SIr57k9HCqzSvj+IkNBj4YYlU7Oy52KrzT8pbcj8ZD8c55CZXpD HQJa50Sk3YzY2Nhto5wiafn64pCk5K1pgMq6WfFcbA98+Sva5LMze5v+LwoPWgouPmzS XJ7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=Z1ujcUSO; 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 y6si2401966pgs.342.2019.06.07.09.38.06; Fri, 07 Jun 2019 09:38:23 -0700 (PDT) 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; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=Z1ujcUSO; 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 S1730832AbfFGQfb (ORCPT + 99 others); Fri, 7 Jun 2019 12:35:31 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:38393 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730733AbfFGQfa (ORCPT ); Fri, 7 Jun 2019 12:35:30 -0400 Received: by mail-pl1-f195.google.com with SMTP id f97so1033809plb.5 for ; Fri, 07 Jun 2019 09:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0wvMqjnLfHeibHfnd5Vo60J3T+kOUBskArwKAN9PGMQ=; b=Z1ujcUSObY84r0pQw1gBEgavn3UDkEJ73l7OoeuHJ7dTxxtAWA5cFzGd2tv+bDLXFZ ZUSH8lkopmuRZXxnqwLbFKFylazXfmK1Yd06ZaFH3sphoqD6YxdLCXKJjTeZ/46olgLw cLkrGYT/rNrgSGRUpMNUrvuX5u7UwSAvEWwn4hAgbhrWtbQEXPMkYf5cSf3rXHCCI2yO oxKvbLtHVB4ymsJqzauKbObHwXVJGq0nRHyzLloNX1EQW9P9evaYW8zYcNjTEP4aI/WM V69MI12MFr6S0MbwLenZ5QYptjGPavTIFQ1xi2XagjAAyleNVcloUFwKXdfWiK7WVJUO LbUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0wvMqjnLfHeibHfnd5Vo60J3T+kOUBskArwKAN9PGMQ=; b=Hxics4HlzniUbc9IFqAEguu/2ciYRR9SlA3YeOdwg7hXz/jfIoy5rNSCu7Fe1VTmzm lDlEztPqwxAIDKPHLD0tqTo5LyPyYBoTV1nLgBMjm3g4SSTW1qh7rHFcDVYBpm8ZdNmd P8oJB54PGS8PlLaMYcePXN1+Ygyv4bM9AQnEeSl/zmSygZRhSRtQW3oOy8COabJ3ib0e c3ptRtWmCVKrE9+CCpqDOOvowc5JRcJ044jiLuZfpkpU7muEb2x1j0lMlLoF0xNL3t/n SzU17jaSu/eZWAan8bcECehe+MulKycpKm0rt+ZRCzGlbqBwu7VOOxegpcbkyLSuDZWP iWNQ== X-Gm-Message-State: APjAAAU/cwBW0RE8PCzy8dgniFQpDr56s9QaaIoS9beV/dcWf7HA27TL DxZaA/tjeIG4W5McikzNn9/MVw== X-Received: by 2002:a17:902:7e0f:: with SMTP id b15mr48583188plm.237.1559925330160; Fri, 07 Jun 2019 09:35:30 -0700 (PDT) Received: from ?IPv6:2600:1012:b044:6f30:60ea:7662:8055:2cca? ([2600:1012:b044:6f30:60ea:7662:8055:2cca]) by smtp.gmail.com with ESMTPSA id f2sm2240019pgs.83.2019.06.07.09.35.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 09:35:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function From: Andy Lutomirski X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Fri, 7 Jun 2019 09:35:27 -0700 Cc: Peter Zijlstra , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin Content-Transfer-Encoding: quoted-printable Message-Id: <76B7B1AE-3AEA-4162-B539-990EF3CCE2C2@amacapital.net> References: <20190606200926.4029-1-yu-cheng.yu@intel.com> <20190606200926.4029-4-yu-cheng.yu@intel.com> <20190607080832.GT3419@hirez.programming.kicks-ass.net> To: Yu-cheng Yu Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jun 7, 2019, at 9:23 AM, Yu-cheng Yu wrote: >=20 >> On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote: >>> On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote: >>> Indirect Branch Tracking (IBT) provides an optional legacy code bitmap >>> that allows execution of legacy, non-IBT compatible library by an >>> IBT-enabled application. When set, each bit in the bitmap indicates >>> one page of legacy code. >>>=20 >>> The bitmap is allocated and setup from the application. >>> +int cet_setup_ibt_bitmap(unsigned long bitmap, unsigned long size) >>> +{ >>> + u64 r; >>> + >>> + if (!current->thread.cet.ibt_enabled) >>> + return -EINVAL; >>> + >>> + if (!PAGE_ALIGNED(bitmap) || (size > TASK_SIZE_MAX)) >>> + return -EINVAL; >>> + >>> + current->thread.cet.ibt_bitmap_addr =3D bitmap; >>> + current->thread.cet.ibt_bitmap_size =3D size; >>> + >>> + /* >>> + * Turn on IBT legacy bitmap. >>> + */ >>> + modify_fpu_regs_begin(); >>> + rdmsrl(MSR_IA32_U_CET, r); >>> + r |=3D (MSR_IA32_CET_LEG_IW_EN | bitmap); >>> + wrmsrl(MSR_IA32_U_CET, r); >>> + modify_fpu_regs_end(); >>> + >>> + return 0; >>> +} >>=20 >> So you just program a random user supplied address into the hardware. >> What happens if there's not actually anything at that address or the >> user munmap()s the data after doing this? >=20 > This function checks the bitmap's alignment and size, and anything else is= the > app's responsibility. What else do you think the kernel should check? >=20 One might reasonably wonder why this state is privileged in the first place a= nd, given that, why we=E2=80=99re allowing it to be written like this. Arguably we should have another prctl to lock these values (until exec) as a= gardening measure.=