Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp650131imm; Fri, 5 Oct 2018 09:29:42 -0700 (PDT) X-Google-Smtp-Source: ACcGV61UBAKq9HUBoiO1ySLBOJ3zxwpBFnHF1j4EhcxC243xYQhw043FxXnUi/11Upr8sPnDkomP X-Received: by 2002:a65:6144:: with SMTP id o4-v6mr5496676pgv.387.1538756982111; Fri, 05 Oct 2018 09:29:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538756982; cv=none; d=google.com; s=arc-20160816; b=Atq9kBT5SF5UIV5SnJBE6sbp8892s6q8VDZLBNi+qGiuP+ZZ47Z+saKf7kSEKD22ez 9fr+KpTQz2jvS/ol7x4xfx6OWcLPkUySgFHxxi+B3N5p95A4WP35SZ3vGxQd1K7C4QKm SOYAucneBTnpVckInohOl7L2vtKskuHgYRNrGueKHfY3qJeZOGP+8BaDbyxQ5Ly0nXAM +g1h8BGmGOx0p7J7TpF07kJ8beaPrEWZozW5OR6hEXzJLu6yycB2dRkV8fMBaHkdduDQ n+deWfrnaStE4p0qlpM/0bRUyC4rgMClzw3tUaDuPq7XMBYUuKoZgM3AEETwMWx582rM zCzA== 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=ylALM1i0/5QJ4UtpmaS85u5cgqJgzR+0WMDfZjeoQak=; b=VmmmL4e8/VWneNt3L+sOJOrBOO9PbgBnCnApvIVyrTWIZhs+3SGIBqiB6gHK7vutdh LReFaq539JY+whOUK8hAoMTKnkzFMlYgYITGI30JrU690KGhjWzV1kMRTYZflgQy+7Kj cndQhLKJ/RFnWd3i2eP9ExUhrYU+k7PTJAUqpxny/6aPeH0rnpDUrK9dqm2A6H32zTcc 5Wpgzv/2dlgQUP01eztb3ycpjFwRCDBJT3SmZg8Gfg0aKusbfvxlOAXHWVQO3gRrxPum BDmZJ/keVJ7ZEM0jincCZQWlMs5Fs4Cq4gvwmu3hw0b+sviJv68OIajzmILb92C2wTLP LR7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=qgK7T18l; 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 b1-v6si8871908pfc.156.2018.10.05.09.29.26; Fri, 05 Oct 2018 09:29:42 -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=qgK7T18l; 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 S1729189AbeJEX1f (ORCPT + 99 others); Fri, 5 Oct 2018 19:27:35 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:40740 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728698AbeJEX1e (ORCPT ); Fri, 5 Oct 2018 19:27:34 -0400 Received: by mail-pl1-f196.google.com with SMTP id 1-v6so7081862plv.7 for ; Fri, 05 Oct 2018 09:28:08 -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=ylALM1i0/5QJ4UtpmaS85u5cgqJgzR+0WMDfZjeoQak=; b=qgK7T18lH+BiZJCwaW5fLt2Sax6iXXOZzvbpCqgMmmTfQkHmXPpT7PR1LPfrRugQUn OWu1GIfay8S5a/95gKD+KlVIwUuU7rgMymrU/QnyZXJnkQcs+JkV40aAiB7oGlCs8YvO d7eB606Z5KxFghHK1YzJfl7A3SKTkrMUkr4A4gX/xgki3YWNKVGBnRO47ApaZ2FkUEAr 1C/LboX2DwGAuowU+H9SlyMtXl+9SLGSH2OGAMD/W8tI4uWFn9GIWYEtTLzahI/cHEjb 24V0O2K4p8WV2dFPGopjZeg19DGHFzqAvicf1IbrrU2xgEzDy+2ACcqMvh8/eQG4JqI5 ghMQ== 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=ylALM1i0/5QJ4UtpmaS85u5cgqJgzR+0WMDfZjeoQak=; b=TZDxZuBUq0utEvpxBpdSkZJGoVvuOVS0p4Vm52j6xQo+opeWT2tVHvZG8MIMARue+w ZzLs2bUbjlfLjsNQrUUMH0vb5NvPl7w6LMYkISXsUYaf+bKxYO1v3eW0shLgftMYIXGa y0buPVHAKWdIEOhzDkbLV5u8MH6Ic6F/1l9w0mVIvLFg3lkSX6r3jcV5VOxxjOf6XRQt /1zJv9OiQXralmO3igjb8RK9jUHVcO4BJjyF3vr3d+m0B0lLTdf3E46Er2oIYXgE3xrB a3x0oVsOk4z/tmym4ELVmZ3NeBSWwaX6MOIIsgtobZRMPkVbG4IAxDqOh/wIaZeU71b4 O8fA== X-Gm-Message-State: ABuFfoh+6NRbJvyNSMOWRKqHFL+v8/v3XT3lpGEx6XlVRpnKW+RM/ZWh C+uZ/z2Z5CM3S8gPMUxSR1W8eg== X-Received: by 2002:a17:902:421:: with SMTP id 30-v6mr6187502ple.184.1538756887742; Fri, 05 Oct 2018 09:28:07 -0700 (PDT) Received: from ?IPv6:2600:1010:b02c:cbf4:5532:1d8f:efe5:8aa? ([2600:1010:b02c:cbf4:5532:1d8f:efe5:8aa]) by smtp.gmail.com with ESMTPSA id d24-v6sm8488462pgv.23.2018.10.05.09.28.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Oct 2018 09:28:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [RFC PATCH v4 3/9] x86/cet/ibt: Add IBT legacy code bitmap allocation function From: Andy Lutomirski X-Mailer: iPhone Mail (16A366) In-Reply-To: Date: Fri, 5 Oct 2018 09:28:05 -0700 Cc: Eugene Syromiatnikov , 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 , Cyrill Gorcunov , Dave Hansen , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue Content-Transfer-Encoding: quoted-printable Message-Id: <5BF3AE8F-CC2A-4160-9FF6-FEA171A76371@amacapital.net> References: <20180921150553.21016-1-yu-cheng.yu@intel.com> <20180921150553.21016-4-yu-cheng.yu@intel.com> <20181003195702.GF32759@asgard.redhat.com> To: Yu-cheng Yu Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Oct 5, 2018, at 9:13 AM, Yu-cheng Yu wrote: >=20 >> On Wed, 2018-10-03 at 21:57 +0200, Eugene Syromiatnikov wrote: >>> On Fri, Sep 21, 2018 at 08:05:47AM -0700, Yu-cheng Yu wrote: >>> Indirect branch tracking provides an optional legacy code bitmap >>> that indicates locations of non-IBT compatible code. When set, >>> each bit in the bitmap represents a page in the linear address is >>> legacy code. >>>=20 >>> We allocate the bitmap only when the application requests it. >>> Most applications do not need the bitmap. >>>=20 >>> Signed-off-by: Yu-cheng Yu >>> --- >>> arch/x86/kernel/cet.c | 45 +++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 45 insertions(+) >>>=20 >>> diff --git a/arch/x86/kernel/cet.c b/arch/x86/kernel/cet.c >>> index 6adfe795d692..a65d9745af08 100644 >>> --- a/arch/x86/kernel/cet.c >>> +++ b/arch/x86/kernel/cet.c >>> @@ -314,3 +314,48 @@ void cet_disable_ibt(void) >>> wrmsrl(MSR_IA32_U_CET, r); >>> current->thread.cet.ibt_enabled =3D 0; >>> } >>> + >>> +int cet_setup_ibt_bitmap(void) >>> +{ >>> + u64 r; >>> + unsigned long bitmap; >>> + unsigned long size; >>> + >>> + if (!cpu_feature_enabled(X86_FEATURE_IBT)) >>> + return -EOPNOTSUPP; >>> + >>> + if (!current->thread.cet.ibt_bitmap_addr) { >>> + /* >>> + * Calculate size and put in thread header. >>> + * may_expand_vm() needs this information. >>> + */ >>> + size =3D TASK_SIZE / PAGE_SIZE / BITS_PER_BYTE; >>=20 >> TASK_SIZE_MAX is likely needed here, as an application can easily switch >> between long an 32-bit protected mode. And then the case of a CPU that >> doesn't support 5LPT. >=20 > If we had calculated bitmap size from TASK_SIZE_MAX, all 32-bit apps would= have > failed the allocation for bitmap size > TASK_SIZE. Please see values belo= w, > which is printed from the current code. >=20 > Yu-cheng >=20 >=20 > x64: > TASK_SIZE_MAX =3D 0000 7fff ffff f000 > TASK_SIZE =3D 0000 7fff ffff f000 > bitmap size =3D 0000 0000 ffff ffff >=20 > x32: > TASK_SIZE_MAX =3D 0000 7fff ffff f000 > TASK_SIZE =3D 0000 0000 ffff e000 > bitmap size =3D 0000 0000 0001 ffff >=20 I haven=E2=80=99t followed all the details here, but I have a general policy= of objecting to any new use of TASK_SIZE. If you really really need to depe= nd on 32-bitness in new code, please figure out what exactly you mean by =E2= =80=9C32-bit=E2=80=9D and use an explicit check. Some day I would love to delete TASK_SIZE.=