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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3E1EFC4345F for ; Mon, 29 Apr 2024 08:37:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=w2VK3rlaIri6nDIBJX0M34b8d/9WPwIhjIr+QmPJ02E=; b=5A2biBUnlLr+ey cScHOBlPZWBMJ/9+ujIgvD8mPh53uEPIKh5n94tHthbi16VY0FbfoRmJYp2RB1oLC66mNaer3ujjB lnlm8r1tEhvEmja+TQnUiYazTs4kswHbL7MPbwXMCTCk5FwkDNZjEAZ7wR9adnEFw55+FQpI+x2TJ vB1fbJIVxxHMFf7M2elnprrzc+yqy0/F3MlzLicJno/Id4WDCLqbZFxmHvChziEWaM4MGEb58eydz lnmtDQg14vpSH1DtHLgdWUrBODXXgGSnaPffKyf/FWi5FFDUTf19xzMurjnTp9kfFrdpx/HoGd8JV TtRwBMpiZV9pRypS1k0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s1MV5-00000001yJN-0RdO; Mon, 29 Apr 2024 08:36:39 +0000 Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s1MV2-00000001yH5-0afi for linux-arm-kernel@lists.infradead.org; Mon, 29 Apr 2024 08:36:37 +0000 Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-6eb6b9e1808so1903990a34.3 for ; Mon, 29 Apr 2024 01:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juliahub.com; s=google; t=1714379793; x=1714984593; darn=lists.infradead.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ubSEdojDGK/PFJMQ7BmKqUuibopOG0NrDcRek/z+wGI=; b=O/mLPGjfi2dipp2yNXptkAJ8uWsCwtZJU91RfVVVnvOYhs/dqq/cSB4uujGwBNL4FF PlducQ7V+G4Dzn2sgzJGU0j4Qht9zoKy9WBM6APOMsVxVec+3bbINKBcrvXGrwf2LqrN NFGnZHDpKHfQ5DP1FSHK3szDJE+uCdL1dEKnK6HZXfFSMBH7/zvA/1B989KHtaQtA0qK DaHgzSExNUm8aLhFQO9N8bHhGE99SQCCF3Lz4gkY1N1nTgIT+YC6NbbLjwyG+id5C1Rs KCzag+BCYEilwEYHaJt9SOdVk62QgfbXksuX4/cbcgwVtVpXL7s/bM5H1MDLeMVkO3Np ZZAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714379793; x=1714984593; h=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=ubSEdojDGK/PFJMQ7BmKqUuibopOG0NrDcRek/z+wGI=; b=AvUujlxm929X7MBwuUDbAviEW4LuP/OsgejiUUIoj80+oT/02eUlj5AmAaX+xn8Ig0 XKwwNhzBlonYae57IEzHAi08MC/Cqr4c40vSJf4qAX1F4hFkSJ96+uE4Sl9AZpa4zXIp VQZcIQaSpIERMDaKd1UJ2LN1tjdIZLi23KXOA+eyH/OcOGQn2sjgRAd97j5HxX0NHkq4 S8un/aAWKuJo/4ODYXlcwW4uAoyUclygdVTn63LDrUPruqx9LqQ7WPokMkMf+L2QBI8j ZXsEJuRNMGEz7VKVf1c+8LtjJ2Oim+OlPfmFeOaI2EaRP35t2JoNy8xryeeXOeApjPZw fnFw== X-Forwarded-Encrypted: i=1; AJvYcCUaulqqs0qTVZickeHDVPsIQD6mmZ6uDtfXjqN3xb6kGOnxsr2AelBipFTvwAfJvCSDVPO1pGnGQJFKFgyX3bLopjXPoZWQNUc2zCJW9WdixKlBY/k= X-Gm-Message-State: AOJu0YxmrvG56UGC57le+nrQHcHIiGeH94ZAyGIKIEcDcD2fhL5K4/09 wcI1dNEi8mjIEFniWuLM26rGeKf9dwFSQbGgRIiXxW6uz3d2zfaEdq6VtXZnAEcON0WP8ikXInD /XW1t/b4ZELYyTfdr+DHrS2xV/vXDPP5uMQWXJA== X-Google-Smtp-Source: AGHT+IElStMXorKyFWStPxjz5x5a0Wg0YZc2ud5M6fyMjTSK6YzvOLlsUwFgIf0YQk93iFADv8eAhUNjy7gouh84Gio= X-Received: by 2002:a05:6830:14cf:b0:6ee:3b91:5e3b with SMTP id t15-20020a05683014cf00b006ee3b915e3bmr1974106otq.27.1714379793080; Mon, 29 Apr 2024 01:36:33 -0700 (PDT) MIME-Version: 1.0 References: <20240427052754.2014024-1-pcc@google.com> <87h6flu61d.wl-maz@kernel.org> <86a5lcr5a3.wl-maz@kernel.org> In-Reply-To: <86a5lcr5a3.wl-maz@kernel.org> From: Keno Fischer Date: Mon, 29 Apr 2024 04:35:56 -0400 Message-ID: Subject: Re: [PATCH] arm64: Implement prctl(PR_{G,S}ET_TSC) To: Marc Zyngier Cc: Peter Collingbourne , Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, Yichao Yu , "Robert O'Callahan" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240429_013636_276658_7100B4AE X-CRM114-Status: GOOD ( 18.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org First a note that this has been previously discussed on this list for the same motivation and with the same questions asked, so let me link that first: Link: https://lore.kernel.org/linux-arm-kernel/CAP045ApiMSvP--f2E0=VdMbjE8oibvy921m8JASf4kaCCuU2RA@mail.gmail.com/T/ > It seems to me that this sort of "trap and inspect" behaviour is in > the realm of ptrace(), and not that of prctl(), because I can't > imagine the debugged program calling that by itself. In the rr use case, this is indeed used to force a ptrace signal stop for trap/inspect (or emulate in replay mode). Of course the history of PR_SET_TSC is complicated and was not originally intended for this use case. Rather, it was intended as a hardening mechanism against cache-timing/speculative execution attacks (this was pre-Spectre, so all the discussion at the time is a bit theoretical). Of course, the Spectre experience has shown that you don't really actually need architectural timers for any of this, so perhaps it wasn't all that useful in the first place. I think this could reasonably be made a PTRACE_EVENT, but that would not be useable for hardening if somebody wanted to do that in the future (I am not personally aware of any such request, but it doesn't seem unreasonable). Of course, my concerns about adding yet another kind of ptrace stop mentioned last time still exist. Perhaps a third option would be to put this into seccomp instead. One could imagine a flag addition to SECCOMP_SET_MODE_FILTER that would enable filtering for all otherwise emulated instructions (not just a CNTVCT_EL0 read) and an appropriate bpf program to decide allow/disallow/trap/signal/whatever. Of course, there are folks already unhappy with using seccomp for non-security purposes (as rr already does), so there may be some objection there. Similar concerns about making ptrace stops more complicated apply (basically the issue is that what you can do to a tracee at a ptrace stop very much depends on where exactly in the kernel the tracee is stopped, which ptrace doesn't always tell you, so to be fully correct, ptracers need to do some very elaborate state machine tracking). > How does rr work on non-x86 architectures? How does this interoperate > with AArch32? rr has significant microarchitecture dependence. It works on most modern x86 chips (AMD worse than Intel with the exception of some Intel Atom uarchs) and more recent high-end AArch64 chips as long as the programs only use lse atomics and not llsc. AArch32 is not supported. See here for a list: https://github.com/rr-debugger/rr/blob/822863c92d8f52778700f0375ac1b705193a2152/src/PerfCounters.cc#L198-L237 Thanks, Keno _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel