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 3552DC3DA45 for ; Mon, 8 Jul 2024 23:43:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A99D06B0096; Mon, 8 Jul 2024 19:43:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A49FD6B0098; Mon, 8 Jul 2024 19:43:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 912296B0099; Mon, 8 Jul 2024 19:43:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 740DA6B0096 for ; Mon, 8 Jul 2024 19:43:17 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1D221815F6 for ; Mon, 8 Jul 2024 23:43:17 +0000 (UTC) X-FDA: 82318214034.27.17D28A6 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf05.hostedemail.com (Postfix) with ESMTP id 523C310000D for ; Mon, 8 Jul 2024 23:43:14 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EKvIunjD; spf=pass (imf05.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720482165; 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=yDcT9L7Zk0KFiBp0ZQUaBASvcdoU9u1j2Ta/LTRDoH0=; b=YTkxJIaIiB+tq9YZR2CRxTxlrkehr7aMPrax0qY5Vfzt+7sx+ktvH7yfhkZyjsLmB3zLdU Gxgyw5mMjgfUQ2CguEAr9JcPINEQanMhxZMdQP3XEhpiEmN3lKirWnnt0NmGo5/M65m8MX WuZeE4Za0JrtPDrRP0NS2JgbBHoAi1s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720482165; a=rsa-sha256; cv=none; b=BoveGQkLBpy1X1Bo6LWhXxWqqfxC9HplFZaVicXubGNdKQcVb9MOJ37fYyixT0hNZ2C7PN sR+cHxXzChE8TmPJDn3cgKFbkRhTbOirDqEmas79lH2WiTpy2ecLMrrfhBzoSPYi1Gzpnx l/sgqCkEN+8J61Ov7R8weZ5R0eMNWoU= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EKvIunjD; spf=pass (imf05.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-70b0e9ee7bcso2621386b3a.1 for ; Mon, 08 Jul 2024 16:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720482193; x=1721086993; 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=yDcT9L7Zk0KFiBp0ZQUaBASvcdoU9u1j2Ta/LTRDoH0=; b=EKvIunjDoMRB+Q9XLlL0f+sGu+0h+IR+/heqDx/IOtAnP/tJtIT876gTSHqKoamXHd 4bmzEuR9n3DJc7ZlR7/LuF2Yaxth2vzZdrPFUNzUrm2pnTzSVREU5kEEG9DXMAvX/9DL ViQTWs5b9CVC7msr78g/1Js4q+NUdlS/N8TQjpHLcRawfKJYxX0LK82RiBv6VOEJSl6r 5gEwIfe7x9BvNfWgsES++RKVnaoKgNgvZbH5V84iU2/8Nrv86uSGzLOlliZGCGGq2zom Q0BKukNtVmd78nbzMeRJMzHcMaDeRe4D9GsWbJTRWUe9DyXlBmRQkTGhEmA0v/6LE/cj qmXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720482193; x=1721086993; 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=yDcT9L7Zk0KFiBp0ZQUaBASvcdoU9u1j2Ta/LTRDoH0=; b=dBG4ZaCpmRjqilKBZ5bl0QVXhxpP4o+irqMQKSwYBeNU17Qtjgzzo/ZG2YFDOhZxnP MtGAoss15u+JsF95uzTA8yljkCrGdEy6jqHif2AauTOvwaJmjtknSUyIbJS0Cku/eXOK puXS0Y4IvYNRUFeaszsEcRxkfgrqKbYaL+uN9lPyacljw6AyVPYX+YcrO3w/yqgVQPKR BvWJOLKDN2rcRij+SCUPOhrWPYSvdxWKulNpBzEtIjymP/KaDqIfGKiY85hnKtZplLB9 ND+eSwlZbkTIQt1t3JQxeWGO1/SHe6uIrjzBthxM0IscyORZbTe/Hdp9cUW1RW0LGh5l K1lw== X-Forwarded-Encrypted: i=1; AJvYcCVsOK/YkJ2kEXovgo0LfDSPYBGZQ7UQGtX5+CZMkaDXxehB+/YKpSdqC4L5dPSEctkui2KkMS4CuFfT903iKrtWQv4= X-Gm-Message-State: AOJu0YyN0rNNNWFh4UT9Q0jLsSAFUTVvyuSBEBtuaaI9GAvQQQd0pZd7 JefJ8XKHnm0ilt14rL776JrbN7ACCp/qvehURzVBXfzSTJ2VgFwvFbz/XTq7OylRHFfRlt2jsQh 5YmVZWclWnrYIKxo7/rvgzsVfTvU= X-Google-Smtp-Source: AGHT+IH1imuiEMLyu25NOak7kJ+zWW5+fNO/01KMRl9fOcvLwbOGzy+gF+7wDMeIVkDREa+KeJTZolbZG7rgeibCAEc= X-Received: by 2002:a05:6a21:3382:b0:1af:66aa:7fc7 with SMTP id adf61e73a8af0-1c2981ff88emr1168425637.3.1720482193011; Mon, 08 Jul 2024 16:43:13 -0700 (PDT) MIME-Version: 1.0 References: <20240627170900.1672542-1-andrii@kernel.org> <20240627170900.1672542-4-andrii@kernel.org> <878qyqyorq.fsf@linux.intel.com> In-Reply-To: From: Andrii Nakryiko Date: Mon, 8 Jul 2024 16:43:00 -0700 Message-ID: Subject: Re: [PATCH v6 3/6] fs/procfs: add build ID fetching to PROCMAP_QUERY API To: Andi Kleen Cc: Andrii Nakryiko , linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, gregkh@linuxfoundation.org, linux-mm@kvack.org, liam.howlett@oracle.com, surenb@google.com, rppt@kernel.org, adobriyan@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 523C310000D X-Stat-Signature: mtswcep3fzsc1g13af5pgpby5t9yejjn X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1720482194-189189 X-HE-Meta: U2FsdGVkX19/FaLUGbKMan3lLlkXbPwPKZdufgY8HwF4pS0m8FISfka/C6BEMHwkuia8AvKE65EoHnvzmuw/vpYQt3fUZbgPkJtptjH8F4yCMhezjzBiqiPKoAyc1FBgxspp2Wro+LHMjYzB1VbD3LeBqp7EgHcPA/cBkasBJavZCJQ5UPvITl/+E+MZfNz0zbau2vkt7mSzI6CSgRehsHBbfk1MF/HXcyTzVsbxB1ThheQk43SifoxKJ99YN5o7g5Yzf27Jj3/oKcmj03D41+EVz3KsEwjOm2hLDgtZh5WeFN1XdRvjZyMi9pQZAtC98I+phLWMIlnE6L5LmcNtSusp0A1F96NKymyT2OR1XTyQZIDH7tQt1Asj/Nu0+jWcQCTMx4jfc1jHBYO6ut+zJNfYw0cjl8+aSlZ6rC/BJvqPGug7NhwVuqYOEAAAm5cz566k3YdgjO2+x+FOhMSWy1JSb6xBo39Fx0RWngDsTscN4Y5C84c4jwBlG89qhRPEgwmH+fm4JW07boRs2yOia51mB7/djkQS9dTRzi4MXQ8FAwetO/tPxTAwB9m9JF6HmfiFKyY6+fY8IK9zu6x7N3tlo/HI6nK9H5kjd+NdX5w8QRLB+u8iIUIvEdzXrWKS3GSnfdgpbqw86v78OqrQt9IZt1SEqAHcbtY6wiVOa7KzB6SBVsan1pVC3MHstanYDtZHgkTUvbfEQxB3QGGefyQieSZmLbTV4YZflzKSECe86ACiEZoZczzQnrvEjEjVQbtH+RfdcYxhUifPrVFCY1pF0Uzl4OFsGV3G9b7EwTaIh+9q1dDtNJ6V4uhe4kt8nb6sd91n/KGqY1E7b9ZiZ19K6GiLhlaOhykcPNrVQMaSR/Kt3c9FpTP08OdJxbZxhgBEA1mLgcB60Mr6aBzul8Q4S+wqFeNiuOQEFb7o34hRMRTE4Tcv4pGuBKLGjSryZe4LFQvcCgad7tGtGES XI2P1Js4 xa3utcQq1gbeoSfm5QXLrB4Jk9Z8Oxsoq6oRyzgtdtwAc88CiG++OHkAko0bCxj+URHY4QrQidtmD6ix0KSvzNFCAtoSdIatrSj8Pm8c9vsPIDNBsCVYYYkpVoXq0qwXOZ/6TNV+7jjrdO+AG63VDtTTVMaLRJbg38mrhSvKVeA4PMsHjlvPYsHuMF7HtXFA8uPZLGMSSiXKulnyzu+28Kg4pyxbz7SbwATkiXoJnTJwCKAhRSusPzWR/v3Ca7qfNhFDl1+nZKmf44i3uRK5aAiGR5N3m9PpShce3h6+lFBl4t+KBlqaY4CSfa3TfWwWxqEJd7mSFkrw4R3wSbi2UUxD+ar9dyEJzb/DlDbI4mTlQP+HhgQ63vgSeUepGjq4lOzhGJgNW1TEJ8uT/F/v/MGp8CA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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, Jul 2, 2024 at 7:50=E2=80=AFAM Andi Kleen wrot= e: > > > 1) non-executable file-backed VMA still has build ID associated with > > it. Note, build ID is extracted from the backing file's content, not > > from VMA itself. The part of ELF file that contains build ID isn't > > necessarily mmap()'ed at all > > That's true, but there should be at least one executable mapping > for any useful ELF file. > > Basically such a check guarantee that you cannot tell anything > about a non x mapping not related to ELF. Hey Andi, So when we were discussing this I was imagining that inode/address_space does have something like VMA's VM_MAYEXEC flag and it would be easy and fast to check that. But it doesn't seem so. So what exactly did you have in mind when you were proposing that check? Did you mean to do a pass over all VMAs within the process to check if there is at least one executable VMA belonging to address_space? If yes, then that would certainly be way too expensive to be usable. If I missed something obvious, please point me in the right direction. As it stands, I don't see any reasonable way to check what you asked performantly. And given this is a bit of over-cautious check, I'm inclined to just not add it. Worst case someone with PTRACE_MODE_READ access would be able to tell if the first 4 bytes of a file are ELF signature or not. Given PTRACE_MODE_READ, I'd imagine that's not really a problem. > > > > > 2) What sort of exploitation are we talking about here? it's not > > enough for backing file to have correct 4 starting bytes (0x7f"ELF"), > > we still have to find correct PT_NOTE segment, and .note.gnu.build-id > > section within it, that has correct type (3) and key name "GNU". > > There's a timing side channel, you can tell where the checks > stop. I don't think it's a big problem, but it's still better to avoid > such leaks in the first place as much as possible. > > > > > I'm trying to understand what we are protecting against here. > > Especially that opening /proc//maps already requires > > PTRACE_MODE_READ permissions anyways (or pid should be self). > > While that's true for the standard security permission model there might > be non standard ones where the relationship is more complicated. > > -Andi