qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	xen-devel@lists.xensource.com, mst@redhat.com,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, Sander Eikelenboom <linux@eikelenboom.it>,
	John Snow <jsnow@redhat.com>,
	rth@twiddle.net
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults
Date: Thu, 14 May 2015 16:44:00 +0200	[thread overview]
Message-ID: <5554B4B0.7030002@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1505141530040.20496@kaball.uk.xensource.com>



On 14/05/2015 16:39, Stefano Stabellini wrote:
> On Thu, 14 May 2015, Paolo Bonzini wrote:
>> On 14/05/2015 15:25, Sander Eikelenboom wrote:
>>> I tend to kindly disagree if you look at the broader perspective, yes it's could 
>>> be a storm in a tea cup, but there seems to be a pattern.
>>>
>>> From a "cmdline user" / "platform emulation" point of view i can imagine that some sort of 
>>> auto configuration / bundling in platforms is necessary (to limit the length of 
>>> the cmdline to be supplied).
>>>
>>> But from a library / toolstack point of view it's quite nasty if *all* more or 
>>> less obscure options have to actively disabled. It's quite undoable, not to mention what
>>> happens when new ones get added. 
>>
>> Where do you stop?
> 
> At this stage I would be happy enough if no floppy drives were actually
> emulated when the user asks for none.

Floppy drives aren't being emulated; the controller is.  Same for IDE,
so why single out the FDD controller?

> Sure, but it is harder to write a device emulator in a secure fashion
> than a brand new PV interface, that can be designed with security in
> mind from scratch. The number of VM escaping CVEs affecting Xen PV
> interfaces is extremely low, I think it was just two since the start of
> the project.

Sure; OTOH, treating hypervisor and QEMU escapes would be very silly, if
QEMU has been properly protected (through any combination of stubdoms,
LSM, seccomp, ...).

Paolo

> 
> 
>>> From this PoV it would be better to have to actively enable all the stuff you want.
>>>
>>> At least Xen seemed to have taken the "no-defaults" as the best option to get 
>>> there so far, but that doesn't seem to 
>>>
>>> It's not the first CVE that has come from this "you have to actively disable all 
>>> you don't want to happen" and probably won't be the last.
>>>
>>> So a "-no-defaults-now-for-real" option/mode for libraries / toolstacks, that 
>>> requires them to be very verbose, explicit and specific in what they actually 
>>> want, could be valuable.
>>

  reply	other threads:[~2015-05-14 14:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 17:29 [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Stefano Stabellini
2015-05-13 17:42 ` Daniel P. Berrange
2015-05-13 18:15   ` Stefano Stabellini
2015-05-13 21:46     ` John Snow
2015-05-14 11:12       ` Stefano Stabellini
2015-05-14 11:18         ` Daniel P. Berrange
2015-05-14 11:46           ` Michael S. Tsirkin
2015-05-14 12:02           ` Markus Armbruster
2015-05-14 12:11             ` Paolo Bonzini
2015-05-14 12:45               ` Markus Armbruster
2015-05-14 12:48                 ` Daniel P. Berrange
2015-05-14 12:53                 ` Paolo Bonzini
2015-05-14 13:25                   ` [Qemu-devel] [Xen-devel] " Sander Eikelenboom
2015-05-14 13:41                     ` Daniel P. Berrange
2015-05-14 13:55                     ` Paolo Bonzini
2015-05-14 14:39                       ` Stefano Stabellini
2015-05-14 14:44                         ` Paolo Bonzini [this message]
2015-05-14 14:52                           ` Stefano Stabellini
2015-05-14 13:57                     ` Michael S. Tsirkin
2015-05-14 14:07             ` [Qemu-devel] " Michael S. Tsirkin
2015-05-14 17:54               ` John Snow
2015-05-15  7:50                 ` Markus Armbruster
2015-05-15  8:19                   ` Paolo Bonzini
2015-05-15 10:20                     ` Stefano Stabellini
2015-05-18  9:19                 ` Kevin Wolf
2015-05-14 11:47         ` Michael S. Tsirkin
2015-05-14 11:54           ` Paolo Bonzini
2015-05-14 11:56             ` Michael S. Tsirkin
2015-05-14 12:47             ` Markus Armbruster
2015-05-14  4:38     ` Stefan Weil
2015-05-14  5:45       ` Michael S. Tsirkin
2015-05-13 21:44 ` Michael S. Tsirkin

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=5554B4B0.7030002@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=armbru@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=linux@eikelenboom.it \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /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;
as well as URLs for NNTP newsgroup(s).