From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id 5B49B3857437 for ; Wed, 20 Dec 2023 07:51:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B49B3857437 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5B49B3857437 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::32c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703058677; cv=none; b=I+1O1aPmOxf8faEMzVL5swtriWaWzrH5zoorDed0UihPd03QqeKt1bOCKk/mRoFZCt4vSY65KdneC0hfiV9oHTKP1RQKcwcgUeGc6CO6u77FQCHsH5pULDNPdL/+IokPaBmb/VlklM2cMpwGy66miMDbR113fAvNMxH3kZJoZzE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703058677; c=relaxed/simple; bh=wL6xQyb1ogw8FfhBDvmbqHTENvmkrGMMs96RJp8+8gA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=F7/ItBAncuDGK5MH6V/40Plg/8zgfIT9FatAUY9t38GcSXfl5VzoHbtCj3TFoNFdZVY67kfZJAKeoL83HvmW2aE5kNWQB24ZtV76UBCyyIl38i+1D4QQ0oNHnUZetRK/ETL7PRH5Ga525jBOOGYqUjHYvF/Al2ElXW9eI9lactk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-40c41b43e1eso68041865e9.1 for ; Tue, 19 Dec 2023 23:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1703058674; x=1703663474; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=LaF6OrrE3yZmzWf/8u9BlEvAvNBm2Uvl+UOoA+h3Jsg=; b=Pn1rwbxDZoaIuYJbs1p3q0Ypg03oALrqSSsGMvAhObcWPzU81cC/MiQMv9PYsgJXbJ IljmauP/TEUb7J+wOZ2P0Wel0tXbm7j4vtHbBCZ92pDdVFPwq0wxOe+6bHdmPf13iEj3 8QwdpGxaGaCH9y/54pSMII/7/HQe2Yv1+e6EFCM8/2DRoDahNuFKEwQIENBBCltV7sEL NIQUenW5hxJmo4ztQ+oGA4vsqae7B8XdllucJXOp/CzvChnznzTQhzrS63kG6TErRs1O U/zLAbNurCI8usotbjckghpkILDCnqCrXSozwuDd90W9AA5HqCqzl7AMJm7dA9R1QUUL ZERw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703058674; x=1703663474; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LaF6OrrE3yZmzWf/8u9BlEvAvNBm2Uvl+UOoA+h3Jsg=; b=feIrKVav6vqbFnd/vv4yZM1vRJEldGDdYeTtGSH2rWVd/1Lu/b8Kf5PkE1NUaTojkh e9ob0T9U5wglCIOtifmv52IL6l9NJfdo33EoBaKN5KcWLS+pZioeTRu0zZDqhq3sObja GD6Y48WwTja0p4FZY3ruQvrLKCrUlf8Pd81lYzHKG0W2yEMwFvFZrsIOyVwfn2mcoLK8 LKpqkT5Ext75/1aaVPoIV5i4t3dFBAvGc9CjsqVwHPdtUkPQxjyvHPGiy06P/9NysW7V X1ZyhrcDJKhqeBKMce+329pBwp7q2uGNcPsdZtSQGk7UtAG2WOh0tUkZjpD9jrniUSDp Yovg== X-Gm-Message-State: AOJu0YzfifhAHlH+/zpp8leTRmxt6UImcALReJx0K302nyI0ruNU8lBl 0Cv+xmtJ23ZLS8pImHjWJSHT X-Google-Smtp-Source: AGHT+IEfUJes+KRcNy6CMP/G9myKvAdkxDPekdVYxMGV1eIp1r3oPWNe1UMZE2oKie5UYIWncPly2Q== X-Received: by 2002:a7b:c44e:0:b0:408:4120:bad2 with SMTP id l14-20020a7bc44e000000b004084120bad2mr9183355wmi.9.1703058674049; Tue, 19 Dec 2023 23:51:14 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id n7-20020a05600c4f8700b0040b45282f88sm6220774wmq.36.2023.12.19.23.51.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Dec 2023 23:51:13 -0800 (PST) Message-ID: <3fb2f10e-bcb6-4200-8ef4-9b2bde5adb32@suse.com> Date: Wed, 20 Dec 2023 08:51:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH,V3 00/13] Synthesize CFI for hand-written asm Content-Language: en-US To: Indu Bhagat Cc: Nick Clifton , binutils@sourceware.org, "H.J. Lu" References: <20231211060359.3561062-1-indu.bhagat@oracle.com> <6db8b80a-ce1f-4f5d-9c3d-02ae76235903@redhat.com> <852395fc-2cf3-4863-953e-adedddc0c573@oracle.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <852395fc-2cf3-4863-953e-adedddc0c573@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3026.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 19.12.2023 22:02, Indu Bhagat wrote: > On 12/18/23 00:47, Jan Beulich wrote: >> While this is an unusual situation - new very general purpose insns aren't >> introduced frequently -, I'd also like to see more formally addressed the >> idea of ongoing support: From the original review I recall that you need >> to minimally track insns altering GPRs, in order to avoid silently >> generating bad CFI. Remember that I haven't looked at v3 yet, but as long >> as that tracking is based on specific insns rather than a generalized >> pattern, any ISA addition allowing GPRs to be altered would be at risk of >> rendering the CFI generator code stale. Yet people, once they've started >> to detect availability of this functionality, may validly expect that >> their use of the functionality won't silently break behind their backs. In >> this respect, did you consider constraining under what conditions the >> generator code may actually come into play (at least for the time being)? > > (Step 1) I propose that, for now, we add a check such that if any APX > insn is seen for --scfi invocation, we bail out. IIUC, we could check > using the is_any_apx_rex2_encoding (). That would cover only the REX2 subset of additions. The promoted-to-EVEX insns would need covering as well. > (Step 2a) We can remove this check once there is support for all APX > instructions for SCFI. I can add support for ginsns for APX instructions > once the APX work is pushed. > > (Step 2b) Orthogonal to supporting the APX instruction set: For SCFI, it > is ideal to add a way to raise alert if new instructions are added in > the three categories (For APX, I see we have additions in #2, and #3): > > 1. Control flow instructions > We can detect them by checking for insn.tm.opcode_modifier.jump. We may certainly hope that any new control flow insns would also have this attribute set. This reminds me of another guard you may need, though: Use of .byte to hand-craft insns. > 2. Operations altering GPRs > We can detect them by checking for: > if (insn.operands && insn.reg_operands) > { > reg_op = i.op[insn.operands - 1].regs; > if (reg_op) > check if destination reg is REG_SP/REG_FP > } The condition here isn't sufficient (the destination could also be a memory operand), but something along these lines would certainly address one of my fundamental concerns. > 3. Operations with implicit update to stack pointer. > Currently we have no marker, but how about adding something like > unsigned int implicitstackop:1 in i386_opcode_modifier ? We will also > need to ensure this property is correctly conveyed for all existing > instructions in i386-opc.tbl. When new instructions are added, the SCFI > machinery will be able to warn the user of missing functionality (and > not generate wrong CFI). While I'm generally hesitant to see new attributes added, if one's needed for a clear purpose (like looks to be the case here), that's certainly fine. Much will depend on people (at least one of submitter or reviewer) remembering to (ask to) add such an attribute whenever needed. > After this support for #3 is added to the backend, we will be in good > stead for future ISA additions wrt SCFI. > > I can _try_ to accommodate 2b before the 2.42 release is cut. However, I > think its best to plan for both 2a and 2b for 2.43 release (given the > 2.42 is around the corner), if there is agreement. If 2b was properly in place, I could probably be convinced to agree with your work going in ahead of the APX stuff. It's in particular unclear to me in how far APX is really going to make 2.42, considering how much of a change it is, and how hard is has been so far to review the changes. It would nevertheless feel better to me if your work was given some more time, to go in only after 2.42 was branched off. I certainly can't promise I will be able get around to reviewing either SCFI or APX again before the end of the year (more precisely: before the holidays). Jan