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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 837A5C433DB for ; Tue, 9 Feb 2021 16:57:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 30F7A64DFF for ; Tue, 9 Feb 2021 16:57:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233156AbhBIQ47 (ORCPT ); Tue, 9 Feb 2021 11:56:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233137AbhBIQ4f (ORCPT ); Tue, 9 Feb 2021 11:56:35 -0500 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C51CC061756 for ; Tue, 9 Feb 2021 08:55:54 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id e9so2016352pjj.0 for ; Tue, 09 Feb 2021 08:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1bFvl2bIW4Oh3wbTy7ZymRT/srGmZL+rM5fEH6hBOlE=; b=CxCedMb+RMB2rjOGYlf85FglO5AAOwRCDrVJYQqgZJ3h664qF8scVpNpV/nk0Ve6bF HEjnDUY5gDFsyQ8iVQrRAuxXEh35W9yseTgpHovrhVPKTehosh/tzsH5759uqnI1E5Wy tW6aevBIg9FHOUewdYnhGr4E8JME1JdGZoSMMOTM1uGNpxXYtBOl5oF64/yeGwHysdPw /ug4f0ZDK505aiX8XTyznhLVnlb8WxksZl73oxKbSSdi9/FRXIMClEh7Zle8ewUbrBjP G8Gap02Yhbea/hUqJqSPcJXJmsm+4qDc7RlCSD6QZnKJLJOXXCDFkOm5KQbgBLp8DbN/ Xd9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1bFvl2bIW4Oh3wbTy7ZymRT/srGmZL+rM5fEH6hBOlE=; b=taEzvJ+Aj9Gz+qz0Mk6nmzvbyVp1SdxbbdMZg27+vqYAbXoPsGiDjnl1nFFLcBIuUj 6qe5HZ02bvH280K57gnUYQ2ADuhnc8Pr6RpJ4H6RQVDQBQhwrsgS91FJdlyzgHO2wi1N lZTVzhUuVzSRStLxw0AbrKbcxvGnlzhijtN4seL6lQjCFfgOfIQ2CAITcSH36UpETx0P fqa0nRc9ggl2+eBzBrcXweoIY4adFLmGZFafKozozHfWlYe35S7fknv1PTKRcqt/SoMy YqEw8jhjnz91eKRCzXO+qHn9CyekSFjXOKlk/Rlb0K6nU0ZKGt5iDLF6Mn8rhgu6/l4c rhqw== X-Gm-Message-State: AOAM531a4JZ+u+8noUme4Mi6a+kdVRfYiNEfZ50QWwlkqd4iXVXhPnLH q66SjmI90Rkvu69IdNGu7AWcKA== X-Google-Smtp-Source: ABdhPJwO9CnieT0CraLne733rr1Axe7Z0/TeuoS/LaAA3J09+3wwD2JbNMH5wJ6XjL3/DRuyn6gOMg== X-Received: by 2002:a17:902:ed95:b029:e2:d080:7e0e with SMTP id e21-20020a170902ed95b02900e2d0807e0emr13163938plj.85.1612889753378; Tue, 09 Feb 2021 08:55:53 -0800 (PST) Received: from ?IPv6:2601:646:c200:1ef2:2db1:f678:b1ca:a522? ([2601:646:c200:1ef2:2db1:f678:b1ca:a522]) by smtp.gmail.com with ESMTPSA id z31sm2978386pjj.47.2021.02.09.08.55.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Feb 2021 08:55:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [GIT PULL] x86/urgent for v5.11-rc7 Date: Tue, 9 Feb 2021 08:55:51 -0800 Message-Id: <73175691-4AE1-496D-80D1-DC85AE1E9C27@amacapital.net> References: Cc: Steven Rostedt , Miroslav Benes , Peter Zijlstra , Josh Poimboeuf , Linus Torvalds , Borislav Petkov , Dave Hansen , x86-ml , lkml , Alexei Starovoitov , live-patching@vger.kernel.org In-Reply-To: To: Alexei Starovoitov X-Mailer: iPhone Mail (18D52) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Feb 9, 2021, at 8:45 AM, Alexei Starovoitov wrote: >=20 > =EF=BB=BFOn Tue, Feb 9, 2021 at 6:49 AM Steven Rostedt wrote: >>=20 >>> On Tue, 9 Feb 2021 09:32:34 +0100 (CET) >>> Miroslav Benes wrote: >>>=20 >>> powerpc has this >>>=20 >>> static inline unsigned long klp_get_ftrace_location(unsigned long faddr)= >>> { >>> /* >>> * Live patch works only with -mprofile-kernel on PPC. In this ca= se, >>> * the ftrace location is always within the first 16 bytes. >>> */ >>> return ftrace_location_range(faddr, faddr + 16); >>> } >>>=20 >>>>> I suppose the trivial fix is to see if it points to endbr64 and if so,= >>>>> increment the addr by the length of that. >>>>=20 >>>> I thought of that too. But one thing that may be possible, is to use >>>> kallsym. I believe you can get the range of a function (start and end o= f >>>> the function) from kallsyms. Then ask ftrace for the addr in that range= >>>> (there should only be one). >>>=20 >>> And we can do this if a hard-coded value live above is not welcome. If I= >>> remember correctly, we used to have exactly this in the old versions of >>> kGraft. We walked through all ftrace records, called >>> kallsyms_lookup_size_offset() on every record's ip and if the offset+ip >>> matched faddr (in this case), we returned the ip. >>=20 >> Either way is fine. Question is, should we just wait till CET is >> implemented for the kernel before making any of these changes? Just knowi= ng >> that we have a solution to handle it may be good enough for now. >=20 > I think the issue is more fundamental than what appears on the surface. > According to endbr64 documentation it's not just any instruction. > The cpu will wait for it and if it's replaced with int3 or not seen at > the branch target the cpu will throw an exception. > If I understood the doc correctly it means that endbr64 can never be > replaced with a breakpoint. If that's the case text_poke_bp and kprobe > need to do extra safety checks. Ugh. Or we hack up #CP to handle this case. I don=E2=80=99t quite know how I feel= about this.=