linux-hardening - Re: [PATCH] x86/tdx: refactor deprecated strncpy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <202309291450.E78582CC@keescook>
Date: Fri, 29 Sep 2023 14:51:01 -0700
From: Kees Cook <keescook@...omium.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Justin Stitt <justinstitt@...gle.com>, linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org,
	Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH] x86/tdx: refactor deprecated strncpy

On Fri, Sep 29, 2023 at 11:14:14PM +0200, Ingo Molnar wrote:
> 
> * Kees Cook <keescook@...omium.org> wrote:
> 
> > On Mon, 11 Sep 2023 18:27:25 +0000, Justin Stitt wrote:
> > > `strncpy` is deprecated and we should prefer more robust string apis.
> > > 
> > > In this case, `message.str` is not expected to be NUL-terminated as it
> > > is simply a buffer of characters residing in a union which allows for
> > > named fields representing 8 bytes each. There is only one caller of
> > > `tdx_panic()` and they use a 59-length string for `msg`:
> > > |	const char *msg = "TD misconfiguration: SEPT_VE_DISABLE attribute must be set.";
> > > 
> > > [...]
> > 
> > This appears to be trivially correct, so I can take it via my tree.
> > 
> > Applied to for-next/hardening, thanks!
> > 
> > [1/1] x86/tdx: refactor deprecated strncpy
> >       https://git.kernel.org/kees/c/e32c46753312
> 
> Please don't apply - Dave had some reservations, plus after the
> change the comment would be now out of sync with the code ...
> 
> Also, we generally carry such patches in the x86 tree.

I've dropped it now. Thanks!

-- 
Kees Cook