From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Markus Armbruster" <armbru@redhat.com>,
qemu-devel@nongnu.org,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH v8 01/11] util: add helper APIs for dealing with inotify in portable manner
Date: Fri, 28 Jan 2022 16:42:02 +0000 [thread overview]
Message-ID: <YfQc2nEvP1IgFKJt@redhat.com> (raw)
In-Reply-To: <CAFEAcA-hKkN-f+85zNwXZwgXWtZ=mEX+P-Pm13rh-G=bCeHzcw@mail.gmail.com>
On Fri, Jan 28, 2022 at 04:17:32PM +0000, Peter Maydell wrote:
> On Fri, 15 Feb 2019 at 16:06, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > The inotify userspace API for reading events is quite horrible, so it is
> > useful to wrap it in a more friendly API to avoid duplicating code
> > across many users in QEMU. Wrapping it also allows introduction of a
> > platform portability layer, so that we can add impls for non-Linux based
> > equivalents in future.
>
> Hi; Coverity has suddenly decided to complain about this 3-year-old
> code (in CID 1469132). It reports an "untrusted loop bound" because
> in the 'loop over events in the buffer' we use the data we just read
> from the filedescriptor (specifically ev->len) as part of the
> calculation of our loop termination condition.
>
> Is there actually anything to change here, or is this a false
> positive because we actually trust the data we're getting on this fd?
I think its false positive. The inotify API between kernel and
userspace requires that you work in this manner. The data on
this FD is strictly emitted by the kernel, not any untrusted
application, so I don't think there's a risk here.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2022-01-28 16:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-15 15:56 [Qemu-devel] [PATCH v8 00/11] Add a standard authorization framework Daniel P. Berrangé
2019-02-15 15:56 ` [Qemu-devel] [PATCH v8 01/11] util: add helper APIs for dealing with inotify in portable manner Daniel P. Berrangé
2022-01-28 16:17 ` Peter Maydell
2022-01-28 16:42 ` Daniel P. Berrangé [this message]
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 02/11] qom: don't require user creatable objects to be registered Daniel P. Berrangé
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 03/11] hw/usb: don't set IN_ISDIR for inotify watch in MTP driver Daniel P. Berrangé
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 04/11] hw/usb: fix const-ness for string params " Daniel P. Berrangé
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 05/11] hw/usb: switch MTP to use new inotify APIs Daniel P. Berrangé
2019-02-16 11:28 ` Marc-André Lureau
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 06/11] authz: add QAuthZ object as an authorization base class Daniel P. Berrangé
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 07/11] authz: add QAuthZSimple object type for easy whitelist auth checks Daniel P. Berrangé
2019-02-16 11:31 ` Marc-André Lureau
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 08/11] authz: add QAuthZList object type for an access control list Daniel P. Berrangé
2019-02-16 11:35 ` Marc-André Lureau
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 09/11] authz: add QAuthZListFile object type for a file " Daniel P. Berrangé
2019-02-16 11:40 ` Marc-André Lureau
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 10/11] authz: add QAuthZPAM object type for authorizing using PAM Daniel P. Berrangé
2019-02-22 0:34 ` Philippe Mathieu-Daudé
2019-02-22 12:24 ` Daniel P. Berrangé
2019-02-22 13:27 ` Philippe Mathieu-Daudé
2019-02-22 14:49 ` Daniel P. Berrangé
2019-02-15 15:57 ` [Qemu-devel] [PATCH v8 11/11] authz: delete existing ACL implementation Daniel P. Berrangé
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=YfQc2nEvP1IgFKJt@redhat.com \
--to=berrange@redhat.com \
--cc=afaerber@suse.de \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.