All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Gabriel L. Somlo" <somlo@cmu.edu>, kbuild test robot <lkp@intel.com>
Cc: mark.rutland@arm.com, peter.maydell@linaro.org, mst@redhat.com,
	stefanha@gmail.com, qemu-devel@nongnu.org, eric@anholt.net,
	kraxel@redhat.com, linux-api@vger.kernel.org, pawel.moll@arm.com,
	zajec5@gmail.com, galak@codeaurora.org,
	rmk+kernel@arm.linux.org.uk, lersek@redhat.com,
	hanjun.guo@linaro.org, devicetree@vger.kernel.org, arnd@arndb.de,
	ijc+devicetree@hellion.org.uk, jordan.l.justen@intel.com,
	agross@codeaurora.org, leif.lindholm@linaro.org,
	robh+dt@kernel.org, ard.biesheuvel@linaro.org,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	luto@amacapital.net, kbuild-all@01.org, sudeep.holla@arm.com,
	pbonzini@redhat.com, revol@free.fr
Subject: Re: [Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
Date: Tue, 24 Nov 2015 10:38:18 -0700	[thread overview]
Message-ID: <5654A08A.6030002@redhat.com> (raw)
In-Reply-To: <20151124165553.GA22627@HEDWIG.INI.CMU.EDU>

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

On 11/24/2015 09:55 AM, Gabriel L. Somlo wrote:
> On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote:

>>
>>    drivers/firmware/qemu_fw_cfg.c: In function 'fw_cfg_cmdline_set':
>>>> drivers/firmware/qemu_fw_cfg.c:510:7: warning: format '%lli' expects argument of type 'long long int *', but argument 3 has type 'phys_addr_t *' [-Wformat=]
>>           &ctrl_off, &data_off, &consumed);
>>           ^
> 
> Oh, I think I know why this happened:
> 

> 
> So, I could use u64 instead of phys_addr_t and resource_size_t, and
> keep "%lli" (or "%Li"), but then I'd have to check if the parsed value

%Li is not POSIX.  Don't use it (stick with %lli).

> would overflow a 32-bit address value on arches where phys_addr_t is
> u32, which would make things a bit more messy and awkward.
> 
> I'm planning on #ifdef-ing the format string instead:
> 
> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> #define PH_ADDR_SCAN_FMT "@%Li%n:%Li:%Li%n"
> #else
> #define PH_ADDR_SCAN_FMT "@%li%n:%li:%li%n"
> #endif

A more typical approach is akin to <inttypes.h>; have PH_ADDR_FMT
defined to either "lli" or "li", then write sscanf(str, "@%"PH_ADDR_FMT
"%n:..., ...), using PH_ADDR_FMT multiple times.

> ...
>         processed = sscanf(str, PH_ADDR_SCAN_FMT,
>                            &base, &consumed,
>                            &ctrl_off, &data_off, &consumed);

Umm, why are you passing &consumed to more than one sscanf() %?  That's
(probably) undefined behavior.

[In general, sscanf() is a horrid interface to use for parsing integers
- it has undefined behavior if the input text would trigger integer
overflow, making it safe to use ONLY on text that you control and can
guarantee won't overflow. By the time you've figured out if untrusted
text meets the requirement for safe parsing via sscanf(), you've
practically already parsed it via safer strtol() and friends.]

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Gabriel L. Somlo" <somlo-D+Gtc/HYRWM@public.gmane.org>,
	kbuild test robot <lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
	peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	stefanha-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org,
	eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org,
	kraxel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	pawel.moll-5wv7dgnIgG8@public.gmane.org,
	zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
	lersek-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	arnd-r2nGTMty4D4@public.gmane.org,
	ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
	jordan.l.justen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	agross-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org,
	kbuild-all-JC7UmRfGjtg@public.gmane.org,
	sudeep.holla-5wv7dgnIgG8@public.gmane.org,
	pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	revol-GANU6spQydw@public.gmane.org
Subject: Re: [Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
Date: Tue, 24 Nov 2015 10:38:18 -0700	[thread overview]
Message-ID: <5654A08A.6030002@redhat.com> (raw)
In-Reply-To: <20151124165553.GA22627-h65ZQ0r4j6KKUezXOiBB2eW1CriLhL8O@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

On 11/24/2015 09:55 AM, Gabriel L. Somlo wrote:
> On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote:

>>
>>    drivers/firmware/qemu_fw_cfg.c: In function 'fw_cfg_cmdline_set':
>>>> drivers/firmware/qemu_fw_cfg.c:510:7: warning: format '%lli' expects argument of type 'long long int *', but argument 3 has type 'phys_addr_t *' [-Wformat=]
>>           &ctrl_off, &data_off, &consumed);
>>           ^
> 
> Oh, I think I know why this happened:
> 

> 
> So, I could use u64 instead of phys_addr_t and resource_size_t, and
> keep "%lli" (or "%Li"), but then I'd have to check if the parsed value

%Li is not POSIX.  Don't use it (stick with %lli).

> would overflow a 32-bit address value on arches where phys_addr_t is
> u32, which would make things a bit more messy and awkward.
> 
> I'm planning on #ifdef-ing the format string instead:
> 
> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> #define PH_ADDR_SCAN_FMT "@%Li%n:%Li:%Li%n"
> #else
> #define PH_ADDR_SCAN_FMT "@%li%n:%li:%li%n"
> #endif

A more typical approach is akin to <inttypes.h>; have PH_ADDR_FMT
defined to either "lli" or "li", then write sscanf(str, "@%"PH_ADDR_FMT
"%n:..., ...), using PH_ADDR_FMT multiple times.

> ...
>         processed = sscanf(str, PH_ADDR_SCAN_FMT,
>                            &base, &consumed,
>                            &ctrl_off, &data_off, &consumed);

Umm, why are you passing &consumed to more than one sscanf() %?  That's
(probably) undefined behavior.

[In general, sscanf() is a horrid interface to use for parsing integers
- it has undefined behavior if the input text would trigger integer
overflow, making it safe to use ONLY on text that you control and can
guarantee won't overflow. By the time you've figured out if untrusted
text meets the requirement for safe parsing via sscanf(), you've
practically already parsed it via safer strtol() and friends.]

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake@redhat.com>
To: "Gabriel L. Somlo" <somlo@cmu.edu>, kbuild test robot <lkp@intel.com>
Cc: mark.rutland@arm.com, peter.maydell@linaro.org, mst@redhat.com,
	stefanha@gmail.com, qemu-devel@nongnu.org,
	linux-kernel@vger.kernel.org, eric@anholt.net, kraxel@redhat.com,
	pawel.moll@arm.com, zajec5@gmail.com,
	rmk+kernel@arm.linux.org.uk, lersek@redhat.com,
	kbuild-all@01.org, devicetree@vger.kernel.org, arnd@arndb.de,
	ijc+devicetree@hellion.org.uk, jordan.l.justen@intel.com,
	galak@codeaurora.org, leif.lindholm@linaro.org,
	robh+dt@kernel.org, sudeep.holla@arm.com,
	ard.biesheuvel@linaro.org, linux-api@vger.kernel.org,
	gregkh@linuxfoundation.org, luto@amacapital.net,
	hanjun.guo@linaro.org, agross@codeaurora.org,
	pbonzini@redhat.com, revol@free.fr
Subject: Re: [Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
Date: Tue, 24 Nov 2015 10:38:18 -0700	[thread overview]
Message-ID: <5654A08A.6030002@redhat.com> (raw)
In-Reply-To: <20151124165553.GA22627@HEDWIG.INI.CMU.EDU>

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

On 11/24/2015 09:55 AM, Gabriel L. Somlo wrote:
> On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote:

>>
>>    drivers/firmware/qemu_fw_cfg.c: In function 'fw_cfg_cmdline_set':
>>>> drivers/firmware/qemu_fw_cfg.c:510:7: warning: format '%lli' expects argument of type 'long long int *', but argument 3 has type 'phys_addr_t *' [-Wformat=]
>>           &ctrl_off, &data_off, &consumed);
>>           ^
> 
> Oh, I think I know why this happened:
> 

> 
> So, I could use u64 instead of phys_addr_t and resource_size_t, and
> keep "%lli" (or "%Li"), but then I'd have to check if the parsed value

%Li is not POSIX.  Don't use it (stick with %lli).

> would overflow a 32-bit address value on arches where phys_addr_t is
> u32, which would make things a bit more messy and awkward.
> 
> I'm planning on #ifdef-ing the format string instead:
> 
> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> #define PH_ADDR_SCAN_FMT "@%Li%n:%Li:%Li%n"
> #else
> #define PH_ADDR_SCAN_FMT "@%li%n:%li:%li%n"
> #endif

A more typical approach is akin to <inttypes.h>; have PH_ADDR_FMT
defined to either "lli" or "li", then write sscanf(str, "@%"PH_ADDR_FMT
"%n:..., ...), using PH_ADDR_FMT multiple times.

> ...
>         processed = sscanf(str, PH_ADDR_SCAN_FMT,
>                            &base, &consumed,
>                            &ctrl_off, &data_off, &consumed);

Umm, why are you passing &consumed to more than one sscanf() %?  That's
(probably) undefined behavior.

[In general, sscanf() is a horrid interface to use for parsing integers
- it has undefined behavior if the input text would trigger integer
overflow, making it safe to use ONLY on text that you control and can
guarantee won't overflow. By the time you've figured out if untrusted
text meets the requirement for safe parsing via sscanf(), you've
practically already parsed it via safer strtol() and friends.]

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2015-11-24 17:38 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 15:57 [PATCH v5 0/4] SysFS driver for QEMU fw_cfg device Gabriel L. Somlo
2015-11-23 15:57 ` [Qemu-devel] " Gabriel L. Somlo
2015-11-23 15:57 ` Gabriel L. Somlo
2015-11-23 15:57 ` [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's " Gabriel L. Somlo
2015-11-23 15:57   ` [Qemu-devel] " Gabriel L. Somlo
2015-11-23 15:57   ` Gabriel L. Somlo
2015-11-23 20:14   ` kbuild test robot
2015-11-23 20:14     ` [Qemu-devel] " kbuild test robot
2015-11-23 20:14     ` kbuild test robot
2015-11-24 16:55     ` Gabriel L. Somlo
2015-11-24 16:55       ` [Qemu-devel] " Gabriel L. Somlo
2015-11-24 16:55       ` Gabriel L. Somlo
2015-11-24 17:38       ` Eric Blake [this message]
2015-11-24 17:38         ` [Qemu-devel] " Eric Blake
2015-11-24 17:38         ` Eric Blake
2015-11-24 17:44         ` Laszlo Ersek
2015-11-24 17:44           ` Laszlo Ersek
2015-11-24 17:44           ` Laszlo Ersek
2015-11-24 18:09         ` Gabriel L. Somlo
2015-11-24 18:09           ` Gabriel L. Somlo
2015-11-23 15:57 ` [PATCH v5 2/4] kobject: export kset_find_obj() for module use Gabriel L. Somlo
2015-11-23 15:57   ` [Qemu-devel] " Gabriel L. Somlo
2015-11-23 15:57   ` Gabriel L. Somlo
2015-11-23 15:57 ` [PATCH v5 3/4] firmware: create directory hierarchy for sysfs fw_cfg entries Gabriel L. Somlo
2015-11-23 15:57   ` [Qemu-devel] " Gabriel L. Somlo
2015-11-23 15:57 ` [PATCH v5 4/4] devicetree: update documentation for fw_cfg ARM bindings Gabriel L. Somlo
2015-11-23 15:57   ` [Qemu-devel] " Gabriel L. Somlo
2015-11-23 16:35   ` Laszlo Ersek
2015-11-23 16:35     ` [Qemu-devel] " Laszlo Ersek
2015-11-23 16:35     ` Laszlo Ersek
2015-11-23 16:47     ` Gabriel L. Somlo
2015-11-23 16:47       ` [Qemu-devel] " Gabriel L. Somlo
2015-11-23 16:47       ` Gabriel L. Somlo
2015-11-25  2:42   ` Rob Herring
2015-11-25  2:42     ` [Qemu-devel] " Rob Herring
2015-11-25  2:42     ` Rob Herring

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=5654A08A.6030002@redhat.com \
    --to=eblake@redhat.com \
    --cc=agross@codeaurora.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=eric@anholt.net \
    --cc=galak@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hanjun.guo@linaro.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jordan.l.justen@intel.com \
    --cc=kbuild-all@01.org \
    --cc=kraxel@redhat.com \
    --cc=leif.lindholm@linaro.org \
    --cc=lersek@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=luto@amacapital.net \
    --cc=mark.rutland@arm.com \
    --cc=mst@redhat.com \
    --cc=pawel.moll@arm.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=revol@free.fr \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=robh+dt@kernel.org \
    --cc=somlo@cmu.edu \
    --cc=stefanha@gmail.com \
    --cc=sudeep.holla@arm.com \
    --cc=zajec5@gmail.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 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.