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 AFD3FC433F5 for ; Mon, 16 May 2022 21:34:12 +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:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2G+T9gQH29hrBWIgu0f41MD/+gwJokcccCrLAW7uSEw=; b=HXOqciYdL/mt53 QE7K8RGDoHytS332E3DTps8dDKib+2kClSyws2FlSXyQL1y3FW3e9L5nDYNMyrnOquECJzqeqFMqY kupPRHH+gUqkXHPVeZSDGWv4SV75hmeY3E5Y6g/vpwDItsClJXwapziM2d9U530quHN85vSTv+M2W J3ifsDeBj5fu3z4pONnnLIsDrCDL/RYGsJp6uShEjuhzCBmGE9GnT47CNiuWjGDRCdyfVaOj5jUun 3aKD4QRi+Gx0+kzwM//3P2JxSnbSwSYu1pREArpo/7h6/Kf0lE+7+G5KnWuOoUoEOeMemNSGAYNEo sbGTmhaPiNdUlnbEsuWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqiKy-00AKOs-4D; Mon, 16 May 2022 21:33:08 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.85.151]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqiKt-00AKJF-75 for linux-arm-kernel@lists.infradead.org; Mon, 16 May 2022 21:33:06 +0000 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-258-XPGIMpHAPt6Ggx_0Nc-b8Q-1; Mon, 16 May 2022 22:32:56 +0100 X-MC-Unique: XPGIMpHAPt6Ggx_0Nc-b8Q-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Mon, 16 May 2022 22:32:55 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.036; Mon, 16 May 2022 22:32:55 +0100 From: David Laight To: 'Sami Tolvanen' 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" Subject: RE: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG Thread-Topic: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG Thread-Index: AQHYZwdlgt4N7xLw0EK8voqNmmoVIa0hK0vAgAB8yACAAF6CUA== Date: Mon, 16 May 2022 21:32:55 +0000 Message-ID: <19b3e040302d4d8aa240eee43427dfaa@AcuMS.aculab.com> References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-21-samitolvanen@google.com> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220516_143303_576746_39756C54 X-CRM114-Status: GOOD ( 31.63 ) 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 From: Sami Tolvanen > Sent: 16 May 2022 17:39 > > 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. Yes, but there are several ways to encode 'cmpl imm,-6(reg)'. Firstly you can use '81 /7 imm32' or '83 /7 imm8' where imm8 is sign extended. (the /7 1/7/index_reg for a signed 8 bit offset). But that only works for the original 32bit registers. For the 64bit r8 to r15 an extra REX prefix is required. That makes the instruction 8 bytes (if it needs a full 32bit immediate). So if the register is %r11 there is an extra REX byte. If the is a hash and happens to be between -128 and 127 then there are three less bytes. So decoding from regs->ip - 0 isn't always going to give you the start of the instruction. > > > > + * 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. Hmmm.... strange function name... > > > > + if (offset < 0) > > > + return; > > > + > > > + *target = *(unsigned long *)((void *)regs + offset); > > > > WTF is that calculating?? > > It's reading the register value from pt_regs. > > Sami David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel