From nobody Mon Nov 11 21:54:34 2024 X-Original-To: dev-commits-src-all@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 4XnNcW6W44z5cgMJ; Mon, 11 Nov 2024 21:54:35 +0000 (UTC) (envelope-from jhb@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 4XnNcW5W1Qz4lGF; Mon, 11 Nov 2024 21:54:35 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731362075; h=from:from: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: in-reply-to:in-reply-to:references:references; bh=oEYAJYVUdHx/BHW0G4FmZGXXaTLL5dscDEQZrObmSRA=; b=uPP2jHJsT1myIj7LxDokXuuyORLOBRKzvNWHnFlFki2gm4FzUG4ZlvmDdKtbvU3hTHqUid dQbf+0DfyDWhRbaaTfWMziEI81kIOE7YksuiofJ97lxjHcenQOFVfm3rm3RZxzy9tisRhq ijZGx8pGb+r7Ass/rbns+HUKYYhA1VIOcx84VfVDgk2X1ALeTi3n5YZIcNh9tANxesSoGi 5lRUC0kXxdG0TVKQ7WwHTxYoKr1B61qP/UcOt+ekl+NqotFdUIcqV3la9tm+S078gd9/HC pXs2/hPzb9gixvfcEY6FY9xu8WiZ58Fxzcz+ATfoasPY27a5g3KNuY/N0VZOuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731362075; h=from:from: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: in-reply-to:in-reply-to:references:references; bh=oEYAJYVUdHx/BHW0G4FmZGXXaTLL5dscDEQZrObmSRA=; b=HvyOSLsQ6q5eTfDcJUFrcH1XET7NLyhdFu4cX1VWlbVpapTRy5DeOzz4w201ywO+ykh1R9 LPjaq8FH3ny955+rGqKJVZyTQDO2+1t8eQJK2LU1U4RfcNItV0X7ppdvh5wQNFQDwEs+oR iQ5xaKjx547LsGOpBGxxVCNNfAlCyzK8Bi2LWYcCpLfDweYQUnNgT5mTikvMAmE4nlQsXb VeKhqHawDVjZbSHZ8YR1ogRwNGPAfpJo0AvwQvzf4FTSsPzNgFtdCFwGvGaLw2zJskXzH2 5WcoRK0QTMRpScs+LQ7SE57PYl8XStHeqtb/rD7zNYaP9yREYDeMsx019k7cfQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731362075; a=rsa-sha256; cv=none; b=ya2b8Zl1f+4R4I2qX+g2T1iFlug6Qnf74MkaOoElN4MHrCIMTuPX4JElPOiN34parPL7aT JuB3oGMAAKt5u/cs4lnxYE5d/ERk6laLpYuMXs4ZnNzRt3jszQSal7yu84cosqJyX5UdEO cpNV9ReUKPjNhujb/lfWL9kp66At1JaH4A8FVsZATzREy3L+Afn1uVgKthfNR6dtCjryXp UH/SnDlL5JQ//0qcRyRfDesh5s1bBthjhChrdAyK8e1yUae8iJ4rKZJO9rtf92vWR9Z3bI bMO45g1+YtgioVBMMZPzS9W6btiMukRTBddt9xDBi6a3rZnGNpXIqarLpvtf0A== Received: from [IPV6:2601:5c0:4200:b830:d04f:46f9:caeb:6e94] (unknown [IPv6:2601:5c0:4200:b830:d04f:46f9:caeb:6e94]) (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: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XnNcW3fgMzLMS; Mon, 11 Nov 2024 21:54:35 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <33c76eb5-d0e9-43e8-a7f1-3c1911abdef3@FreeBSD.org> Date: Mon, 11 Nov 2024 16:54:34 -0500 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: cf8e5289a110 - main - include: ssp: round out fortification of current set of headers Content-Language: en-US To: Kyle Evans , src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org References: <202407130523.46D5N0Qh032534@gitrepo.freebsd.org> <84468a78-9906-4275-8220-db5ef9ccff82@FreeBSD.org> <1e5d5d2b-9e16-451a-b083-ba26d28e694f@FreeBSD.org> From: John Baldwin In-Reply-To: <1e5d5d2b-9e16-451a-b083-ba26d28e694f@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/11/24 13:43, Kyle Evans wrote: > On 11/11/24 15:13, John Baldwin wrote: >> On 7/13/24 22:23, Kyle Evans wrote: >>> The branch main has been updated by kevans: >>> >>> URL: >>> https://cgit.FreeBSD.org/src/commit/?id=cf8e5289a110954600f135024d1515a77d0ae34d >>> >>> commit cf8e5289a110954600f135024d1515a77d0ae34d >>> Author:     Kyle Evans >>> AuthorDate: 2024-07-13 05:16:10 +0000 >>> Commit:     Kyle Evans >>> CommitDate: 2024-07-13 05:16:24 +0000 >>> >>>      include: ssp: round out fortification of current set of headers >>>      ssp/ssp.h needed some improvements: >>>       - `len` isn't always a size_t, it may need casted >>>       - In some cases we may want to use a len that isn't specified as a >>>          parameter (e.g., L_ctermid), so __ssp_redirect() should be more >>>          flexible. >>>       - In other cases we may want additional checking, so pull all of >>> the >>>          declaration bits out of __ssp_redirect_raw() so that some >>> functions >>>          can implement the body themselves. >>>      strlcat/strlcpy should be the last of the fortified functions >>> that get >>>      their own __*_chk symbols, and these cases are only done to be >>>      consistent with the rest of the str*() set. >>>      Reviewed by:    markj >>>      Sponsored by:   Klara, Inc. >>>      Sponsored by:   Stormshield >>>      Differential Revision:  https://reviews.freebsd.org/D45679 >> >> For the change in , is the intention for to only >> be included in userspace binaries that use this header for some reason?  As >> it is, there are a handful of files compiled in the kernel that use remove >> -nostdinc from CFLAGS to access intrinsic headers for things like crypto >> instructions and those files end up including all of in the >> kernel, e.g. this from armv8crypto: >> >> # Remove -nostdinc so we can get the intrinsics. >> armv8_crypto_wrap.o: armv8_crypto_wrap.c >>     ${CC} -c ${CFLAGS:C/^-O2$/-O3/:N-nostdinc:N-mgeneral-regs-only} \ >>         -I${SRCTOP}/sys/crypto/armv8 \ >>         ${WERROR} ${PROF} \ >>          -march=armv8-a+crypto ${.IMPSRC} >>     ${CTFCONVERT_CMD} >> >> For CHERI this breaks in an obscure way (which is why I discovered this), >> but I'm curious what the intention is?  Should the kernel always be >> using the fallback definition of __ssp_real? >> > > I think this was meant to address some cross-build issue somewhere in > our bootstrapped stuff; if it was a kernel vs. userspace thing I don't > see why I wouldn't have used _KERNEL instead. The kernel should always > use the stub that just defines it back to the name passed in, though, so > we could definitely add a '&& !defined(_KERNEL)' there. Ok, thanks, that's what I've done locally. I'll throw it into a review in a bit. -- John Baldwin