strncpy works perfectly here in all cases, however, it is deprecated and as such we should prefer more robust and less ambiguous string apis.
Let's use `strtomem_pad` as this matches the functionality of `strncpy` and is _not_ deprecated. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: [email protected] Cc: Kees Cook <[email protected]> Signed-off-by: Justin Stitt <[email protected]> --- Changes in v2: - update subject (thanks Kees) - update commit message (thanks Dave) - rebase onto mainline cbf3a2cb156a2c91 - Link to v1: https://lore.kernel.org/r/20230911-strncpy-arch-x86-coco-tdx-tdx-c-v1-1-4b3815572...@google.com --- Note: build-tested Note: Ingo Molnar has some concerns about the comment being out of sync [1] but I believe the comment still has a place as we can still theoretically copy 64 bytes into our destination buffer without a NUL-byte. The extra information about the 65th byte being NUL may serve helpful to future travelers of this code. What do we think? I can drop the comment in a v3 if needed. [1]: https://lore.kernel.org/all/zrc+jqo7xvyhg%[email protected]/ --- arch/x86/coco/tdx/tdx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 1d6b863c42b0..2e1be592c220 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -119,7 +119,7 @@ static void __noreturn tdx_panic(const char *msg) } message; /* VMM assumes '\0' in byte 65, if the message took all 64 bytes */ - strncpy(message.str, msg, 64); + strtomem_pad(message.str, msg, '\0'); args.r8 = message.r8; args.r9 = message.r9; --- base-commit: cbf3a2cb156a2c911d8f38d8247814b4c07f49a2 change-id: 20230911-strncpy-arch-x86-coco-tdx-tdx-c-98b0b966bb8d Best regards, -- Justin Stitt <[email protected]>
