qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 01/21] iotests: Make 233 output more reliable


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v4 01/21] iotests: Make 233 output more reliable
Date: Fri, 18 Jan 2019 09:56:51 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 1/18/19 4:02 AM, Daniel P. Berrangé wrote:
> On Thu, Jan 17, 2019 at 01:36:38PM -0600, Eric Blake wrote:
>> We have a race between the nbd server and the client both trying
>> to report errors at once which can make the test sometimes fail
>> if the output lines swap order under load.  Break the race by
>> collecting server messages into a file and then replaying that
>> at the end of the test.
>>
>> Signed-off-by: Eric Blake <address@hidden>
>> CC: Daniel P. Berrangé <address@hidden>
>>
>> ---
>> An alternative solution might be to silence the message from the
>> server by default, and output it only when -v was passed
> 
> I wouldn't consider this an either/or situation. It is probably
> good practice to qemu-nbd to be completely silent wrt client
> problems so a malicious client can't spam the qemu-nbd log (if
> any). None the less it is also useful to have the iotests validate
> that this log message is printed.

Thus, the idea for future patches is to:
- teach qemu-nbd to be silent on client disconnects by default to avoid
a malicious client performing DoS by excessive logging,
- teach iotests to run qemu-nbd with -v to double-check what server
logs, as verbose server logs are quite handy when debugging why a
particular client can't connect

Now that the issue is public, is this something I should report to
secalert, or is it not at the level of a CVE?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]