From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MIME_QP_LONG_LINE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8865C43218 for ; Tue, 11 Jun 2019 00:02:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B20D52086A for ; Tue, 11 Jun 2019 00:02:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="KUSlqCLf" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390831AbfFKACN (ORCPT ); Mon, 10 Jun 2019 20:02:13 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:37989 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390788AbfFKACN (ORCPT ); Mon, 10 Jun 2019 20:02:13 -0400 Received: by mail-pl1-f194.google.com with SMTP id f97so4280201plb.5 for ; Mon, 10 Jun 2019 17:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=A82/ddxx3F+ATI2rZx3wBjeD0ledFHTBqnLAZuECLx4=; b=KUSlqCLfKiAiQnRELAl1ZV0yc0U5pUCd2gUMULJ3+ELMQm4Hla5QTfxrOBk5YUAEyu zW+4qpHpO2pgrjwgBMY+GyzEKHtIpxIVIplITWILvwph3AhY3ZYZWBenMnOPLdgHgItc NASjKKHiq2Hn0b+lJstWbgAFaxZx+Q19bWrYD0MV/lo569q87MTUIUBTXXTdPUk5YO6X xX1aqotPQG/nM1VygMeR6ruhR81K6olk429urDbudQJ8MQFwV4AvFmmENPQSNEANXtPI rjLcJiMHLk1wWtRIhQGnKvHy69UpH1crAMAFqgxmbLBgi7aTQybSq/PyiQyATqDXbiNT 5WVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=A82/ddxx3F+ATI2rZx3wBjeD0ledFHTBqnLAZuECLx4=; b=hDnm8CJkJkUZpHryT0EChTXfQadyA/18iZG5GKy0bwN7ZdfrFbvKrnb+I5twq85znG Yvo6zAVJbQM1LY+cBfvWCHUFGHQDJ9zlrko6lVIlHQnX/fZd9Bi7bOozWt/cQ1jtZaPA uHt3qCl64j1pwm/VQDP1fHx/ZgTbCmpBtv50QLJ7xlmtM17E7LxmaKqFYG3o9siMv8ze nK0Fs17LheuEEBhilBv1D9dD6wgCxSaAUGGpxX+WKDJi+3xhTpm4tnb9SwkxUWyhYR// gsZDAx13lA8A8jDxN9uL53mdQfAzascM+xITFuIlryDjbiWO3EEIWufgx3OKpd5yTX98 Fzpw== X-Gm-Message-State: APjAAAXf0AVFsBLW5Vqo+v8JI0YB8uq7RGt7qeM/Q1ORSUtov4zhpJh3 YTr1uxV/+SjfHNNaQkrjObbW1A== X-Google-Smtp-Source: APXvYqwMeZAM5HN0tbtrDv+73zByg9xRCVQtCgh3nPGiZ8vukjVY4hHdmPlqsE6Qi2SoTZcEbcYFYw== X-Received: by 2002:a17:902:4181:: with SMTP id f1mr70400039pld.22.1560211332156; Mon, 10 Jun 2019 17:02:12 -0700 (PDT) Received: from ?IPv6:2600:1010:b04b:ab5e:d9b1:bcf9:898:128e? ([2600:1010:b04b:ab5e:d9b1:bcf9:898:128e]) by smtp.gmail.com with ESMTPSA id a18sm579563pjq.0.2019.06.10.17.02.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jun 2019 17:02:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function Date: Mon, 10 Jun 2019 16:54:52 -0700 Message-Id: References: <20190606200926.4029-1-yu-cheng.yu@intel.com> <20190606200926.4029-4-yu-cheng.yu@intel.com> <20190607080832.GT3419@hirez.programming.kicks-ass.net> <20190607174336.GM3436@hirez.programming.kicks-ass.net> <34E0D316-552A-401C-ABAA-5584B5BC98C5@amacapital.net> <7e0b97bf1fbe6ff20653a8e4e147c6285cc5552d.camel@intel.com> <25281DB3-FCE4-40C2-BADB-B3B05C5F8DD3@amacapital.net> <3f19582d-78b1-5849-ffd0-53e8ca747c0d@intel.com> <5aa98999b1343f34828414b74261201886ec4591.camel@intel.com> <0665416d-9999-b394-df17-f2a5e1408130@intel.com> <5c8727dde9653402eea97bfdd030c479d1e8dd99.camel@intel.com> <328275c9b43c06809c9937c83d25126a6e3efcbd.camel@intel.com> <92e56b28-0cd4-e3f4-867b-639d9b98b86c@intel.com> <1b961c71d30e31ecb22da2c5401b1a81cb802d86.camel@intel.com> Cc: Yu-cheng Yu , 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 In-Reply-To: To: Dave Hansen X-Mailer: iPhone Mail (16F203) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jun 10, 2019, at 3:59 PM, Dave Hansen wrote: >=20 >> On 6/10/19 3:40 PM, Yu-cheng Yu wrote: >> Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and >> VM_DONTDUMP. The bitmap will cover only 48-bit address space. >=20 > Could you make sure to discuss the downsides of only doing a 48-bit > address space? >=20 > What are the reasons behind and implications of VM_DONTDUMP? >=20 >> We then create PR_MARK_CODE_AS_LEGACY. The kernel will set the bitmap, b= ut it >> is going to be slow. >=20 > Slow compared to what? We're effectively adding one (quick) system call > to a path that, today, has at *least* half a dozen syscalls and probably > a bunch of page faults. Heck, we can probably avoid the actual page > fault to populate the bitmap if we're careful. That alone would put a > syscall on equal footing with any other approach. If the bit setting > crossed a page boundary it would probably win. >=20 >> Perhaps we still let the app fill the bitmap? >=20 > I think I'd want to see some performance data on it first. Trying to summarize: If we manage the whole thing in user space, we are basically committing to o= nly covering 48 bits =E2=80=94 otherwise the whole model falls apart in quit= e a few ways. We gain some simplicity in the kernel. If we do it in the kernel, we still have to decide how much address space to= cover. We get to play games like allocating the bitmap above 2^48, but then= we might have CRIU issues if we migrate to a system with fewer BA bits. I doubt that the performance matters much one way or another. I just don=E2=80= =99t expect any of this to be a bottleneck. Another benefit of kernel management: we could plausibly auto-clear the bits= corresponding to munmapped regions. Is this worth it? And a maybe-silly benefit: if we manage it in the kernel, we could optimize t= he inevitable case where the bitmap contains pages that are all ones :). If i= t=E2=80=99s in userspace, KSM could do the, but that will be inefficient at b= est.=