From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F1E3284E1C for ; Thu, 28 Nov 2024 11:19:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732792761; cv=none; b=CUo7mqS7Z9ZgH9dReIiR+PJsPvFzSSDb7ERn0zTLcA8qpIXWGVJsLI4k+6Zmr76vSIdo6EVHsn4l+dmne90y6VIHOol8uSUrMeS5AywCBOhv6FrqoWydp1U0THKiXBdYMUBS1/lxLhpPvR1clTZfJhMx8Bu0I218PqmMxmMQhqk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732792761; c=relaxed/simple; bh=pVaDPt3jBufrVN/9PEf6GS7EmJQMzJOkdOqD6bR1+A4=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=k3vUSPbIGsLWHYbWC1gBeB9vLEdlazaLIlfp3f2h4IfoROn/cmXR4b3ssF5lqJlH+dw3ISs8OFzz6bsI+ULIlgkag8m7AJi/JZkpXqFgU84Pd6qGPwshbmXjPqTrvUWITU7aVRKQAmUN6UebO6ZCaLq9QVI6XOfX+TUyfS7VjTk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=WSytyker; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="WSytyker" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1732792756; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type; bh=XWP9CXJXUFmb3o4USwC7RbljHZTHBC/NnWj2SBA0M3g=; b=WSytykerJ0gq7VAgvM8RazVcmxVgjW3ioPw7Zc0gqc6onD1TkBXnhm9o9WzQjFjMmk47Qj JNDSi1c5IKTzrp2pa5PI1BrJL13sjnCarWJJMpQJKjxohhiuIk7vUbS23P2Gi2Mw52cMmn ge88mbyV8QYSA8zRAdPgE1U3HC5WMFo= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-28-OjWH5ftKN52bbxJklwT7cQ-1; Thu, 28 Nov 2024 06:19:15 -0500 X-MC-Unique: OjWH5ftKN52bbxJklwT7cQ-1 X-Mimecast-MFC-AGG-ID: OjWH5ftKN52bbxJklwT7cQ Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 820A91955F3F for ; Thu, 28 Nov 2024 11:19:14 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.225.55]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id F2C6A1955D45 for ; Thu, 28 Nov 2024 11:19:13 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 4ASBJAR43618987 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Thu, 28 Nov 2024 12:19:10 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4ASBJA8A3618986 for linux-toolchains@vger.kernel.org; Thu, 28 Nov 2024 12:19:10 +0100 Date: Thu, 28 Nov 2024 12:19:10 +0100 From: Jakub Jelinek To: linux-toolchains@vger.kernel.org Subject: GCC 15 -fzero-init-padding-bits= option and redzone clobber Message-ID: Reply-To: Jakub Jelinek Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: I6Cgnexu5YnkVvC7a16K8L0Bnf06MgxHl6NUgEoemWU_1732792754 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! This is just a FYI, since today GCC 15 no longer zero initializes padding bits in unions where the standard doesn't require it. So e.g. void foo (void) { union U { int a; long b[64]; }; /* This clears everything including padding bits, required by at least C23 (note, GCC 15 defaults to -std=gnu23) */ union U u = {}; /* This used to clear everything, but only clears v.a in GCC 15 by default. */ union U v = {0}; } If you want to keep the old behavior e.g. for security purposes (the whole union can be copied to user etc.), one can use -fzero-init-padding-bits=unions to restore the GCC 14 and older behavior. And, -fzero-init-padding-bits=all can be used to clear padding bits even in cases where the standard doesn't require them even in structures, e.g. void bar (void) { struct S { char a; int b; }; /* C23 requires padding bits to be cleared here. */ struct S s = {}; /* But not here. -fzero-init-padding-bits=all does that anyway. */ struct S t = { 1, 2 }; } Note, there is also __builtin_clear_padding builtin to clear padding bits already since GCC 11, though it doesn't clear bits in unions unless they are padding bits for all possible members, as it doesn't know which union member is current. Another new feature since today that might be relevant to kernel is the "redzone" inline asm clobber. It can/should be used on inline asm which does or could clobber memory below the stack pointer and so its presence must disable use of redzone (currently on x86_64 and powerpc*), whether because say pushf/pop pair or because the inline asm performs calls without taking into account the red zone (e.g. on x86_64 that would be something like subtracting 128 from %rsp at the start and restoring at the end). In the past I think kernel used some hacks like clobbering rsp, that is something that really shouldn't be used even if it happened to work, inline asm is of course allowed to change the stack pointer temporarily, but before returning (if it returns at all) it needs to restore it back, and clobbers are not about temporary changes during the execution of inline asm, but about changes from the start to the end of inline asm. So asm ("call something" : ... : ... : "redzone"); (of course it likely needs tons of other clobbers for call clobbered registers unless it saves them and restores them in the inline asm or in whatever it calls). Jakub