From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id AFB573858D32 for ; Fri, 12 Jan 2024 03:02:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AFB573858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AFB573858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705028557; cv=none; b=UOn+pcj9C9IwXnQ+DM/8bppejgukuFE9gvNsJ+DbD5tkUbWD+8pte1Jqa6SNq7xEdYYVOiWGq2OgI6ufHSaLpuiidovV9mISIfGOQHq3wIUc7WgLt1ErJQZ7rCpiSIprHcXvWQ5Fz6JMGVhfBMpFeyacLZvZ74WrH566n/ZcH44= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705028557; c=relaxed/simple; bh=zLe8lLbzxhyN0bG1kOrRkevOCV429EfOLzks/cvw/k4=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=oER4jMorZEDQ0qdIRcQYLhCIwMFmfchGi9LpO+guddPADrBdQkgYdQs7xVGup0DoiP4cPbSJ80SpT2zgYg4pXfhWPxbf5RDMeyBSfwqau8LKT8j+Fl+XW4i+oXaxM8yjXkWoZtWr9o3OSrDF8QOXxOW/7WFeKTEEGgOddJAAqKM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353724.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 40BNuISh000478; Fri, 12 Jan 2024 03:02:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=3vWz+4KQ0p0CcNQ1pE+qQWyiZu0xvdVOAhOBgk0Ar+8=; b=djX66zW+OFB8Oj06eMNEWbk2bORRG+n9Vi2eLIDK5G9iG/AfZkl6tGY1IB6JLBRiAtK4 lGrAQt0wXOb3lGAZZXw47nvTKFesoL9alf0QW3G1PybVu4MKr8o3WxcOV4o7XCVXw11e 7rJINwO0Qk0rrrwyE2G/2rRW+jaYmXWriMR5sf5zHwc5y4KU3+XY5asECx4gCYLq0fbA 3yKiyuclnVxxkUbQt6RgjcqeMVuyUpnC4qe9OA2xGFDUKJ3mzjlaDOE2Bq3cu50jZn1Y q1Eb96PTKYMvJ69s4u4ttEQcNYzF06hGl9GRev/YEUDBAcpqC6V3bCmTkMjajDN1yyjC mA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3vjj70gfbh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jan 2024 03:02:29 +0000 Received: from m0353724.ppops.net (m0353724.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 40C2gI8G002857; Fri, 12 Jan 2024 03:02:29 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3vjj70gfb8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jan 2024 03:02:29 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 40C21OjO028061; Fri, 12 Jan 2024 03:02:28 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3vgwft3jg8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jan 2024 03:02:28 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 40C32Qlv43319982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Jan 2024 03:02:26 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B60992004B; Fri, 12 Jan 2024 03:02:26 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9E32820043; Fri, 12 Jan 2024 03:02:23 +0000 (GMT) Received: from [9.197.242.77] (unknown [9.197.242.77]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 12 Jan 2024 03:02:23 +0000 (GMT) Message-ID: <22ba03be-6c9a-0168-a51e-99c171175aff@linux.ibm.com> Date: Fri, 12 Jan 2024 11:02:22 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] strub: Only unbias stack point for SPARC_STACK_BOUNDARY_HACK [PR113100] Content-Language: en-US To: Alexandre Oliva Cc: GCC Patches , Richard Biener , Jakub Jelinek , Peter Bergner , Segher Boessenkool , Jeff Law , Richard Sandiford , Rainer Orth References: <91d2c107-0168-791b-b5fa-de21c2345f84@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 8vrXMo3z91SUNhnhAMnClh_QRJ9-I5GN X-Proofpoint-ORIG-GUID: vnsP0wTFN6u2tvg2ncyefGEV0K_EhHM3 Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-11_15,2024-01-11_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 lowpriorityscore=0 priorityscore=1501 phishscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 spamscore=0 mlxscore=0 suspectscore=0 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401120020 X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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: Hi Alexandre, on 2024/1/11 17:05, Alexandre Oliva wrote: > On Jan 7, 2024, "Kewen.Lin" wrote: > >> As PR113100 shows, the unbiasing introduced by r14-6737 can >> cause the scrubbing to overrun and screw some critical data >> on stack like saved toc base consequently cause segfault on >> Power. > > Ugh. Sorry about the breakage, and thanks for addressing it during my > absence. Happy GNU Year! :-) > No problem! Happy New Year! :) >> By checking PR112917, IMHO we should keep this unbiasing >> guarded under SPARC_STACK_BOUNDARY_HACK (TARGET_ARCH64 && >> TARGET_STACK_BIAS), similar to some existing code special >> treating SPARC stack bias. > > I'm afraid this change will most certainly regress 32-bit sparc, because > of the large register save area. Oh, I read the comments and commit logs in PR112917, mainly https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112917#{c4,c5,c6}, and the "sparc64" in subject of commit r14-6737 also implies that this unbiasing is only required for sparc64, so I thought it should be safe to guard with SPARC_STACK_BOUNDARY_HACK. CC Rainer (reporter of PR112917), maybe he already noticed if it's regressed or not. > > I had been hesitant to introduce yet another target configuration knob, > but it looks like this is what we're going to have to do to accommodate > all targets. > >> I also expect the culprit commit can >> affect those ports with nonzero STACK_POINTER_OFFSET. > > IMHO it really shouldn't. STACK_POINTER_OFFSET should be the "Offset > from the stack pointer register to the first location at which outgoing > arguments are placed", which suggests to me that no data that the callee > couldn't change should go in the area below (or above) %sp+S_P_O. > > ISTM that PPC sets up a save area between the outgoing args and the Yes, taking 64-bit PowerPC ELF abi 1.9 as example: | Parameter save area (SP + 48) | TOC save area (SP + 40) | link editor doubleword (SP + 32) | compiler doubleword (SP + 24) | LR save area (SP + 16) | CR save area (SP + 8) SP ---> +-- Back chain (SP + 0) https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#STACK 64-bit PowerPC ELF abi v2 drops "link editor doubleword" and "compiler doubleword". PR113100 failures mainly suffer from the TOC saved value changed when it's used for TOC BASE restoring. > stack pointer; I don't think that's very common, but I suppose other > targets that do so would also define STACK_POINTER_OFFSET to nonzero so > as to reserve those bits. But whether they should be cleared by stack > scrubbing, as on sparc, or preserved, as on ppc, depends on the ABI > conventions, so we probably can't help yet another knob :-/ I agree, it really depends on ABI conventions, taking 64-bit PowerPC ELF abi as example, some of them is safe to be scrubbed like "LR save area", some of them depends on if they are used like "TOC save area". It reminds me that even if on somewhere there is no failures with scrubbing them, it doesn't really mean it's always safe to scrub since it's possible that there are no enough testing coverage. For example, back chain gets cleared but no issues would be exposed if there is no test case happening to do some jobs with back chain. From this perspective, excepting for the special need of sparc unbiasing, without examining the specific ABIs, IMHO it's more conservative (not risky) not to scrub this area than scrubbing it? > > I'll take care of that, and update the corresponding documentation. Nice, thanks! Welcome back. :-) BR, Kewen