linux-kernel - Re: [PATCH] KVM: remove printing of token address

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <f3b2e079-4ed2-dd21-2229-24655d6ea54d@redhat.com>
Date:   Mon, 9 Oct 2017 12:58:12 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     "Tobin C. Harding" <me@...in.cc>
Cc:     rkrcmar@...hat.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: remove printing of token address

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@...in.cc>
>>> To: "Paolo Bonzini" <pbonzini@...hat.com>, rkrcmar@...hat.com
>>> Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, "Tobin C. Harding" <me@...in.cc>
>>> 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.
>