From nobody Mon Nov 11 21:43:26 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 4XnNMk65yBz5cfgB; Mon, 11 Nov 2024 21:43:30 +0000 (UTC) (envelope-from kevans@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 4XnNMk5ZR5z4kRH; Mon, 11 Nov 2024 21:43:30 +0000 (UTC) (envelope-from kevans@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731361410; 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=q8SS/5cvHUVsVeRFl3C2LdDOMNNPnlxqaPF5g5oCpZI=; b=bWgQAaZdKF2Fr7NeGHzo20+Jv9hrNk2KkkTiCC1j0uZ8J0yrqioowS3zA81kmHmzqGa72n BAirljQKbP/HDs7OwWtrqL0jDLBhcZ/6ZjgCXXa3K5efTfcD+QS4M6CY99NUqxj/L4cqD+ /Z2aaYQIds1OvDVbkU2b87hBVkJ/c5EgejXnu3RLwWWA/7ADhYc72gHX62QkpyXwlCIovg BAtrNnyndgSYmTtSSvNg9RnL5495YUth3DEZt5QrjwBBRsBNcidh6oC4pvZ2rHLX/FB2BK gL32Ve91A9m0H3pt+Tn2tA3Me5ns74uFViMQq3rv/7WymKwZKIjzbn9K+7i4gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731361410; 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=q8SS/5cvHUVsVeRFl3C2LdDOMNNPnlxqaPF5g5oCpZI=; b=Un3MNCRCyqMkalGeHYkfDbPzNm1+oM4QT9x6U1l5dxEEP/b4t0HKSFxGcGb4n1yAG70rJi vrtVY9NxMmOkUce62NDsduLHFIbh2yAxlGiLC/p++Bghv1fAy3uC/Fj/JkFMKoSfp+Iahz 83QKJ1Jn50m/2W+sGik+3BiCNt4aE5e17jDTxzgZJItg5De3BONWrRUlkXGHZhDDMoDF/n 4Ni1RQSrX+4BEQ56pzLqjwF/lcyuSRfhvFrVRvHzvGD51/d5FopxUNKCmWtlSZz1HYZ4oU R6o4m/jJmuCsxjdxSAa6LOT9VE256a7qC/ODmWO5ZigAhHo/hfwHfBOBZFl/oA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731361410; a=rsa-sha256; cv=none; b=a7E6zp0T6dmCeA7fgwIHa4LMzgH40OY3WS6ghJ42kWW8tw0LOreimsf9trR8uUQ3Fd9zh1 +EPEXNdBPEZ69dvR7c5RD7zA/tQMN44Fb3Zrv7C8F30gW5JmJghE0x/CTkgaz926lZx/O1 82hpxqiFeiLC0KMtdSov6CI2lQHa63flbivdxvZsz5XnrJD10azc64nFY3V5DTQE607m55 Q9WcrlJ3fpslYA++OZbjWP2xF8MJvobrFl+3ic07mRsk5xi89XmBx8G/bKjfZ2peuH4Yv1 LFSljEusNazwzIepohCHEEgTLaxfsq6cmKfO5YexRI+kLgwrob3MFUHKfNQk0w== Received: from [10.9.4.95] (unknown [209.182.120.176]) (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: kevans/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XnNMj4Nf9zLMN; Mon, 11 Nov 2024 21:43:29 +0000 (UTC) (envelope-from kevans@FreeBSD.org) Message-ID: <1e5d5d2b-9e16-451a-b083-ba26d28e694f@FreeBSD.org> Date: Mon, 11 Nov 2024 15:43:26 -0600 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 To: John Baldwin , 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> Content-Language: en-US From: Kyle Evans In-Reply-To: <84468a78-9906-4275-8220-db5ef9ccff82@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. Thanks, Kyle Evans