From: Michael Mueller <mimu@linux.ibm.com>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Janosch Frank" <frankja@linux.ibm.com>,
"Claudio Imbrenda" <imbrenda@linux.ibm.com>,
"David Hildenbrand" <david@redhat.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Sven Schnelle" <svens@linux.ibm.com>
Cc: kvm@vger.kernel.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] KVM: s390: Don't use %pK through debug printing
Date: Tue, 25 Feb 2025 13:56:09 +0100 [thread overview]
Message-ID: <5ac2dda6-a9ac-449a-bb7c-0f9eb90614f5@linux.ibm.com> (raw)
In-Reply-To: <20250217-restricted-pointers-s390-v1-2-0e4ace75d8aa@linutronix.de>
On 17.02.25 14:13, Thomas Weißschuh wrote:
> Restricted pointers ("%pK") are only meant to be used when directly
> printing to a file from task context.
> Otherwise it can unintentionally expose security sensitive,
> raw pointer values.
>
> Use regular pointer formatting instead.
>
> Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
I sucessfully ran our test suite after applying this patch.
Reviewed-by: Michael Mueller <mimu@linux.ibm.com>
Tested-by: Michael Mueller <mimu@linux.ibm.com>
> ---
> arch/s390/kvm/intercept.c | 2 +-
> arch/s390/kvm/interrupt.c | 8 ++++----
> arch/s390/kvm/kvm-s390.c | 10 +++++-----
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
> index 610dd44a948b22945b0a35b760ded64bd44ef7cb..a06a000f196ce0066bfd21b0d914492a1796819a 100644
> --- a/arch/s390/kvm/intercept.c
> +++ b/arch/s390/kvm/intercept.c
> @@ -95,7 +95,7 @@ static int handle_validity(struct kvm_vcpu *vcpu)
>
> vcpu->stat.exit_validity++;
> trace_kvm_s390_intercept_validity(vcpu, viwhy);
> - KVM_EVENT(3, "validity intercept 0x%x for pid %u (kvm 0x%pK)", viwhy,
> + KVM_EVENT(3, "validity intercept 0x%x for pid %u (kvm 0x%p)", viwhy,
> current->pid, vcpu->kvm);
>
> /* do not warn on invalid runtime instrumentation mode */
> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> index 07ff0e10cb7f5c0294bf85f1d65d1eb124698705..c0558f05400732b2fe6911c1ef58f86b62364770 100644
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
> @@ -3161,7 +3161,7 @@ void kvm_s390_gisa_clear(struct kvm *kvm)
> if (!gi->origin)
> return;
> gisa_clear_ipm(gi->origin);
> - VM_EVENT(kvm, 3, "gisa 0x%pK cleared", gi->origin);
> + VM_EVENT(kvm, 3, "gisa 0x%p cleared", gi->origin);
> }
>
> void kvm_s390_gisa_init(struct kvm *kvm)
> @@ -3178,7 +3178,7 @@ void kvm_s390_gisa_init(struct kvm *kvm)
> gi->timer.function = gisa_vcpu_kicker;
> memset(gi->origin, 0, sizeof(struct kvm_s390_gisa));
> gi->origin->next_alert = (u32)virt_to_phys(gi->origin);
> - VM_EVENT(kvm, 3, "gisa 0x%pK initialized", gi->origin);
> + VM_EVENT(kvm, 3, "gisa 0x%p initialized", gi->origin);
> }
>
> void kvm_s390_gisa_enable(struct kvm *kvm)
> @@ -3219,7 +3219,7 @@ void kvm_s390_gisa_destroy(struct kvm *kvm)
> process_gib_alert_list();
> hrtimer_cancel(&gi->timer);
> gi->origin = NULL;
> - VM_EVENT(kvm, 3, "gisa 0x%pK destroyed", gisa);
> + VM_EVENT(kvm, 3, "gisa 0x%p destroyed", gisa);
> }
>
> void kvm_s390_gisa_disable(struct kvm *kvm)
> @@ -3468,7 +3468,7 @@ int __init kvm_s390_gib_init(u8 nisc)
> }
> }
>
> - KVM_EVENT(3, "gib 0x%pK (nisc=%d) initialized", gib, gib->nisc);
> + KVM_EVENT(3, "gib 0x%p (nisc=%d) initialized", gib, gib->nisc);
> goto out;
>
> out_unreg_gal:
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index ebecb96bacce7d75563bd3a130a7cc31869dc254..9e427ba3aed42edf617d6625b5bcaba8f43dc464 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -1020,7 +1020,7 @@ static int kvm_s390_set_mem_control(struct kvm *kvm, struct kvm_device_attr *att
> }
> mutex_unlock(&kvm->lock);
> VM_EVENT(kvm, 3, "SET: max guest address: %lu", new_limit);
> - VM_EVENT(kvm, 3, "New guest asce: 0x%pK",
> + VM_EVENT(kvm, 3, "New guest asce: 0x%p",
> (void *) kvm->arch.gmap->asce);
> break;
> }
> @@ -3464,7 +3464,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> kvm_s390_gisa_init(kvm);
> INIT_LIST_HEAD(&kvm->arch.pv.need_cleanup);
> kvm->arch.pv.set_aside = NULL;
> - KVM_EVENT(3, "vm 0x%pK created by pid %u", kvm, current->pid);
> + KVM_EVENT(3, "vm 0x%p created by pid %u", kvm, current->pid);
>
> return 0;
> out_err:
> @@ -3527,7 +3527,7 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
> kvm_s390_destroy_adapters(kvm);
> kvm_s390_clear_float_irqs(kvm);
> kvm_s390_vsie_destroy(kvm);
> - KVM_EVENT(3, "vm 0x%pK destroyed", kvm);
> + KVM_EVENT(3, "vm 0x%p destroyed", kvm);
> }
>
> /* Section: vcpu related */
> @@ -3648,7 +3648,7 @@ static int sca_switch_to_extended(struct kvm *kvm)
>
> free_page((unsigned long)old_sca);
>
> - VM_EVENT(kvm, 2, "Switched to ESCA (0x%pK -> 0x%pK)",
> + VM_EVENT(kvm, 2, "Switched to ESCA (0x%p -> 0x%p)",
> old_sca, kvm->arch.sca);
> return 0;
> }
> @@ -4025,7 +4025,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
> goto out_free_sie_block;
> }
>
> - VM_EVENT(vcpu->kvm, 3, "create cpu %d at 0x%pK, sie block at 0x%pK",
> + VM_EVENT(vcpu->kvm, 3, "create cpu %d at 0x%p, sie block at 0x%p",
> vcpu->vcpu_id, vcpu, vcpu->arch.sie_block);
> trace_kvm_s390_create_vcpu(vcpu->vcpu_id, vcpu, vcpu->arch.sie_block);
>
>
next prev parent reply other threads:[~2025-02-25 12:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 13:13 [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints Thomas Weißschuh
2025-02-17 13:13 ` [PATCH 1/2] KVM: s390: Don't use %pK through tracepoints Thomas Weißschuh
2025-02-25 13:08 ` Michael Mueller
2025-02-17 13:13 ` [PATCH 2/2] KVM: s390: Don't use %pK through debug printing Thomas Weißschuh
2025-02-25 12:56 ` Michael Mueller [this message]
2025-02-27 16:04 ` [PATCH 0/2] KVM: s390: Don't use %pK through debug printing or tracepoints Janosch Frank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5ac2dda6-a9ac-449a-bb7c-0f9eb90614f5@linux.ibm.com \
--to=mimu@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=svens@linux.ibm.com \
--cc=thomas.weissschuh@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox