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 B3400C433F5 for ; Fri, 13 May 2022 11:08:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A8CE6B0073; Fri, 13 May 2022 07:08:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 356698D0001; Fri, 13 May 2022 07:08:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F6286B0078; Fri, 13 May 2022 07:08:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0FD486B0073 for ; Fri, 13 May 2022 07:08:21 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BE71433032 for ; Fri, 13 May 2022 11:08:20 +0000 (UTC) X-FDA: 79460445960.18.6429F51 Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by imf23.hostedemail.com (Postfix) with ESMTP id 9796A1400AD for ; Fri, 13 May 2022 11:08:05 +0000 (UTC) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-2f7c57ee6feso86700567b3.2 for ; Fri, 13 May 2022 04:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JREMHrhRnmFXzY43T8lrU7YAoHvId1ic6AHyQlmWHr4=; b=jgU+agWozrb1Iq7qvHz+pWY/0Mhi1Ofby5FMgFiF/bU/yGxJSQJjUuNnG9tccTVIp3 p1MOPGv1oewd6owpIyZL+v04n5lh99R1y4OcL2wMO1JezMI9rTrnvHjTrvlEDZjNj6el QiOl9R2uauDLODlhWxMxNhgZVf5MPqLxiWmsUOWh1wobGvy0Y6XAilfCRgav+H7BPD4m PZVJWYcUrVlpicrq1vfCzgzHHF8tgQ/flODi1ap93VdfyffUqGhTZt3XHkXPihLJdTcw 9GYuJZN188L19XciJY7d0IqjnU8oeacAM9ufz6FazRLyPsmfm3MZciFwPkA6qb/uIIRk RmyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JREMHrhRnmFXzY43T8lrU7YAoHvId1ic6AHyQlmWHr4=; b=tVsAv6s/MSxnQdS8jE5Gp+084oV8EB1lPUEy3qRTgKEZI9EZzxpCkRYYetT4ydhapj sOgq9CvpgthMjGTCpF+HeKUG23LV+6edvhvtCR8/iRNk5OhPBUqt499bLcWxry2aLkt7 dXUKJqqw7ycMe37TP6IczDFLWINP8uu6/n1bGoykK0yqTekM2HLzI0TzkpMh7h1BinDO JcyZrmEFmL6N2zJjnhJ1FhWFmwFh15IzP0vKEwjVAYPVfacMn/HtBCfi+NKWbctMyBgJ zxotEcDsA+2L19o5hRxNb6gw+AJkIib4+5W9R4wV1fupHiR9+LZQC0C9rWhHKNw32W3C R2HQ== X-Gm-Message-State: AOAM531oHwbapwAyMAoMq8Ui7RWVYdKh82o2fy/G+LZfF+Ncvr6zNJJ5 r36mQFLhc+hrPqDRkyh9v4U8j5ItroJ6tSBFgzJTOA== X-Google-Smtp-Source: ABdhPJzGOBX3yenemlairB/CBb3881W/vk+vs+5T3k6dV0sbJPG/UpCVQPhZN0hRrMn+P6ETO0NZVzhTFO/wYJy6FgM= X-Received: by 2002:a0d:f0c3:0:b0:2f4:d291:9dde with SMTP id z186-20020a0df0c3000000b002f4d2919ddemr4969992ywe.437.1652440099204; Fri, 13 May 2022 04:08:19 -0700 (PDT) MIME-Version: 1.0 References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511064943.GR76023@worktop.programming.kicks-ass.net> <20bada85-9203-57f4-2502-57a6fd11f3ea@intel.com> <875ymav8ul.ffs@tglx> <55176b79-90af-4a47-dc06-9f5f2f2c123d@intel.com> In-Reply-To: <55176b79-90af-4a47-dc06-9f5f2f2c123d@intel.com> From: Alexander Potapenko Date: Fri, 13 May 2022 13:07:43 +0200 Message-ID: Subject: Re: [RFCv2 00/10] Linear Address Masking enabling To: Dave Hansen Cc: Thomas Gleixner , Peter Zijlstra , "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , "the arch/x86 maintainers" , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=jgU+agWo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of glider@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=glider@google.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9796A1400AD X-Rspam-User: X-Stat-Signature: wowputwa61zy7enuwhdjzpifwqqgfq48 X-HE-Tag: 1652440085-157455 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000079, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, May 12, 2022 at 11:51 PM Dave Hansen wrote: > > On 5/12/22 12:39, Thomas Gleixner wrote: > >> It's OK for a debugging build that runs on one kind of hardware. But, > >> if we want LAM-using binaries to be portable, we have to do something > >> different. > >> > >> One of the stated reasons for adding LAM hardware is that folks want t= o > >> use sanitizers outside of debugging environments. To me, that means > >> that LAM is something that the same binary might run with or without. > > On/off yes, but is there an actual use case where such a mechanism woul= d > > at start time dynamically chose the number of bits? > > I'd love to hear from folks doing the userspace side of this. Will > userspace be saying: "Give me all the bits you can!". Or, will it > really just be looking for 6 bits only, and it doesn't care whether it > gets 6 or 15, it will use only 6? (speaking more or less on behalf of the userspace folks here) I think it is safe to assume that in the upcoming year or two HWASan will be fine having just 6 bits for the tags on x86 machines. We are interested in running it on kernels with and without CONFIG_X86_5LEVEL=3Dy, so U48 is not an option in some cases anyway. > Do the sanitizers have more overhead with more bits? Or *less* overhead > because they can store more metadata in the pointers? Once we have the possibility to store tags in the pointers, we don't need redzones for heap/stack objects anymore, which saves quite a bit of memory. Also, HWASan doesn't use quarantine and has smaller shadow memory size (see https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.htm= l for more details). Having more bits increases the probability to detect a UAF or buffer overflow and reduces the shadow memory size further, but that one is small enough already. > Will anyone care about the difference about potentially missing 1/64 > issues with U57 versus 1/32768 with U48? I don't think anyone will. Having said that, I agree with Dave that it would be nice to have an interface that would just request the mask from the system. That way we could have support for U57 in the kernel now and keep the possibility to add U48 in the future without breaking existing users. I also may be missing something obvious, but I can't come up with a case where different apps in the system may request U48 and U57 at the same time. It seems natural to me to let the OS decide which of the modes is supported and give the app the freedom to use it or lose it. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie = mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.