From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A6621361 for ; Mon, 16 May 2022 16:39:39 +0000 (UTC) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-2ff1ed64f82so8822967b3.1 for ; Mon, 16 May 2022 09:39:39 -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; bh=DJ1mj/6AEbnCZ4HPughZpfwPoxjL4U+12a8eW3KN+cU=; b=BrUCwqzxN2mNfk/ExieimQ9XkZd769u40ZXKgP3WMEJSnoidxk7l4mgPgX8TQLEUf+ mHoGRcO4qbZrF3SZvjLddv1SFfTTPb/Qdm7F/4Iww+SxqXQBztROLAuEfJN/v/B1VpYQ Ow8ybjFEWj00m3V7QA+mRR5vUigRQPZszrSAj3T8lfAbC2/FCRo96LSLXzVjjdgvWDsV Yfs6cGR6w4Xbfm8W5Mf6h60V4gzbxVxbjBnQXmEnogjmm/VFkWUOQpgtI8/qriceckOr RaOqb/nWuFQtgqtCf0NnQumcR5ga8ZlkjY+sc2wBUohWGR5PrpBBo67IOdsHmRMHYVWj 3kpQ== 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; bh=DJ1mj/6AEbnCZ4HPughZpfwPoxjL4U+12a8eW3KN+cU=; b=vugfS374NVX+wtBIH0KYZmcgiBXX6ObVJD2SwlhaJTLuEKF9zwvnEetKx4+fdto1A4 CY4kN6aZp0gBwRMByoxG5vULEqErzuZnnaekWP+NswYyVZXhIw+Jwt05fpZtv6q0OY/1 VsSTeEbIgregLvKS2vI4ba9ODlFEsEl9NzTPoOHPeWsy5IoJ/ISRDJ7fEI1qiAMyXOGg 5gsfraSfdDQMQB8JKIrQ/UxSIvjpnpj5s+1xAQLm0PqBkvEahs+GrFgCaEQ7O1sJY7DD f2aaxk9GBJ5/qWQ1bS4LowB4NX0k+jOC8UeBxoiJ4iwrDUfmqsKw430NKlRGS5y/brxc Z+LQ== X-Gm-Message-State: AOAM533cVz+uYbfqwJRMQSjx8KbOHyZ1Q9qBZjApcAK5DyQlhxDSgsZq Fhu7naiNnghltCKTGt0IAtDKX+bJmZtXre3ZP0afbA== X-Google-Smtp-Source: ABdhPJzQJa1N5l2z5xfrd+zcTG6blvNDsfHVm9LuNqqXVzDY9SqhLJ1LbDtJEHO1K6Zz6VnIidKyyWBgtD0CkopkxGA= X-Received: by 2002:a81:4ecf:0:b0:2fe:d9f2:15b3 with SMTP id c198-20020a814ecf000000b002fed9f215b3mr11033942ywb.305.1652719177966; Mon, 16 May 2022 09:39:37 -0700 (PDT) Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-21-samitolvanen@google.com> In-Reply-To: From: Sami Tolvanen Date: Mon, 16 May 2022 09:39:02 -0700 Message-ID: Subject: Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG To: David Laight Cc: "linux-kernel@vger.kernel.org" , Kees Cook , Josh Poimboeuf , Peter Zijlstra , "x86@kernel.org" , Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , "linux-hardening@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "llvm@lists.linux.dev" Content-Type: text/plain; charset="UTF-8" On Mon, May 16, 2022 at 1:32 AM David Laight wrote: > > From: Sami Tolvanen > > Sent: 13 May 2022 21:22 > > > > With CONFIG_CFI_CLANG, the compiler injects a type preamble > > immediately before each function and a check to validate the target > > function type before indirect calls: > > > > ; type preamble > > __cfi_function: > > int3 > > int3 > > mov , %eax > > Interesting - since this code can't be executed there is no > point adding an instruction 'prefix' to the 32bit constant. The reason to embed the type into an instruction is to avoid the need to special case objtool's instruction decoder. > > int3 > > int3 > > function: > > ... > > ; indirect call check > > cmpl , -6(%r11) > > je .Ltmp1 > > ud2 > > .Ltmp1: > > call __x86_indirect_thunk_r11 > > > > Define the __CFI_TYPE helper macro for manual type annotations in > > assembly code, add error handling for the CFI ud2 traps, and allow > > CONFIG_CFI_CLANG to be selected on x86_64. > > > ... > > + > > + /* > > + * The compiler generates the following instruction sequence > > + * for indirect call checks: > > + * > > + * cmpl , -6(%reg) ; 7 bytes > > If the is between -128 and 127 then an 8bit constant > (sign extended) might be used. > Possibly the compiler forces the assembler to generate the > long form. > > There could also be a REX prefix. > That will break any code that tries to use %reg. The compiler always generates this specific instruction sequence. > > + * je .Ltmp1 ; 2 bytes > > + * ud2 ; <- addr > > + * .Ltmp1: > > + * > > + * Both the type and the target address can be decoded from the > > + * cmpl instruction. > > + */ > > + if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE)) > > + return; > > + if (insn_decode_kernel(&insn, buffer)) > > + return; > > + if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7) > > + return; > > Since you are looking for a very specific opcode why bother > calling insn_decode_kernel() - just check for the required (masked) > byte values. Because I need to decode both the immediate value and the register from that instruction. > > + > > + *type = insn.immediate.value; > > + > > + offset = insn_get_modrm_rm_off(&insn, regs); > > Given the expected instruction, isn't that -6 ?? No, this is the register offset. > > + if (offset < 0) > > + return; > > + > > + *target = *(unsigned long *)((void *)regs + offset); > > WTF is that calculating?? It's reading the register value from pt_regs. Sami 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 0D48EC433EF for ; Mon, 16 May 2022 16:42:56 +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=vQqTLw+TptxNTSFTNWIllvWEqeuPOGraP1CPrGAmK6I=; b=WMjnozRIv2ENeI MIDuQOpmcvg/P9rbXBnGetYb+SKJGQjsdJUBNc6WR4KJpyZ0QAFHYAiSsvNhwcUJJf8Ibd/k1YrFt Z2xJLOf9psqfMitYpo4cV3a7FTqAHGPpcSsSCChdipcCGU3odBfrA0PuvPGvgKSRS5FyNS96EeaTl OA8rlTtyjzi5lp7NQxUMVZf2XtOY9ae2+xAKcqLqGoce7IQdBQwqhNMD6BYtzS4+weTFEPOYhX5so Su6mm19SjTyzml5R8d+pxWaid8CQunCM81qB22YYqKh81WnG+4nfkcIzb3ELnL206bt+tn81DJWnW 6D4AM1DdYptQ+V7TfrkQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqdmg-0095vd-Uk; Mon, 16 May 2022 16:41:27 +0000 Received: from mail-yw1-x112d.google.com ([2607:f8b0:4864:20::112d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqdky-0094zE-AM for linux-arm-kernel@lists.infradead.org; Mon, 16 May 2022 16:39:42 +0000 Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-2fedd26615cso47227047b3.7 for ; Mon, 16 May 2022 09:39:38 -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; bh=DJ1mj/6AEbnCZ4HPughZpfwPoxjL4U+12a8eW3KN+cU=; b=BrUCwqzxN2mNfk/ExieimQ9XkZd769u40ZXKgP3WMEJSnoidxk7l4mgPgX8TQLEUf+ mHoGRcO4qbZrF3SZvjLddv1SFfTTPb/Qdm7F/4Iww+SxqXQBztROLAuEfJN/v/B1VpYQ Ow8ybjFEWj00m3V7QA+mRR5vUigRQPZszrSAj3T8lfAbC2/FCRo96LSLXzVjjdgvWDsV Yfs6cGR6w4Xbfm8W5Mf6h60V4gzbxVxbjBnQXmEnogjmm/VFkWUOQpgtI8/qriceckOr RaOqb/nWuFQtgqtCf0NnQumcR5ga8ZlkjY+sc2wBUohWGR5PrpBBo67IOdsHmRMHYVWj 3kpQ== 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; bh=DJ1mj/6AEbnCZ4HPughZpfwPoxjL4U+12a8eW3KN+cU=; b=0tRjw92Mi+t5tlkhDeizvobM7alb4YQiEPxZXLf6vR6hsHITCvALL8uU2e24086WdG hhB2CgzftmfihtM9sffKiznmqItbwX268Gu81aKCMT7ps7xL3WSr1ZGA2xVT4fn8LfUp BaGhaJLKNkFgo0AeGaRvPQYdwVAmptHO3Tv8GfzO5rLJdOsmNtrtxTHojWAJ8nuTPU/T qHFlt+c4gXs+si7N50HhPEZxT91WT+hbRG4WnarH6d6ecr8qHe08boAYN/9wkzPDRgCe gwKZqHUnO2M+6P/+F/cI2DHS0D8dneX3g9aKpTPiEJ+8RalPaWVfxqabgFr9gTE6TQRs wf6g== X-Gm-Message-State: AOAM532reotlnOd7YM5dgfxmUt+wPZaLuFh8VpHfEqx/nJ1Qk0Bg6l5M c0TpzpT7KfwpzaB8KNzr3BP/RJE4YFpYclmz9f9WAA== X-Google-Smtp-Source: ABdhPJzQJa1N5l2z5xfrd+zcTG6blvNDsfHVm9LuNqqXVzDY9SqhLJ1LbDtJEHO1K6Zz6VnIidKyyWBgtD0CkopkxGA= X-Received: by 2002:a81:4ecf:0:b0:2fe:d9f2:15b3 with SMTP id c198-20020a814ecf000000b002fed9f215b3mr11033942ywb.305.1652719177966; Mon, 16 May 2022 09:39:37 -0700 (PDT) MIME-Version: 1.0 References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-21-samitolvanen@google.com> In-Reply-To: From: Sami Tolvanen Date: Mon, 16 May 2022 09:39:02 -0700 Message-ID: Subject: Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG To: David Laight Cc: "linux-kernel@vger.kernel.org" , Kees Cook , Josh Poimboeuf , Peter Zijlstra , "x86@kernel.org" , Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , "linux-hardening@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "llvm@lists.linux.dev" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220516_093940_440575_3D76DBB2 X-CRM114-Status: GOOD ( 27.60 ) 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 On Mon, May 16, 2022 at 1:32 AM David Laight wrote: > > From: Sami Tolvanen > > Sent: 13 May 2022 21:22 > > > > With CONFIG_CFI_CLANG, the compiler injects a type preamble > > immediately before each function and a check to validate the target > > function type before indirect calls: > > > > ; type preamble > > __cfi_function: > > int3 > > int3 > > mov , %eax > > Interesting - since this code can't be executed there is no > point adding an instruction 'prefix' to the 32bit constant. The reason to embed the type into an instruction is to avoid the need to special case objtool's instruction decoder. > > int3 > > int3 > > function: > > ... > > ; indirect call check > > cmpl , -6(%r11) > > je .Ltmp1 > > ud2 > > .Ltmp1: > > call __x86_indirect_thunk_r11 > > > > Define the __CFI_TYPE helper macro for manual type annotations in > > assembly code, add error handling for the CFI ud2 traps, and allow > > CONFIG_CFI_CLANG to be selected on x86_64. > > > ... > > + > > + /* > > + * The compiler generates the following instruction sequence > > + * for indirect call checks: > > + * > > + * cmpl , -6(%reg) ; 7 bytes > > If the is between -128 and 127 then an 8bit constant > (sign extended) might be used. > Possibly the compiler forces the assembler to generate the > long form. > > There could also be a REX prefix. > That will break any code that tries to use %reg. The compiler always generates this specific instruction sequence. > > + * je .Ltmp1 ; 2 bytes > > + * ud2 ; <- addr > > + * .Ltmp1: > > + * > > + * Both the type and the target address can be decoded from the > > + * cmpl instruction. > > + */ > > + if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE)) > > + return; > > + if (insn_decode_kernel(&insn, buffer)) > > + return; > > + if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7) > > + return; > > Since you are looking for a very specific opcode why bother > calling insn_decode_kernel() - just check for the required (masked) > byte values. Because I need to decode both the immediate value and the register from that instruction. > > + > > + *type = insn.immediate.value; > > + > > + offset = insn_get_modrm_rm_off(&insn, regs); > > Given the expected instruction, isn't that -6 ?? No, this is the register offset. > > + if (offset < 0) > > + return; > > + > > + *target = *(unsigned long *)((void *)regs + offset); > > WTF is that calculating?? It's reading the register value from pt_regs. Sami _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel