From nobody Thu Nov 14 12:44:38 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Xq0Gb2H3bz5ccnS for ; Thu, 14 Nov 2024 12:44:39 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xq0Gb1n5lz4JMs for ; Thu, 14 Nov 2024 12:44:39 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731588279; 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: content-transfer-encoding:content-transfer-encoding; bh=rmOwu4poK/CybHhpOcFE0Hd/MmIc3S2gBOeUNjjTcwc=; b=hQ61zn3aprpjxjIEiVMIrel3Jc55cV+7UVzO4bxsog4Ip/SNOzRpZ9teMGMygRcGZYyUEG q5XTuZ+7EECEhRDxz26gSGJXcZvdBPl9dxlvGcaAIq+GoJMbFPOxHARbN5f6IbunbsZU3L wbyBWi2Yd4GprlTHa8NzfOhQTWwn2k74vWo3t91ufT4QgW+mC1kOp5VuQm+Ow3jW5bidFY jxsPRDOm9evyTXd4Z5uM0BMQgn8/nuwQO+FMsfc5l6o1EjXfOfCjbRCayWBEyqH3/kP8cC OmuRyHe4zi7I/XIVbU/rP+Hp1LgLL0yohPxclZfbDOEzruS+OEHvuKGWPdOb2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731588279; 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: content-transfer-encoding:content-transfer-encoding; bh=rmOwu4poK/CybHhpOcFE0Hd/MmIc3S2gBOeUNjjTcwc=; b=UuLZZ6C/9gc+7JtP2nEPHJVprEDC0DtSI/fGSPUNMX62ll1xejBcsiIiZIcqnoJzisNEgA YJbLMO7VibXKRNSrbdvLkrVgJg3rMVS7ipV/pARYcEyeeeypsUcI5ACjxTW8/x9EPo/sim e4gb6N8Jtwl6idMlMnYH8Encj9vrgdcyHk1WAj/Lc7S7FCV8S3/ARoAI9snFHvMmRZW1Mj 8jTbX82oa5hGem0qP+l2aRKZsKPdyE8r2dt2AbZRFA/Qj0HQqhxTYrJtVeY5eweus1A81q 2gqF6CRTceSPDEBDbouvnzhqBnoDxM1mxFm3Q6GIwsiMcWgdRVpSOMw2Ze8ovA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731588279; a=rsa-sha256; cv=none; b=nDP7/+G1GZ3C2aRIp0mWgUpGAKfCprR9QEy73v1CfPCzVEbV8udViHHb4FsltZFwbSVXTV +2La3cEftuxu7C6HsswW4Nkr2MNK9jM4f/O0wkFZ/mrNcKyjRikSZf6jcR3qzD6Qn5g0l8 JaDDITtizAamHciq0vL+AzHVFMrCcp1HfiMEl2nIZ6IONRms2JlXRN+WZRgctKadaFQF+t 6crA8TOCj7T0Pl/07Rn3Z9r7y/WzgaI4dEkGuBlnW/hei4pS80/98E2pKAGGQNdbUghfxE aFHQJdCEEsueAJ12Qcm3DHgzclXjMOB9Hd+cMpY1OwYgw7IKTEie+rMn1R0rqA== Received: from [192.168.168.195] (lety.radiolinkplus.cz [109.205.241.143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Xq0GZ6z0QzgsC for ; Thu, 14 Nov 2024 12:44:38 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: <192a3da4-6765-401a-a669-0359f8ac9487@FreeBSD.org> Date: Thu, 14 Nov 2024 13:44:38 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: mmel@FreeBSD.org Content-Language: cs, en-US To: FreeBSD Current From: Michal Meloun Subject: llvm19 lld issue Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit While searching for the cause of armv7 kernel corruption after updating to llvm19 lld, I came across an interesting problem. - The linker script does not list all generated sections. Specifically, the data sections created by the linker set are not listed. - The linker can place these orphaned sections in any location (OK, with some restrictions). See https://maskray.me/blog/2024-06-02-understanding-orphan-sections. - Creating symbols outside a section is fragile and subject to error; the linker may place an orphaned section between the symbol definition and the following section. We ran into this problem many years ago, see https://github.com/freebsd/freebsd-src/commit/6e764e36da019837d90e3b4b712871ee4442637a. Unfortunately, we didn't fix it completely then, and we have to address the same corruption again. I think we should be strict in this area and use '--orphan-handling=error' for kernel linking. However, I'm not sure we can handle linker sets gracefully. Any comments, contrary opinion or better solution ? Does anyone know how to properly list all linker sets (mainly but not only 'set__set') in linker script and which section is appropriate for them ? .rodata? Thanks, Michal From nobody Thu Nov 14 21:01:29 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XqCHw01gzz5d8lP for ; Thu, 14 Nov 2024 21:01:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XqCHv6h95z4B7w; Thu, 14 Nov 2024 21:01:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731618091; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7zm7kqwaAysCQehSGwi/60Lr26XGWt2c/pwPT9HtTzQ=; b=cUJ5qDSMqfhzsGIPEMOd8t9J5C/tRmGsFihdOufvrOeoS3BDGjTAXAdn2lnWkfnZugtYUN z+sWTeVplRr9sWQCRD3ShXjuJqq4VqQ7jhcVqIjF31D3nGwS3VqDmQLpK8HxjHhHUnzWLe p8P2hPD4nxUfPY5RNDtQUG44N6l5jrrsUXuVHI3DMdd7oEWAahNyQhsm7N8XcOHxYf7xDk McCneErIDtOw0B9HA0J6xUfyyt0CpOt030nRm09bzPLXBwm/b0Sc0dD3qjoslA2SLcxPRI Dz7E4iSTqF4cjhzVrlO4htBTqabbk+5FMgm7bpBhddWO3De+5fz8+EDS63hA0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731618091; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7zm7kqwaAysCQehSGwi/60Lr26XGWt2c/pwPT9HtTzQ=; b=SwwPPazaUq6NJpdFJfeb9IYDF9Tria1xbEnupSeAundLGB3s/lukhGnvcjtnH6etCLJPyl JqrU7ZqTPGJwHM9VQrkAc3jYYwBTp8YxYnkDWwiWAr1XJmQSxf7OZmxl9Z9dV9fjcjUaXr 3I8D/u3QXQ4EGnHv0eUjQyRjE/xIk4vDcm/+36DMtLpMcYJP9Ozbe9nY8jnzaquorudNPn XXrmVV4WkZ2z5WB3XbgaH+4Rx3qVZ0sOSc7dd/43Lh6GR88Mx6IZr6d3hgcZNodQvYjQ1s HbjZeqGCRn959kdyVECPpvgWMQJs7eCqZTiYMmEtC16jMdB3aFfjk+v9QR2XQw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731618091; a=rsa-sha256; cv=none; b=yx8b4EQfFa3AyfNinEg4nHKTUJ9F/FhQNK3DGGyrctSm3dNs8S8tY8D1en/TqUiE4n93PB ceTMemuZP/H/RhJevUWjx8mkBRHI42xFRoFWo3F7jqqCxN6GX1s3IwU7xxr8vh3acSdf5e NXfvGqsUs6K50ZlpcTHUALXyNIT4KbZ0CguoL9uBwc+oeSqpD6yQTRvvVafLkZBF1Eoc6c tL/6MAJCEADlBA1LB6YhFZazd63WpRTZhzj6h4e3L6t7M7ldhOgRlx+lxPH5kA6/H+W9ce l8RZWkdMncPE1uXPTBE1eETaHv4Iyoko+yLvTzQGP6vDIjsylw9gwFe64sQWsQ== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R10" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XqCHv5jw4z16tK; Thu, 14 Nov 2024 21:01:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4A281747C0; Thu, 14 Nov 2024 22:01:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.9\)) Subject: Re: llvm19 lld issue From: Dimitry Andric In-Reply-To: <192a3da4-6765-401a-a669-0359f8ac9487@FreeBSD.org> Date: Thu, 14 Nov 2024 22:01:29 +0100 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <8C24BC41-9782-45C9-AB8B-075943452519@FreeBSD.org> References: <192a3da4-6765-401a-a669-0359f8ac9487@FreeBSD.org> To: "mmel@freebsd.org" X-Mailer: Apple Mail (2.3731.700.6.1.9) On 14 Nov 2024, at 13:44, Michal Meloun wrote: >=20 > While searching for the cause of armv7 kernel corruption after = updating to llvm19 lld, I came across an interesting problem. >=20 > - The linker script does not list all generated sections. = Specifically, the data sections created by the linker set are not = listed. >=20 > - The linker can place these orphaned sections in any location (OK, = with some restrictions). See = https://maskray.me/blog/2024-06-02-understanding-orphan-sections. >=20 > - Creating symbols outside a section is fragile and subject to error; = the linker may place an orphaned section between the symbol definition = and the following section. >=20 > We ran into this problem many years ago, see = https://github.com/freebsd/freebsd-src/commit/6e764e36da019837d90e3b4b7128= 71ee4442637a. Unfortunately, we didn't fix it completely then, and we = have to address the same corruption again. >=20 > I think we should be strict in this area and use = '--orphan-handling=3Derror' for kernel linking. However, I'm not sure we = can handle linker sets gracefully. >=20 > Any comments, contrary opinion or better solution ? Does anyone know = how to properly list all linker sets (mainly but not only = 'set__set') in linker script and which section is appropriate for = them ? .rodata? I tried adding --orphan-handler=3Derror, and on buildkernel (even for = amd64) I get pretty soon: --- all_subdir_accf_data --- ld: error: accf_data.o:(.data) is being placed in '.data' ld: error: accf_data.o:(set_modmetadata_set) is being placed in = 'set_modmetadata_set' ld: error: accf_data.o:(set_sysinit_set) is being placed in = 'set_sysinit_set' ld: error: accf_data.o:(.debug_loc) is being placed in '.debug_loc' ld: error: accf_data.o:(.debug_abbrev) is being placed in = '.debug_abbrev' ld: error: accf_data.o:(.debug_info) is being placed in '.debug_info' ld: error: accf_data.o:(.debug_ranges) is being placed in = '.debug_ranges' ld: error: accf_data.o:(.debug_str) is being placed in '.debug_str' ld: error: accf_data.o:(.comment) is being placed in '.comment' ld: error: accf_data.o:(.debug_frame) is being placed in '.debug_frame' ld: error: accf_data.o:(.debug_line) is being placed in '.debug_line' ld: error: accf_data.o:(.llvm_addrsig) is being placed in = '.llvm_addrsig' ld: error: accf_data.o:(.SUNW_ctf) is being placed in '.SUNW_ctf' ld: error: :(.note.gnu.build-id) is being placed in = '.note.gnu.build-id' ld: error: :(.note.GNU-stack) is being placed in = '.note.GNU-stack' ld: error: :(.symtab) is being placed in '.symtab' ld: error: :(.shstrtab) is being placed in '.shstrtab' ld: error: :(.strtab) is being placed in '.strtab' --- all_subdir_aic7xxx --- --- all_subdir_aic7xxx/ahc --- --- machine --- machine -> /home/dim/src/freebsd/src/sys/amd64/include --- all_subdir_accf_data --- *** [accf_data.ko.full] Error code 1 Not sure if those are all really orphaned, though? -Dimitry From nobody Fri Nov 15 08:40:44 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XqVpl1HkLz5cqxm for ; Fri, 15 Nov 2024 08:40:47 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XqVpl0nvXz49yG; Fri, 15 Nov 2024 08:40:47 +0000 (UTC) (envelope-from mmel@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731660047; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zzSpad+1lSL+TtlRTq3oZjEVAJQPdUOLEkk0amSRfpY=; b=o6ZXhDLbJYRYDhmCXxmrePU6sb9BL48gRD/fOZdzdRATof+H3G2uX3014kVbWDQlKj2fLq x+KTDM9EMfzhI7vV8oUFD3EIOxILTYcW/vvoVU7j8+pCYvdFJavtf7jcngW3/IReWz7mVx y0yYGNc/lvprE4YkyVYxQdnDtQ5DR0Nw5omX6p2S/ts0M3OfwvKTvpQz39VLKsiFdUeZdl J4bvEPGnBnvBrZM29rAPSq+7iHSMSMOUnIw09VrigKAqmDk4IclNaz86kwfpiVcoJ+SZEk CJ8OOwn93HY357uZLmifESGHOOLaPYTQYuXPbt5eXJZrRwh1UfHJKf8B/cWhaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731660047; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zzSpad+1lSL+TtlRTq3oZjEVAJQPdUOLEkk0amSRfpY=; b=wUp2ZF1y52pHI16GYcwlYf/74TukXByPpz9uu7YjwqgGpU1w6o+vYfn1zz++w72W4t09MW HzCcBfdNetAb7VtmpuEXBpreVAfqT0yyoLk1fjzktgTbiMVBqGj60ZIIlP3pLCeH5Ivylx jg+oCWYeReMrja9fMpegwJvc+zl3ujb1iSpTO/vt/+WSaf0UY8rsfnjT+f1/px6jJ+FZSS PHelfi1A9Hv+wIdlgcGcO5e56hPzfnJvs69tEgkGFTXI0qtYsRT7LVoYr398CPFxvM4kJc sTwU/GNWv9uaCHWYpouTHX/9rEFiLl4pSA2GnDPqzQiZVBf+g5BCl6gEoFjQ6Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731660047; a=rsa-sha256; cv=none; b=LO2zs78EJUspFNwuqyKr4Y+K+CP8433IT0UL5RDmuFvFTzjfhwgUckMGQ+zK1SPE9tpnG7 hMZXaVUEckZUqIz1bZdll4EmSn5XdD15W1Vm1kqlVMrHI0xSvVkAt6mIQ7QPEI3zQVQhnP qA1eUmgNPY+78h14zOBercGLnMXNVo208WqTtFfaNEvx05Rl2AjbeXOzWFAYvo5ni52E97 +Z9xV4ayroqw6/yEh1WHjZ4ENemnlEutlKElvK+6+7VCWii0TfdzJqM7sm41oxXl2UUDXR 3HgTWuIFmMyu79FvB37R0GLpPq4AbSICEak79FqW0T4b3Nm6cK+YcbDltpFP6w== Received: from [192.168.168.195] (internet-251.radiolinkplus.cz [109.205.241.251]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: mmel/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XqVpk2cLVz1M30; Fri, 15 Nov 2024 08:40:45 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Message-ID: Date: Fri, 15 Nov 2024 09:40:44 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: "mmel@freebsd.org" Reply-To: mmel@FreeBSD.org Subject: Re: llvm19 lld issue To: Dimitry Andric Cc: FreeBSD Current References: <192a3da4-6765-401a-a669-0359f8ac9487@FreeBSD.org> <8C24BC41-9782-45C9-AB8B-075943452519@FreeBSD.org> Content-Language: cs, en-US In-Reply-To: <8C24BC41-9782-45C9-AB8B-075943452519@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 14.11.2024 22:01, Dimitry Andric wrote: > On 14 Nov 2024, at 13:44, Michal Meloun wrote: >> >> While searching for the cause of armv7 kernel corruption after updating to llvm19 lld, I came across an interesting problem. >> >> - The linker script does not list all generated sections. Specifically, the data sections created by the linker set are not listed. >> >> - The linker can place these orphaned sections in any location (OK, with some restrictions). See https://maskray.me/blog/2024-06-02-understanding-orphan-sections. >> >> - Creating symbols outside a section is fragile and subject to error; the linker may place an orphaned section between the symbol definition and the following section. >> >> We ran into this problem many years ago, see https://github.com/freebsd/freebsd-src/commit/6e764e36da019837d90e3b4b712871ee4442637a. Unfortunately, we didn't fix it completely then, and we have to address the same corruption again. >> >> I think we should be strict in this area and use '--orphan-handling=error' for kernel linking. However, I'm not sure we can handle linker sets gracefully. >> >> Any comments, contrary opinion or better solution ? Does anyone know how to properly list all linker sets (mainly but not only 'set__set') in linker script and which section is appropriate for them ? .rodata? > > I tried adding --orphan-handler=error, and on buildkernel (even for amd64) I get pretty soon: > > --- all_subdir_accf_data --- > ld: error: accf_data.o:(.data) is being placed in '.data' > ld: error: accf_data.o:(set_modmetadata_set) is being placed in 'set_modmetadata_set' > ld: error: accf_data.o:(set_sysinit_set) is being placed in 'set_sysinit_set' > ld: error: accf_data.o:(.debug_loc) is being placed in '.debug_loc' > ld: error: accf_data.o:(.debug_abbrev) is being placed in '.debug_abbrev' > ld: error: accf_data.o:(.debug_info) is being placed in '.debug_info' > ld: error: accf_data.o:(.debug_ranges) is being placed in '.debug_ranges' > ld: error: accf_data.o:(.debug_str) is being placed in '.debug_str' > ld: error: accf_data.o:(.comment) is being placed in '.comment' > ld: error: accf_data.o:(.debug_frame) is being placed in '.debug_frame' > ld: error: accf_data.o:(.debug_line) is being placed in '.debug_line' > ld: error: accf_data.o:(.llvm_addrsig) is being placed in '.llvm_addrsig' > ld: error: accf_data.o:(.SUNW_ctf) is being placed in '.SUNW_ctf' > ld: error: :(.note.gnu.build-id) is being placed in '.note.gnu.build-id' > ld: error: :(.note.GNU-stack) is being placed in '.note.GNU-stack' > ld: error: :(.symtab) is being placed in '.symtab' > ld: error: :(.shstrtab) is being placed in '.shstrtab' > ld: error: :(.strtab) is being placed in '.strtab' > --- all_subdir_aic7xxx --- > --- all_subdir_aic7xxx/ahc --- > --- machine --- > machine -> /home/dim/src/freebsd/src/sys/amd64/include > --- all_subdir_accf_data --- > *** [accf_data.ko.full] Error code 1 > > > Not sure if those are all really orphaned, though? > > -Dimitry > Most of them are not orphaned and I think they should be explicitly placed. Annoying as it is, we should probably keep a list of sections used in the kernel (one is sufficient for all architectures) and include it in the ldscripts for a particular arches(it's about 24 lines now). After discussion with jrtc27 (thanks a lot for your patience), I think we have only three options besides explicitly listing all kernel sections: 1) Leave the ldscripts as they are, but prefix each _start symbol with a guard, i.e. explicit assignment to location counter ( '.=.' or ALIGN()). 2) Move all _start/end symbols defined outside to the appropriate sections 3) Add the linker '--orphan-handling=error' and declare/discard all compiler-generated sections. I definitely don't like option 1. It's too fragile and depends on not very defined linker behavior. Option 2 is easy and robust, and with the explicit placement of all kernel sections seems sufficient. In my best opinion, we can combine options 2 and 3 to get the most robust solution. Another problem is that an explicit list of kernel sections could probably make modules outside the tree interact badly with linker script. What was your preference? Michal From nobody Sat Nov 16 01:00:17 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XqwY96vnkz5cXqV; Sat, 16 Nov 2024 01:00:29 +0000 (UTC) (envelope-from stefan.k.dimitrov@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XqwY924ynz46Rm; Sat, 16 Nov 2024 01:00:29 +0000 (UTC) (envelope-from stefan.k.dimitrov@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=REC7zgzh; spf=pass (mx1.freebsd.org: domain of stefan.k.dimitrov@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=stefan.k.dimitrov@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5cb15b84544so139280a12.2; Fri, 15 Nov 2024 17:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731718828; x=1732323628; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q2KuAhy3unZTFGCjyiYLSKSjEwxFPAUOY3ibx/ul3Vk=; b=REC7zgzhIvi+hjQTILLTD+Pw9BPP8/Az0gXPStR8JhaYAWdE9nkDUN0QYxrAvtmaBw 8RKnSHz2rEdR8uYwLEuPvrrtBu1MLqAOuft8mD/r82bikeH+Vu25uMBOREw407yIc2ig TF8ZWkjtbW5SKOAVN7u8MNT+xn9J5DVaeuvVThBABj/6FSFjsngqw1oVHnXpa1iVE0T2 0o7ou6PsvZz2FZtfLzL33HoTMwofhd4MBxbQMVE+GXGsDjzpV4CUjf7+Ssav+KlCbIhc CT90PVG5Ammhg51CKvPrMqmci38NTRFcBRIVbmC2LYwui+RIQ8PiWbztQuLDhfm8uF16 oSCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731718828; x=1732323628; h=content-transfer-encoding:cc:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Q2KuAhy3unZTFGCjyiYLSKSjEwxFPAUOY3ibx/ul3Vk=; b=A2lSW3+IkrKAXYpI115bhgWDcKtIlTg6RMsBbE8CXDQAphgTJS6ntyvkwOOqo3m3I7 nBHchal+OPn61Kqp6djM3iuvFKjHkLya5wWPo7ndBZEJmixYh2qwJQeRP4sqe6gODGxm Os0oP++HsJgxTrQ3jLzh3iExcrEvLvZgSnF2OTdAJx5N7NQ3Hy2XKMrQQHX+VIEYp6bl 029tmJLUQm0g82dPsTasXIx/agv5eJsW8NRFqj1/xAgsXQMa72sxoOhgYJyzQtqS7S/c wrnUyPOunzhC/Cq7QUdrU+pdyAlq7zty/70Hld41DE4rGD/B2i48oNTno2RFOJ8JCaWa gKcg== X-Gm-Message-State: AOJu0Yx4XP+am6H/7JHA6jAl9d1T+EkACD8afM6WfGfxSUpPI40zwxAO 4m/32XqZ55VCSAph5K+dzqn3zi7jSgG4WKZGOTMzNjeB/LWsWeThEajP9xRYpTbLAd03OhdBHUy xVJIXCgIkpxd9GNuze/4n9lF1F+B44iC8prQ= X-Google-Smtp-Source: AGHT+IEYZ5RUbBPqhIllldmrL3UOGiLhU4s2JJR2KS0ZgMzOH0TSvsLR9fU7VuBqytcSLsdvaTtndYqbA4jbR36DX7U= X-Received: by 2002:a17:907:944f:b0:a9e:e1a5:9746 with SMTP id a640c23a62f3a-aa48347dba6mr305904966b.34.1731718827935; Fri, 15 Nov 2024 17:00:27 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 From: Stefan Dimitrov Date: Sat, 16 Nov 2024 03:00:17 +0200 Message-ID: Subject: Re: New driver for Asus Xonar DG/DGX soundcards now available To: freebsd-multimedia@freebsd.org Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.74 / 15.00]; FAKE_REPLY(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.74)[-0.740]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org,freebsd-current@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from] X-Rspamd-Queue-Id: 4XqwY924ynz46Rm X-Spamd-Bar: -- has anyone kept a copy of the driver code by any chance? the website is down, Archive.org has a copy of the webpage itself, but it didn't archive the tarball with the driver. IMHO, it's a (big) loss, because it's the only FreeBSD driver for C-Media CMI878x, that at least I can find, that supports Multichannel playback. On Mon, Sep 30, 2019 at 10:43=E2=80=AFPM Alexei Palyutin wro= te: > > Good day everyone! > > Driver for Asus Xonar DG/DGX soundcards is now available on my home page. > > Features are playback, recording (up to 192 kHz both directions), playbac= k up to 6 channels, spdif, volume controls, ACPI. > > If someone is interested - download it, test, and share results. > > Again, I hope this work was done for a reason and will be useful to someo= ne else. > > Driver page: https://sndbro.ru/soft/snd_xonardg?lang=3Den > > -- > Alexei Palyutin > _______________________________________________ > freebsd-multimedia@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-multimedia > To unsubscribe, send any mail to "freebsd-multimedia-unsubscribe@freebsd.= org" From nobody Sun Nov 17 15:30:34 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Xrw3n00qGz5d2vY for ; Sun, 17 Nov 2024 15:41:57 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xrw3l6CcXz4Tdl for ; Sun, 17 Nov 2024 15:41:55 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b="hP+E/+Nf"; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net; dmarc=pass (policy=quarantine) header.from=leidinger.net List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1731858107; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=T34goCIAiOsisHAI2eGKZ/wVvCLWi5U5+3TJX6z/QR0=; b=hP+E/+Nfk+RH9lROlTl7Z86NSbPtTDYL+bGXlnzTtgh1pp7nIph0xSWBFh0Q14Y1v25ggz yp4Lg7FuTogbKarVmc7qPF8mT+WXrGjiXCrdZQwB91fPbmzVIYL4BCw+OgyEjJOzic4/ED WYJRinI7g4prE7TR7Wkyz1XsDwdeP1s9vb0U3SK7MB/PNrU8KiS5yIvg90Xtjd0Je91suj wwYNoVHZR38tGXQsBUZV8+YSWF7DS++v+U+IbqPqV7Pku0xb+29UI4Vhvv5E9wAx1hg1JL SuJBquj3+Jdx1BSqljbxkq9ST8NuN0z8wRVg4Egs9yo15M0f5HDWqbgn0Akm+w== Date: Sun, 17 Nov 2024 16:30:34 +0100 From: Alexander Leidinger To: Current FreeBSD Subject: Playing around with security hardening compiler flags Message-ID: <01a4b49d43860c30e480ec7cf5bd08f9@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_8a2c56e7a664655d96511974de246ef1"; micalg=pgp-sha256 X-Spamd-Result: default: False [-6.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4Xrw3l6CcXz4Tdl X-Spamd-Bar: ------ This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_8a2c56e7a664655d96511974de246ef1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, after reading https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html https://libcxx.llvm.org/Hardening.html https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html I played around a bit with some of the flags there (in CFLAGS). What doesn't work: - -fstrict-flex-arrays=3 (variable array issue in IIRC a tool for ath) - -fstrict-flex-arrays=2 (issue in another area, haven't checked further) What works and results in a world+kernel which is able to boot: - -D_GLIBCXX_ASSERTIONS - -fstrict-flex-arrays=1 - -fstack-clash-protection - -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE Does someone has any reason / argument why some of those shouldn't be used when building FreeBSD? Should something like this be optional, and if yes, enabled by default, or disabled by default? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_8a2c56e7a664655d96511974de246ef1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmc6DCoACgkQEg2wmwP4 2IbwtRAAjL1lgKhYzKCNy/bYE4V/PcncUtziZexqmrldPRDHBnsWsCuyRBJQZpgq Gcc9JkER8io9XsckV65zZh83X2uL7Zit2XvaYPvjyUmzjFrZkp268uhp3H2fSgsK njcgEh4HIEXgMxtUrPbun+jhHi/FjLmua0hALx4YDcxb/EGfTBNTlZT/PHi9DcXT 2REz6OVKBDXA4dsHVdqvZ/S5f9OvoP6/PucgYYpvaD5g1WWuKR0fdx73Bs72bFzt G8QrQSPn4rqBeI6zGVZKiGirdSNa9iS3RZUDndSXiK14y5uJpVuOvJu3pMtH4wdA DRX4s1eo6lZKvVA7NWjc62wMO2tPZ6Ye7M4G+wmbvKVazZxQrB3y3BlPV1H4G38x M2b0nEgEBKKuG0t3AScYbgpNN5gIWavhoQFINllKdyPxD45et+V2aDHRI/nfV868 0oskfwH3i+omznkOkw3vVR4eMJnHAxxgIwD1rwlYdD/gXVkT/IaOMGbqUcjEyOpx 6mG7FUnNxLYOq4LDoI/eS3vnoRlv1CrLXtsR0n6akvHMabiY+jFnb6EJyibdXejI WRqjRN0MySMTg0Jy5Bmh+xpEaD8H3daDEewycLmgTKnXzGhA9UCuZASVhqtd9rJ7 HrjHZkQ56+5XHtRjYSUTj+VZ5w2z4txG5s9Icn95j42FEnc4qG8= =1sRY -----END PGP SIGNATURE----- --=_8a2c56e7a664655d96511974de246ef1-- From nobody Sun Nov 17 18:28:50 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XrzmV36wpz5dFLr for ; Sun, 17 Nov 2024 18:28:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XrzmV2ZN3z4pX9; Sun, 17 Nov 2024 18:28:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731868138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6FbOtT7iES6zDO3HU+j0ukmviCfZJbxCW5AEbkYKspg=; b=WAVvQt1Rat2jV0Fk4Rwz8l0xMEpr1Cliu28upsJifZoDuZBbqSYeKiCryDKAT0VthqzKQc exSEveSzcc9avbOHOYyRBAGfDZHzY+/FZ/rlHT3N/au8dlK2cz9STLakowuG+Dhu9kH6X9 6ZGQMi8AC9DuMRRgslMf38s3ox8Xiqohc5Q+TndlI1KBVxXmszxJLK04Zr87wVe8pSoUTM Hg5e5TJnTqbxuWjg+S3K+YtMFo8xsIdGBdt/IlGq2RNwlxT3SVvntIci738oBcVZB/rAVF YJkRXnR8nAKRRBq8K89IPs/0pmRy9gNXHkRAqk4ezlIb+ksLA+N4xS7cukZ1rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731868138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6FbOtT7iES6zDO3HU+j0ukmviCfZJbxCW5AEbkYKspg=; b=b1VIifUQoDEUtBgFQO6yhAmGzHY74XDWtxfSOKWgLG1m+GAGg95DoUH166LxcCp5qHTxpI Aivz50B9eHk2+pm6gZ/0NwwIh2GS0sMl3mvWpl3vKYmGRJ1aET7CuCbEKDnOteI9lOzHiy xwhnlSCE+NWXEvfPJn1H01smubB4gN+M3yIwxYWW2MIHDfodFkWO2NNB1xcNaplZweFQuI z/oyZKGbVNKjvOFac20j9aqwB+f2w07dijLykCl+D8KrorpWHQDQbiyB892ieZ79RjLJdX rp/xfaOd3n58Pg4/gEmMW8cwKYV0cI0JqYZACuPap2UX0qL07/fGZoVCw+ADpw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731868138; a=rsa-sha256; cv=none; b=Z7EThZtAvE/rhR39JUh3r3Y3PRXCm7avBTkAZ6iTyjhq8z0C6djIDEKIKPHO4IlMsJijw8 MKdxTJUNOpQlgculnpBCB81RrfdVG9bDdw1S1hYfcztl7s+veRsLmOyET9gBTgIzLSpTm3 BhwntjW5vzVjP5Zow4MY8ii5infASI+Uc5fTM82Gy8M9xazl+3J0TjS8bQ3n91FH74X1ly eiE2wqI9NqCvMWfKLiC50NFJk9xr/GpCyc5BVJFrqseJBuQYWO23GQ+GcHtpZ3CVct8JLp QlB3Qo0T8DsffirOcxnveT7aT27VAP4DM7LSMp6yZKAllnvfYuVSxIzLP1IZ2Q== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R10" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XrzmV1F65zMhT; Sun, 17 Nov 2024 18:28:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 12F272254C; Sun, 17 Nov 2024 19:28:57 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_48F44590-745D-4D44-A0DD-3C10301B2E8B"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.9\)) Subject: Re: Playing around with security hardening compiler flags From: Dimitry Andric In-Reply-To: <01a4b49d43860c30e480ec7cf5bd08f9@Leidinger.net> Date: Sun, 17 Nov 2024 19:28:50 +0100 Cc: Current FreeBSD Message-Id: <812A3C4D-35FA-4F98-B279-F550D3296C12@FreeBSD.org> References: <01a4b49d43860c30e480ec7cf5bd08f9@Leidinger.net> To: Alexander Leidinger X-Mailer: Apple Mail (2.3731.700.6.1.9) --Apple-Mail=_48F44590-745D-4D44-A0DD-3C10301B2E8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Nov 2024, at 16:30, Alexander Leidinger = wrote: >=20 > Hi, >=20 > after reading > = https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hun= dreds.html > https://libcxx.llvm.org/Hardening.html > = https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Harden= ing-Guide-for-C-and-C++.html > I played around a bit with some of the flags there (in CFLAGS). >=20 > What doesn't work: > - -fstrict-flex-arrays=3D3 (variable array issue in IIRC a tool for = ath) > - -fstrict-flex-arrays=3D2 (issue in another area, haven't checked = further) >=20 > What works and results in a world+kernel which is able to boot: > - -D_GLIBCXX_ASSERTIONS > - -fstrict-flex-arrays=3D1 > - -fstack-clash-protection > - -D_LIBCPP_HARDENING_MODE=3D_LIBCPP_HARDENING_MODE_EXTENSIVE FWIW the default hardening mode for libc++ is already extensive. There = is also a debug mode, but that is not suitable for general use. I have = not yet considered any WITH/WITHOUT options to fiddle with this, since = it is an option with 4 possible values: none, fast, extensive, and = debug. _GLIBCXX_ASSERTIONS is a similar directive for libstdc++, so it won't = make much difference for the base system, but it could be good for some = ports. (Not sure about the overhead though.) I am unsure about the usefulness of -fstrict-flex-arrays, I have not = really played with this option. I would expect more warnings to come = out? Last but not least, -fstack-clash-protection might be useful, but I = think it might need some additional runtime support? E.g. in libc? -Dimitry --Apple-Mail=_48F44590-745D-4D44-A0DD-3C10301B2E8B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCZzo14gAKCRCwXqMKLiCW ows9AJ0daLhHhB0A5u1J5MyChziaFEWz/gCguyzVOpjfONIG2aP/kj5NO3eZPtA= =X4nm -----END PGP SIGNATURE----- --Apple-Mail=_48F44590-745D-4D44-A0DD-3C10301B2E8B-- From nobody Sun Nov 17 19:11:15 2024 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Xs0kR1b5Cz5dHcC for ; Sun, 17 Nov 2024 19:12:15 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "E6" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Xs0kQ5vVyz4vcR; Sun, 17 Nov 2024 19:12:14 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; none List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1731870725; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Lk0ZvJTcVB/O8BJUJi7rerwwjRzBhKmjH6wJfWw9Yl8=; b=kpDB8HDWwta2pO0itJL6S4X07NLenxnBqUaH+AjNoT2peTPEn/awUEqoPsjf29fGpTGU6W Y6FIntjIypglTRccKuppLgMEqSD6ZyDb+TOXAEamOpCw9j+3BrYh1f4maUsG2xE5xTqUXi HLAZV+yhY7YSH63JofPo6LgberCvQstC+3a8/CRGuRwy7yZBM5Nmw6LocMTKn2lQqMK+Pl nKNiLO4MlrhD0VeSjhoAb0NMup82OwX6rkbK3uvZEJ4B0FzcsMoCbO2HRenljz6bTVZPgX OFUVJK+iDg9y2GevZG01bxg+UdVPzaEtDvNwHKKH6TktZnHwnj11Tu5W1hVcBg== Date: Sun, 17 Nov 2024 20:11:15 +0100 From: Alexander Leidinger To: Dimitry Andric Cc: Current FreeBSD Subject: Re: Playing around with security hardening compiler flags In-Reply-To: <812A3C4D-35FA-4F98-B279-F550D3296C12@FreeBSD.org> References: <01a4b49d43860c30e480ec7cf5bd08f9@Leidinger.net> <812A3C4D-35FA-4F98-B279-F550D3296C12@FreeBSD.org> Message-ID: Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_f63264dc3e6605e398929c29d0ddc7a9"; micalg=pgp-sha256 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Queue-Id: 4Xs0kQ5vVyz4vcR X-Spamd-Bar: ---- This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_f63264dc3e6605e398929c29d0ddc7a9 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Am 2024-11-17 19:28, schrieb Dimitry Andric: > On 17 Nov 2024, at 16:30, Alexander Leidinger > wrote: >> >> Hi, >> >> after reading >> >> https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html >> https://libcxx.llvm.org/Hardening.html >> >> https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html >> I played around a bit with some of the flags there (in CFLAGS). >> >> What doesn't work: >> - -fstrict-flex-arrays=3 (variable array issue in IIRC a tool for >> ath) >> - -fstrict-flex-arrays=2 (issue in another area, haven't checked >> further) >> >> What works and results in a world+kernel which is able to boot: >> - -D_GLIBCXX_ASSERTIONS >> - -fstrict-flex-arrays=1 >> - -fstack-clash-protection >> - -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE > > FWIW the default hardening mode for libc++ is already extensive. There > is also a debug mode, but that is not suitable for general use. I have > not yet considered any WITH/WITHOUT options to fiddle with this, since > it is an option with 4 possible values: none, fast, extensive, and > debug. Great, personally I don't need more. > _GLIBCXX_ASSERTIONS is a similar directive for libstdc++, so it won't > make much difference for the base system, but it could be good for some > ports. (Not sure about the overhead though.) > > I am unsure about the usefulness of -fstrict-flex-arrays, I have not > really played with this option. I would expect more warnings to come > out? From the 3rd link above: ---snip--- By default, GCC and Clang treat all trailing arrays (arrays that are placed as the last member or a structure) as flexible-sized arrays, regardless of declared size for the purposes of __builtin_object_size() calculations used by _FORTIFY_SOURCE60. This disables various bounds checks that do not always need to be disabled. [...] In this guide we recommend using the standard C99 flexible array notation [] instead of non-standard [0] or misleading [1], and then using -fstrict-flex-arrays=3 to improve bounds checking in such cases. In this case, code that uses [0] for a flexible array will need to be modified to use [] instead. Code that uses [1] for a flexible arrays needs to be modified to use [] and also extensively modified to eliminate off-by-one errors. Using [1] is not just misleading64, it’s error-prone; beware that existing code using [1] to indicate a flexible array may currently have off-by-one errors65. Once in place, bounds-checking can occur in arrays with fixed declared sizes at the end of a struct. In addition, the source code unambiguously indicates, in a standard way, the cases where a flexible array is in use. There is normally no significant performance trade-off for this option (once any necessary changes have been made). ---snip--- Compiler Flag Supported since Description -fstrict-flex-arrays=3 GCC 13.0.0 Clang 16.0.0 Consider trailing array (at the end of struct) as flexible array only if declared as [] -fstrict-flex-arrays=2 GCC 13.0.0 Clang 15.0.0 Consider trailing array as a flexible array only if declared as [], or [0] -fstrict-flex-arrays=1 GCC 13.0.0 Clang 15.0.0 Consider trailing array as a flexible array only if declared as [], [0], or [1] -fstrict-flex-arrays=0 GCC 13.0.0 Clang 15.0.0 Consider any trailing array (at the end of a struct) a flexible array (the default) We fail to build with =3 (with IIRC failure to access array[0]) and =2 (with IIRC failure to access array[3]), but the build works with =1. So I expect a few more checks to be enabled than with the default of =0. Ideally we may want to get up to =3. > Last but not least, -fstack-clash-protection might be useful, but I > think it might need some additional runtime support? E.g. in libc? Just from reading what is written in the 3rd link above about it, it may be more a question if the correct runtime value for our stack gap is compiled in (or the right sysctl is used to query it at runtime during a compiler run), than libc support. I quickly gobbled-up this (tabs are probably mis-converted to spaces during copy&paste of the diff here): ---snip--- diff --git share/mk/bsd.sys.mk share/mk/bsd.sys.mk index 63774e85716..cc13b5ccc46 100644 --- share/mk/bsd.sys.mk +++ share/mk/bsd.sys.mk @@ -304,12 +304,12 @@ CXXFLAGS.clang+= -Wno-c++11-extensions FORTIFY_SOURCE?= 0 .if ${MK_SSP} != "no" # Don't use -Wstack-protector as it breaks world with -Werror. -SSP_CFLAGS?= -fstack-protector-strong +SSP_CFLAGS?= -fstack-protector-strong -fstack-clash-protection CFLAGS+= ${SSP_CFLAGS} .endif # SSP .if ${FORTIFY_SOURCE} > 0 -CFLAGS+= -D_FORTIFY_SOURCE=${FORTIFY_SOURCE} -CXXFLAGS+= -D_FORTIFY_SOURCE=${FORTIFY_SOURCE} +CFLAGS+= -D_FORTIFY_SOURCE=${FORTIFY_SOURCE} -fstrict-flex-arrays=1 +CXXFLAGS+= -D_FORTIFY_SOURCE=${FORTIFY_SOURCE} -D_GLIBCXX_ASSERTIONS -fstrict-flex-arrays=1 .endif # Additional flags passed in CFLAGS and CXXFLAGS when MK_DEBUG_FILES is ---snip--- As we don't have the gcc libstdc++ in the tree, it may be debatable if it needed to enable those assertions, but given the interest in IIRC hackers@ about libstd++ and libc++ it may not be that faaaaar off. Any opinions? More discussion here, or rather opening a review for it? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_f63264dc3e6605e398929c29d0ddc7a9 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmc6P+MACgkQEg2wmwP4 2IbuOQ/+NGshnIusUFp0RMcC/GrL/W8oPLMpIuFdy8iFPnJh3ajzia48NrSXFHNa znejorsWoAKM4i1i/TM+YeMNEML/YLctU0FwWhaPtflfSRlF4yS0+uf3e7mN4r1b iDSFhejzxhLfppN/AhABANxS1LqCJhJ6m4eXDW7DW2ojVyxDw0BQUMPZs6XEKgdv 12fjaZwGL4gsjD0bUZzUoECQ8qT6JZZv8HxqQzpTCfTrIQB0PYN4MKmjaV6RO+xS dMGA2haDSV8Wkd3X1lXTjzL8ZIeDUA2hKOTf8N5hOOVunzxOkooxWkE17Eocf7gf 7bOju98f+4iAlLh9bIWOyNRAZHlegn/WTsS4aKPF4TbAMuibYkLAlm1ntcbuo0Ko gzQpXLcGvJrGy36uAE1kLwcB4gIAQuEQfrHV84KZnsmXj4pVuXM9ctvdcIDSnrV4 1lJL5iGiqZ42eJxyOzQFNMUu5zdhFJ1H+Cd91iPjdNE5yEHvzY8rhzzNnHXIM3iT BHag/Cq2n5KqNSOPPUBI+N4SVYZpOP2E5h8mZxDlEzQBR6Xgs6IW+d4hQE54P6WC XgDDTkcWVIpwYTvt8kuXj4ZELizAQoGa1PT7+Tv7o8nXgYCUJGsMJsbiXfuibji+ Gf++cPn9kk3+n0sFl6ToWJzNxE133WnaXlISCdaF6DLZVkLof7Q= =tXaT -----END PGP SIGNATURE----- --=_f63264dc3e6605e398929c29d0ddc7a9--