Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3867897imm; Mon, 8 Oct 2018 10:49:00 -0700 (PDT) X-Google-Smtp-Source: ACcGV62KlXvids6rRmFNwIB8r7ZZqPTmJDo9xmThlPxH/d1jaX12MEXnQv+zYZTzgg8HYDTmYAu3 X-Received: by 2002:a62:939d:: with SMTP id r29-v6mr26342937pfk.55.1539020940342; Mon, 08 Oct 2018 10:49:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539020940; cv=none; d=google.com; s=arc-20160816; b=tjoXWwL5Cb0gT5UjkE2hA24G14K04gMSVLMWo7SpkbPTXmm0IVx1TwfU1w/TmsqdGR EiT8zCYNvt4dY5Upsw3y0DVDJPboQqihtTLlI9QaE6HnwSakstLs7WoOm3pxXXNojiMF EbXBHGDSkg7X0gEM65RiKsrkVwzJCPGmiXywik0P1GHZGmHFs9KmO18wd6LQnHqDKEJA N2VeFEyHwnzUChbuwiSl9VYp9Knf/+8pfyM0VXupWfnIuVsJCDS1qBtnsRXrJSsG0Co4 yCagRvPWQjlok6xb6bHNC9ClGbw9s9nJtSDuCpn7k68FANRoQ45N/tvFj+x/idmQc2Ez RcXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=8D+awCa3qqzmyCe4kPPrdC/Oz1P+gaNIc4Pgm4R8TQ0=; b=W6C77XRqT0SzG9f8yTRv269hcX4N5/0RM7hE4QdyBufbbNO4ZP7mfBZCJlc7LIm2yp vlmUiagyLmMuBx2S0rZJcpV42fgu5fWAOA8NSm68DsGgS/ne40wmR6wRd1bYL4vbmAUe xZQuhGHngYxWG6EKUvuzyNJci5yJVDd8fwfPjBtfelCEGzP1lAgQcJwxWVCEelnnKGC0 HoocBHU2ibLB4G5vP0N+07bMya7tAyy+ahJ646lqyvISGwGWyTdAEkmi2JFULhcrVkYm tUKlTWjC9WbFYQC2AlUfJaYHDiZMHPGzDgyQrCRFIasVh0iJB3K0CYQVgQM4GZAQvNce b6vw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WCBd34nN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k65-v6si19528898pfj.115.2018.10.08.10.48.44; Mon, 08 Oct 2018 10:49:00 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=WCBd34nN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726613AbeJIBAO (ORCPT + 99 others); Mon, 8 Oct 2018 21:00:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:59594 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726393AbeJIBAO (ORCPT ); Mon, 8 Oct 2018 21:00:14 -0400 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F40CB214FA for ; Mon, 8 Oct 2018 17:47:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539020844; bh=8D+awCa3qqzmyCe4kPPrdC/Oz1P+gaNIc4Pgm4R8TQ0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WCBd34nN0x3YGlpO1ZgJ32kG4QMgmPDHbdWNHtjYMsRXQOPIjyuuhKJMk8TBcjAjV pPQYVHZd7KUFQ4yLBHM1ApoXsNrSmqaKLh+Ns7gxfJ3k9F4z0s6xrfXGcsqMFJlFus QXjdrAJkJ2etQzXJFV9vXMsNTcIeVO6CS2Zg3Gxs= Received: by mail-wr1-f41.google.com with SMTP id e4-v6so21796336wrs.0 for ; Mon, 08 Oct 2018 10:47:23 -0700 (PDT) X-Gm-Message-State: ABuFfoipC9uynXpZRHJSCDN8s4Xkd6DGXzPnSJVR/5U2vfYaiC6Eff10 +5tJukHF1rKk2dYfIl9G4OUYialgFRy7yP7+PxeVgg== X-Received: by 2002:adf:9792:: with SMTP id s18-v6mr18167234wrb.283.1539020842298; Mon, 08 Oct 2018 10:47:22 -0700 (PDT) MIME-Version: 1.0 References: <20181006015110.653946300@goodmis.org> <20181006015720.634688468@goodmis.org> <20181006121211.GA5663@hirez.programming.kicks-ass.net> <20181006093905.46276505@vmware.local.home> <20181008072134.GB5663@hirez.programming.kicks-ass.net> <20181008155757.GC5663@hirez.programming.kicks-ass.net> <20181008163953.GD5663@hirez.programming.kicks-ass.net> In-Reply-To: From: Andy Lutomirski Date: Mon, 8 Oct 2018 10:47:10 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [POC][RFC][PATCH 1/2] jump_function: Addition of new feature "jump_function" To: Jiri Kosina Cc: Ard Biesheuvel , Peter Zijlstra , Steven Rostedt , LKML , Linus Torvalds , Ingo Molnar , Andrew Morton , Thomas Gleixner , Masami Hiramatsu , Mathieu Desnoyers , mhelsley@vmware.com, "Rafael J. Wysocki" , David Woodhouse , Paolo Bonzini , Josh Poimboeuf , Jason Baron , Andrew Lutomirski Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 8, 2018 at 10:44 AM Jiri Kosina wrote: > > On Mon, 8 Oct 2018, Ard Biesheuvel wrote: > > > Does that mean that architectures could opt out of doing the whole > > objtool + relocation processing thing, and instead take the hit of > > going through the trampoline for all calls? > > There are architectures that aren't [currently] supported by objtool at > all anyway. > The the credit of most architectures, though, the only reason x86 would want to use objtool instead of digging the results directly out of the relocation data is that x86 has an overcomplicated instruction encoding and there's no fully reliable way to find the address of the instruction that contains a given relocation without fully disassembling the binary.