public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Fwd: New Defects reported by Coverity Scan for Linux
Date: Sun, 13 Apr 2014 00:41:45 +0300	[thread overview]
Message-ID: <20140412214145.GL18465@intel.com> (raw)
In-Reply-To: <CAErSpo6r3Xw8fZ7eaW=8Mg9EabtPUAOQU8ExGt4aYL--+OnLgA@mail.gmail.com>

On Sat, Apr 12, 2014 at 07:29:29AM -0600, Bjorn Helgaas wrote:
> FYI, looks like these were added by a4dff76924fe ("x86/gpu: Add Intel
> graphics stolen memory quirk for gen2 platforms").

Some of the affected gen2 platforms do support up to 2GB of RAM which
means that if the sign extension were to happen they could hit this.
However I believe all gen2 platforms are 32bit which AFAIK makes size_t 
32 bits. So looks like we can't hit this in practice..

But if someone were to change the return type to 64bits we'd
be in real danger, so I guess it would be better to fix the bug
anyway.

-#define KB(x)  ((x) * 1024)
+#define KB(x)  ((x) * 1024U)
should be sufficient to eliminate the problem. If someone wants me to
put that into a real patch and send it out let me know.

> 
> 
> ---------- Forwarded message ----------
> From:  <scan-admin@coverity.com>
> Date: Sat, Apr 12, 2014 at 1:24 AM
> Subject: New Defects reported by Coverity Scan for Linux
> To:
> 
> ...
> 
> ** CID 1201423:  Unintended sign extension  (SIGN_EXTENSION)
> /arch/x86/kernel/early-quirks.c: 290 in i830_mem_size()
> 
> ** CID 1201424:  Unintended sign extension  (SIGN_EXTENSION)
> /arch/x86/kernel/early-quirks.c: 295 in i85x_mem_size()
> 
> ...
> ________________________________________________________________________________________________________
> *** CID 1201423:  Unintended sign extension  (SIGN_EXTENSION)
> /arch/x86/kernel/early-quirks.c: 290 in i830_mem_size()
> 284
> 285             return MB(1);
> 286     }
> 287
> 288     static size_t __init i830_mem_size(void)
> 289     {
> >>>     CID 1201423:  Unintended sign extension  (SIGN_EXTENSION)
> >>>     Suspicious implicit sign extension: "read_pci_config_byte(0, 0, 0, 99)" with type "unsigned char" (8 bits, unsigned) is promoted in "read_pci_config_byte(0, 0, 0, 99) * 33554432" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned).  If "read_pci_config_byte(0, 0, 0, 99) * 33554432" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
> 290             return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
> 291     }
> 292
> 293     static size_t __init i85x_mem_size(void)
> 294     {
> 295             return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
> 
> ________________________________________________________________________________________________________
> *** CID 1201424:  Unintended sign extension  (SIGN_EXTENSION)
> /arch/x86/kernel/early-quirks.c: 295 in i85x_mem_size()
> 289     {
> 290             return read_pci_config_byte(0, 0, 0, I830_DRB3) * MB(32);
> 291     }
> 292
> 293     static size_t __init i85x_mem_size(void)
> 294     {
> >>>     CID 1201424:  Unintended sign extension  (SIGN_EXTENSION)
> >>>     Suspicious implicit sign extension: "read_pci_config_byte(0, 0, 1, 67)" with type "unsigned char" (8 bits, unsigned) is promoted in "read_pci_config_byte(0, 0, 1, 67) * 33554432" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned).  If "read_pci_config_byte(0, 0, 1, 67) * 33554432" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1.
> 295             return read_pci_config_byte(0, 0, 1, I85X_DRB3) * MB(32);
> 296     }
> 297
> 298     /*
> 299      * On 830/845/85x the stolen memory base isn't available in any
> 300      * register. We need to calculate it as TOM-TSEG_SIZE-stolen_size.

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2014-04-12 21:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5348ea4572e7_5d4d7ac86c27677@209.249.196.67.mail>
2014-04-12 13:29 ` Fwd: New Defects reported by Coverity Scan for Linux Bjorn Helgaas
2014-04-12 21:41   ` Ville Syrjälä [this message]
2014-04-12 22:41     ` H. Peter Anvin
2014-04-13  9:45       ` [PATCH] x86/gpu: Fix sign extension issue in Intel graphics stolen memory quirks ville.syrjala
2014-04-14  7:22         ` [tip:x86/urgent] " tip-bot for Ville Syrjälä

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=20140412214145.GL18465@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox