Re: [PATCH] KVM: remove printing of token address

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/10/2017 12:04, Tobin C. Harding wrote:
> On Mon, Oct 09, 2017 at 03:49:38AM -0400, Paolo Bonzini wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Tobin C. Harding" <me@xxxxxxxx>
>>> To: "Paolo Bonzini" <pbonzini@xxxxxxxxxx>, rkrcmar@xxxxxxxxxx
>>> Cc: kvm@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, "Tobin C. Harding" <me@xxxxxxxx>
>>> Sent: Monday, October 9, 2017 8:30:14 AM
>>> Subject: [PATCH] KVM: remove printing of token address
>>>
>>> KVM currently prints the address of the consumer token. It is not
>>> immediately clear what benefit it is to see this address. Printing
>>> this address leaks kernel pointers into dmesg and is a security risk.
>>>
>>> Remove the consumer token address from error message output.
>>
>> It should use %pK instead.
> 
> Is there any other way we can identify a token? There is some push back against kpt_restrict (as
> used by %pK) at the moment. If there is another sane way to do it perhaps we could consider that,
> else I'll use %pK for v2.

Not really, we know it is an eventfd but you can't go from the struct
eventfd_ctx* (the token) to the corresponding struct file.

I'm not sure about the pushback... I've read your name in
https://lwn.net/Articles/735589/ :) and that article says "the same
effect as a restrictive kptr_restrict setting could be achieved by
searching for (and fixing) every use of unadorned "%p" directives in the
kernel".  As I understand it, the push back is against restrictive
kptr_restrict settings, not against using "%pK" _to avoid the need_ for
such a restrictive setting.

Thanks,

Paolo

>> Also, please do the same change on the VFIO
>> side (drivers/vfio/pci/vfio_pci_intrs.c, call to irq_bypass_register_producer).
> 
> Oh, cool. I was wondering where the other side was. Will send v2
> 
> thanks,
> Tobin.
> 




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux