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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81D40C54E5D for ; Tue, 12 Mar 2024 16:45:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FD808D0063; Tue, 12 Mar 2024 12:45:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 188A68D0017; Tue, 12 Mar 2024 12:45:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04ED08D0063; Tue, 12 Mar 2024 12:45:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E54578D0017 for ; Tue, 12 Mar 2024 12:45:28 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C0F4A40103 for ; Tue, 12 Mar 2024 16:45:28 +0000 (UTC) X-FDA: 81888962736.28.98B7EA9 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf23.hostedemail.com (Postfix) with ESMTP id 9FCCD140012 for ; Tue, 12 Mar 2024 16:45:25 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QFFRwmC9; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710261925; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=T5VYE66SG2vVNABTej4G7/BF3k9RLjCxZBom9PnuvAY=; b=VUcYXjvHZbePWJowAoT5JbHRCZtB1b3CHGv2U4rBCtGWrrheBj8KlHlRqDMAibSqNKcJcM y1IdZA0foxzIDhyUpaxg3WzuUDb0VaeyPyzLNBj74rX/np8KsT+jMxaV3mQkzD9yKpgvUV k4ofDJfhbzha3jST0llR7IGZxx2w120= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=QFFRwmC9; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710261925; a=rsa-sha256; cv=none; b=vO+dFZaZbN5dw2WkYiuQIwH2yQXtoRoKYK8KBfKDbqFX7eAYyt6gIPDJEWy2LK+R0ZPjTb IdZt7EUyaqdAVe7Otj++gAvMLIGzfGTQ3Ub3mIHhb8+TtIN5deee6hdTVQZ0EAs63nWJVh VtzDEsfAnx5dB7zcoNYBvmDSnVKJ2dg= Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-42ef8193ae6so320261cf.1 for ; Tue, 12 Mar 2024 09:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710261924; x=1710866724; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=T5VYE66SG2vVNABTej4G7/BF3k9RLjCxZBom9PnuvAY=; b=QFFRwmC93SxoSDfJ6GzUXQtF/VNF70LcYtGaK3SXnD/Ps+OPIHgq91/QYORGJruz6W BLmQ7+4UcSaDgEPhMMtYw5qPOWNyy4vovPFdLdR5FsB/SKg09s1HpttMDi21i6ZLZk8H 3AN0+k5rcLwhfgCpeylcetiLVZ9o4LpsrYCxIdezYzQB8Zvc1lzl6Yvm6GljmHJEHH2S xjgNNxtPyJ66QIdd9TJZYOex7T0IzOv/0EYeHGMokIrG+Kkcjf+OXabCAPzqvHfMWhIG ULbJE4/wdJX5efp6kmgwIYcmL8RYTGz913PcxOc43ZlPeQj9S7r+iiC7Mm3jucS47hqz KizQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710261924; x=1710866724; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=T5VYE66SG2vVNABTej4G7/BF3k9RLjCxZBom9PnuvAY=; b=u5y2/tBjRfu5JUFWSIZv9oiah9mhD3e91tCfziTvF+6tkMu3T0dLwO1QaHa6zGGXjq CbJEOpFixjFhPzI9ysj/fDKNr/lcwrKd7SksIMjExpQlB1nPYehm8QhnO2BLHkVeugQ4 7E3xLfByfFjNTcCdK+r6BNcesi7iKmntp0qh6Acl5NMcLDjPpFpnUfboB0qipgrD6Iwd Bg5CUNeZjwDqGtEwJXd+L9ZlXNFJ38ccbEuKiiOGjTkt7LBvkQITOYnD8bzBR+/XIX/G nrCSmpNE5I+sLg6dam65sR1/fH+/9ucON4+PH0sWH4qeJaCFsfZsS4mWo0rXOGuc7P24 tnqw== X-Forwarded-Encrypted: i=1; AJvYcCX5Mk10D+6HFtiI8/HcFl9Gr0zF7rHB47wlD1EC2dWb7pRaWcGqb4OLpviJ1xBMq2Ve0Zfd4nBdSfL+udkpa0svOoI= X-Gm-Message-State: AOJu0YzU/yW+11clhZlTz9eE550TzAfaoJ6pN3Pu7VbBTK/8v2YpVJ+K w3xd/t0lU9LqsZkG0TKQnm+vDTqVHdNguxWY+3TjRFtiKCQ4kJnZbf3QYW3YgpURfpfmxlH57PA 27+tE298vONUqpKJu0cyPGMsr4LvQqyx/6Vv9 X-Google-Smtp-Source: AGHT+IEOR4UhpkNFAhWeGvOYHLoPWmcAD8LaPzKllPY5g5qw5dN2JFYaR7wrhs5yubrdbFHq++GHlNrw7PZ0W5GieTk= X-Received: by 2002:a05:622a:2a9a:b0:42f:3075:18e with SMTP id kf26-20020a05622a2a9a00b0042f3075018emr240180qtb.5.1710261924485; Tue, 12 Mar 2024 09:45:24 -0700 (PDT) MIME-Version: 1.0 References: <20240312154828.0efc76a4@meshulam.tesarici.cz> In-Reply-To: <20240312154828.0efc76a4@meshulam.tesarici.cz> From: Brendan Jackman Date: Tue, 12 Mar 2024 17:45:11 +0100 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Address Space Isolation To: =?UTF-8?B?UGV0ciBUZXNhxZnDrWs=?= Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, x86@kernel.org, Junaid Shahid , Reiji Watanabe , Patrick Bellasi , Yosry Ahmed , Frank van der Linden , pbonzini@redhat.com, Jim Mattson , Paul Turner , Ofir Weisse , alexandre.chartre@oracle.com, rppt@linux.ibm.com, dave.hansen@linux.intel.com, Peter Zijlstra , Thomas Gleixner , luto@kernel.org, Andrew.Cooper3@citrix.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9FCCD140012 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: mspcygtqqs85fjddg8k6tmzhkdb66gr8 X-HE-Tag: 1710261925-604903 X-HE-Meta: U2FsdGVkX19kwkDu1804k3C/AqDXHBRCcN9aWAoXpTxndtmNMZMvw9IaBVilEEaLT3oYSv7+a028N4dRiOF75O9X0heHVkEvPcy0EdC9gcwhS5TA++JhGo9k0Cl5CtcVplJY0o0jPmtcK5da85aLZVDjc1OZqUm/fg6Ub8qCp+D2kdsv0dFr2NP9QcbNsEZLkrZweMGB6e3CeJlYT44TESqBe25f1sHxMk+ZIj2mNP1Ai2dG7lespbrpKZogYPoFXH3NlOqxulSTn425wwbki1m6Tuyt7sDSRsby8oIy1dQpiiabEHiQQbkJHb2s3iHBHQT0YLC8uSIVJTbP4NzGr6jYgBmq7go/DBgDyHJ9djyRYUW4Oo7wkFUExZbW0husQ9F1uSFQX0qTFjWy93nar7Vn/z7VLEQDkt23tq3xtyPMRD2YeJQ1NLxX0diqJm1bPM0Fwda8tzQ6+3ZjSODMlbowhOLMsGBzzKong4wNpmFKiMRWPB872s8CJCWfIm4x1V05zs7CRdRtwSloCwM/ztOaWfftb4pZuxhdvHqN9uHzi3v/O5FefHjbkmN8N86Gv7BeN2f2HUnKQ6ZbZvozVp7DlbIU60mlZYnQuwnxlHoGMtibDvG9MIyWtE5h3nmvKw5cdCLgnu5nDCm+a6klMCD8HXUxe14UsV39WLDk+oM/UAd4UPP+lYcUrlALCGftOS5vCjji9tkWipfFR/aKOEsOERfMVeyBUrE4ONnPpR2ZgbzoGXIROq1yEs8DmucekSmtkzAmYIjm92kdZRctR9H5YPFW87g8xJbYoUnUOEeQrwKm8d3kkWwjj/jgEylYnPA3AuTJYdD8QCENgh/fvJIoYdmoovlrW9xUWQYB3D6h6tPGg4/a6CKVB7t/aHl5tGDF5vwbQymOWIHdGDcj0qYpErXg0aA7nOgh1o05it49hpVXbtyL4N+zLzxhx7L4+jdyBl1T7gvJpTc4rBD vO94DNq+ +hj8D X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, 12 Mar 2024 at 15:48, Petr Tesa=C5=99=C3=ADk wro= te: > > - How we=E2=80=99ve solved the TLB flushing issues in sensitivity track= ing, and > > how it could be done better. > > Hello and welcome! I ran into a similar challenge with SandBox Mode. My > solution was to run sandbox code with CPL=3D3 (on x86) and control page > access with the U/S PTE bit rather than the P bit, which allowed me to > implement lazy TLB invalidation. The x86 folks didn't like idea... Hmm, a similar idea might be to use protection keys. I'm not sure if that really works though, we haven't given it any serious thought, since not all CPUs support it. So that would be something to explore as a later optimisation rather than a basic principle. > For the record, SandBox Mode was designed with confidentiality in mind, > although the initial patch series left out this part for simplicity. I > wonder if your objective is to protect kernel data from user space, or > if you have also considered decomposing the kernel into components that > are isolated from each other (and then it we could potentially find > some synergies). Yeah that's something we've pondered. What I've presented here is definitely about protecting the kernel from userspace/VM guest but it's a framework where you could conceivably isolate all sorts of things. Maybe there's a world where ASI makes unprivileged BPF a more viable notion. The thing is, what I'm presenting here doesn't protect against software bugs at all - if you can get the kernel to architecturally access data and do something bad with it, ASI will happily remap that data and branch back to the buggy code. That probably simplifies things quite a lot as compared to SBM. But yes, the whole "sensitivity tracking" thing does seem to share requirements with SandBox Mode, I will need to ponder this some more.