Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp6133154imm; Mon, 23 Jul 2018 12:02:04 -0700 (PDT) X-Google-Smtp-Source: AAOMgpe6TkNTG1nTIeK2ed7BrUdTRwk3JKiuzkSHsbKsGFL0mHFVmx8D8lvT/tyIYzKhPr1ju+cW X-Received: by 2002:a17:902:e201:: with SMTP id ce1-v6mr13733156plb.136.1532372524658; Mon, 23 Jul 2018 12:02:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532372524; cv=none; d=google.com; s=arc-20160816; b=pHiKVE0JyREewSbAekZCL1kQtTmNJAvWhlbrdGOzqSSy5/gZSg9Egmii/jEicK7xSD 5KWfjYJ2whJKCYsPXP9P6qvonBGBlt5Jl3Oo9D1T9/seNpiXDXiaJaKg67ENv5BRmj2L t8eu7dx75nwZMkoGT/EL/xF8MWVfXgJZqFaejtRmoodedJcV+dPanlJA2XBVzkHY1m8c MRo5XVic2NVRO6qXZzR2u7n8+MIdv5sg9J+jWwx6zGaUd1ImBZs4bcCEKR1WtN21R9OR RemxYcqBTADYMWTvAiB6CIrvl6hpI3DBkzwmEzijZvssSu5VdkUP89oKnYmERwKe4TID IUaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=+nvVkN5YjzEa1ZDxcnuw/cmYC2X4Wn2J/3GX5j65O40=; b=svq0ET72PeXulzV6xZcxazqDDPW+NVSqcAIH/EOraNffBad4ZZQxJeknOTvxUjadcU ha9/Kao/sYU7CQyPCWBUpKhx9mYMOQsSQ+6X80IdzBkBe/Z/wpNdsK5ahdXH1OOmMu9a AhkQhViYJD5mJAZYcWZTA1BJcKw55kjiuz8rcVuiYEBzdxM1ZBkWkmyOpoU4CoNuHu6M sUbGqSfspPzBiOA04c/vRLaofaeS+OANrPQswxQYA5Ln+ubl1zaZKe1Czup/EkBNQ6cj 6pdLm9YHb+/kn+jOFnYBWuIzzMAPG+Grf/2T69mhRb3hYOwQ2irlnjlyOpFpslRmwAWI cUfg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=CCN4HIIy; 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 j4-v6si8349779pll.101.2018.07.23.12.01.49; Mon, 23 Jul 2018 12:02:04 -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=@linux-foundation.org header.s=google header.b=CCN4HIIy; 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 S2388131AbeGWUCz (ORCPT + 99 others); Mon, 23 Jul 2018 16:02:55 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:40370 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387970AbeGWUCz (ORCPT ); Mon, 23 Jul 2018 16:02:55 -0400 Received: by mail-it0-f68.google.com with SMTP id h23-v6so250572ita.5 for ; Mon, 23 Jul 2018 12:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+nvVkN5YjzEa1ZDxcnuw/cmYC2X4Wn2J/3GX5j65O40=; b=CCN4HIIyScSK2lVgwQ2qyO+jehyyq/OZb5lRXtJqKSd1YALm/Z4eexZqQOhrKT8g/C NjidzMi5+6RhuUOsS+VcOs70UykQfLKhnvfD1YcYF9C+bbQ5VmgDtS7P47C32gQoiLeD YpYUWtJliqq23Bck65aHcazkeIK0tm9rAeKIM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+nvVkN5YjzEa1ZDxcnuw/cmYC2X4Wn2J/3GX5j65O40=; b=N50N6eh3kQ7ErpY/lavxMTK0cKhtvKwyBfjm4qJgOjubcLYQo7CiBKnHR5g63Lm1Gf v3ul6WohaVe4gPDBFqCPI/kuub69GqR+zfXMwc3ik3mRryCtA0b5oqopgkZFSlE+fwkh 8vF8flm91K7OPXuob5c0x9Ny02MqI1WSH8dNJhPcUYAuhwgIiHMDJN+Bctk/1uYOX5i0 JGgaz9fwsn9DLpBaj8UoRQoor0txh4VU79nBS6f791OoQtXIBYtRgwxrxLk7+ueMZ7Q6 lo3yQDIWDLorUnfIuF9piU5gqxWGkDJV0qEWzkkxknaivjSDSF+S7eHjBJhJWZMVWLYK runw== X-Gm-Message-State: AOUpUlHkKjEUahsCPUv3AmaZBFxr2kDlaarW86W7wNqz/CBgiqla0NkK eAsFqzrffilFIIe68wox1yxUKL7QJ9LqDYUceWk= X-Received: by 2002:a02:2b12:: with SMTP id h18-v6mr12780530jaa.10.1532372419941; Mon, 23 Jul 2018 12:00:19 -0700 (PDT) MIME-Version: 1.0 References: <1532103744-31902-1-git-send-email-joro@8bytes.org> <20180723140925.GA4285@amd> In-Reply-To: <20180723140925.GA4285@amd> From: Linus Torvalds Date: Mon, 23 Jul 2018 12:00:08 -0700 Message-ID: Subject: Re: [PATCH 0/3] PTI for x86-32 Fixes and Updates To: Pavel Machek Cc: Joerg Roedel , Thomas Gleixner , Ingo Molnar , Peter Anvin , "the arch/x86 maintainers" , Linux Kernel Mailing List , linux-mm , Andrew Lutomirski , Dave Hansen , Josh Poimboeuf , =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg Kroah-Hartman , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Andrea Arcangeli , Waiman Long , "David H . Gutteridge" , Joerg Roedel , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 23, 2018 at 7:09 AM Pavel Machek wrote: > > Meanwhile... it looks like gcc is not slowed down significantly, but > other stuff sees 30% .. 40% slowdowns... which is rather > significant. That is more or less expected. Gcc spends about 90+% of its time in user space, and the system calls it *does* do tend to be "real work" (open/read/etc). And modern gcc's no longer have the pipe between cpp and cc1, so they don't have that issue either (which would have sjhown the PTI slowdown a lot more) Some other loads will do a lot more time traversing the user/kernel boundary, and in 32-bit mode you won't be able to take advantage of the address space ID's, so you really get the full effect. > Would it be possible to have per-process control of kpti? I have > some processes where trading of speed for security would make sense. That was pretty extensively discussed, and no sane model for it was ever agreed upon. Some people wanted it per-thread, others per-mm, and it wasn't clear how to set it either and how it should inherit across fork/exec, and what the namespace rules etc should be. You absolutely need to inherit it (so that you can say "I trust this session" or whatever), but at the same time you *don't* want to inherit if you have a server you trust that then spawns user processes (think "I want systemd to not have the overhead, but the user processes it spawns obviously do need protection"). It was just a morass. Nothing came out of it. I guess people can discuss it again, but it's not simple. Linus