Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp533468imm; Mon, 2 Jul 2018 16:40:54 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfQ/4p4yy3r5chVtcRfS57+835nuaJNy+yhWcwpbioTsyt8eHjZNFq607v/IHbLW3Hf/s9G X-Received: by 2002:a17:902:5501:: with SMTP id f1-v6mr740461pli.108.1530574854860; Mon, 02 Jul 2018 16:40:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530574854; cv=none; d=google.com; s=arc-20160816; b=YX3KQtj7HfN5CWa6q71SRML+vBbSiRKnqSWrtK4txzpbjQcczV+9YU7SUE78scxnRD suT4s5oHa4CHbaI7zr5JhzISg5iStFocfOYg7nEoMDR8j+z3Wili8o6GTfIzT7A8q7hR I2LEgTt3RpssLe8tWXv3PeGoXJ1ez8HOzyBDpS+86cBXqAnOV3M8NYD4u3NEM9EE1hPg v+uYlWzHVJunKV6FKRrJt2v9NIWVTDkl3H7u8wuG5q1YFUkymMbn1lBZse4tw9ZOEC4U 6JULL+1qxDzDome3l+uGiA9lA3F9l7Ao9SOlgc8oHNzkDUnyhxLYkU67W334N4UfJjZ/ jqzw== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=9K+icf9Tq+L6chtSmDn+WHr0nVbD9w3yEqnxZuuW1z8=; b=HFgFmpr/QMjz9RzixzexvE1JA/beNg9GjLgsNCtWn0RB+TNgQJg1xrUjAbg9NpsK8T A1GLTUy1YRphdgmeOoxllOMq+oCyB4CggTtoTKmsoOkBtmj6ZxUWm2LPRVcTW6Lr4D8n oVkp8KRdvlsrE/inY4qi2IIn5+MmbvImO9jYmmyTfQu+84hXYWnnaydtUdXTVCT5IFhL 1DD0U4O7+oifilgKAjDkUVxbj2QFL7pbHOksGKhiYAFoODq85TnwHFlgossjplTb/92K QDf01r+bnlxvfkX2ZN4TuURl541PlVAOOSfU6vQUhLPlMA7X9OsaIhhQsQZZbG4RmucB igYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=fbPWFguS; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d13-v6si16699803plr.196.2018.07.02.16.40.37; Mon, 02 Jul 2018 16:40:54 -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=@google.com header.s=20161025 header.b=fbPWFguS; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753680AbeGBXjz (ORCPT + 99 others); Mon, 2 Jul 2018 19:39:55 -0400 Received: from mail-ua0-f196.google.com ([209.85.217.196]:38652 "EHLO mail-ua0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753053AbeGBXjx (ORCPT ); Mon, 2 Jul 2018 19:39:53 -0400 Received: by mail-ua0-f196.google.com with SMTP id 59-v6so76698uas.5 for ; Mon, 02 Jul 2018 16:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9K+icf9Tq+L6chtSmDn+WHr0nVbD9w3yEqnxZuuW1z8=; b=fbPWFguSuI8+CQyYmKDPLIDBcZZdBRgHyfiLwFCxnOOEqxSpHUceGlGIefKWLLjM86 S4TYDGRwq+ko6WkLq4qA3Gvgn6lCJSclShwxMYJZnlUZAFx2IWUrHbT2Ie4qZdBxSfc2 HGVhvOAAQVYHWtFMe0q7Qsr1ZfDNY5MzSEZtFAE4V/WmNq519Pg1G2Mc46VcUCInD5vk nvRkZudXctIFtmMzTGxstxP+N9Nb31NF1b3FqpCDqDVY42te8AluRUvXMG5aHwfxrEpX w8TqX3Fk54zTDWgbgQJAy+A3OXUBbLtS6l7S4DUZuby9PqMkdB+iS7jr+KccY20PMwGM 3xmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9K+icf9Tq+L6chtSmDn+WHr0nVbD9w3yEqnxZuuW1z8=; b=gR00rCatnhrv8RynjgBS32nSBxvWBL8GlZBbEdJ0FOVBjDzXKmr/ywadtEGWmL+nhA gR+pVyLCDs268bjm9PTgXqV9wruSpB0OQBpNGQUpP5CdoVdgPHx5yj0xdL4qi5Ksv+J7 ipJeXoZe8qGlOIftCzRlskYEOn4Mdon3J+MvRtkxzcJsEV4VEGkHjVK957pw17B1SK1N mEszROnqrPIc4oMozJ8U81/o64GFfBltiuuL4ehIh7YberqriGCj0DuSpkHiudQE8ZOY wXCzrr6mcqhQ0UWW51Y8vcvhhqaXvXqW7bqddd+DXYUjXUl6C9qlNxsDjqP9O7dP5tQv vg+A== X-Gm-Message-State: APt69E1auRvPAeved9u/LRtQJNHFdn5lYVIHIH9BUb+grwvo3V5hYZKQ 0z7+Qc7uYlOa6HntYqmMZqrLmsiDGYGVu2BaGkL1nw== X-Received: by 2002:ab0:5013:: with SMTP id b19-v6mr17286927uaa.92.1530574792246; Mon, 02 Jul 2018 16:39:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:9d83:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 16:39:51 -0700 (PDT) In-Reply-To: <20180702203321.GA8371@bombadil.infradead.org> References: <20180627160800.3dc7f9ee41c0badbf7342520@linux-foundation.org> <20180702203321.GA8371@bombadil.infradead.org> From: Evgenii Stepanov Date: Mon, 2 Jul 2018 16:39:51 -0700 Message-ID: Subject: Re: [PATCH v4 00/17] khwasan: kernel hardware assisted address sanitizer To: Matthew Wilcox Cc: Kostya Serebryany , Andrew Morton , Andrey Konovalov , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Catalin Marinas , Will Deacon , Christoph Lameter , Mark Rutland , Nick Desaulniers , Marc Zyngier , Dave Martin , Ard Biesheuvel , "Eric W . Biederman" , Ingo Molnar , Paul Lawrence , Geert Uytterhoeven , Arnd Bergmann , "Kirill A . Shutemov" , Greg KH , Kate Stewart , Mike Rapoport , kasan-dev , linux-doc@vger.kernel.org, LKML , Linux ARM , linux-sparse@vger.kernel.org, Linux Memory Management List , Linux Kbuild mailing list , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Jann Horn , Mark Brand , Chintan Pandya , Vishwath Mohan 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 2, 2018 at 1:33 PM, Matthew Wilcox wrote: > On Wed, Jun 27, 2018 at 05:04:28PM -0700, Kostya Serebryany wrote: >> The problem is more significant on mobile devices than on desktop/server. >> I'd love to have [K]HWASAN on x86_64 as well, but it's less trivial since x86_64 >> doesn't have an analog of aarch64's top-byte-ignore hardware feature. > > Well, can we emulate it in software? > > We've got 48 bits of virtual address space on x86. If we need all 8 > bits, then that takes us down to 40 bits (39 bits for user and 39 bits > for kernel). My laptop only has 34 bits of physical memory, so could > we come up with a memory layout which works for me? Yes, probably. We've tried this in userspace by mapping a file multiple times, but that's very slow, likely because of the extra TLB pressure. It should be possible to achieve better performance in the kernel with some page table tricks (i.e. if we take top 8 bits out of 48, then there would be only two second-level tables, and the top-level table will look like [p1, p2, p1, p2, ...]). I'm not 100% sure if that would work. I don't think this should be part of this patchset, but it's good to keep this in mind.