FYI, looks like these were added by a4dff76924fe ("x86/gpu: Add Intel
graphics stolen memory quirk for gen2 platforms").
---------- Forwarded message ----------
From: <[email protected]>
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.
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: <[email protected]>
> 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
On 04/12/2014 02:41 PM, Ville Syrj?l? wrote:
> 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.
>
Please do, but make it UL (in the Linux kernel context, unsigned long is
always equivalent to size_t/pointer size.)
-hpa
From: Ville Syrjälä <[email protected]>
Have the KB(),MB(),GB() macros produce unsigned longs to avoid
uninteded sign extension issues with the gen2 memory size detection.
What happens is first the uint8_t returned by read_pci_config_byte()
gets promoted to an int which gets multiplied by another int from the
MB() macro, and finally the result gets sign extended to size_t.
Although this shouldn't be a problem in practice as all affected gen2
platforms are 32bit AFAIK, so size_t will be 32 bits.
Cc: H. Peter Anvin <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
---
arch/x86/kernel/early-quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index b0cc380..6e2537c 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -240,7 +240,7 @@ static u32 __init intel_stolen_base(int num, int slot, int func, size_t stolen_s
return base;
}
-#define KB(x) ((x) * 1024)
+#define KB(x) ((x) * 1024UL)
#define MB(x) (KB (KB (x)))
#define GB(x) (MB (KB (x)))
--
1.8.3.2
Commit-ID: 86e587623a0ca8426267dad8d3eaebd6fc2d00f1
Gitweb: http://git.kernel.org/tip/86e587623a0ca8426267dad8d3eaebd6fc2d00f1
Author: Ville Syrjälä <[email protected]>
AuthorDate: Sun, 13 Apr 2014 12:45:03 +0300
Committer: Ingo Molnar <[email protected]>
CommitDate: Mon, 14 Apr 2014 08:50:56 +0200
x86/gpu: Fix sign extension issue in Intel graphics stolen memory quirks
Have the KB(),MB(),GB() macros produce unsigned longs to avoid
unintended sign extension issues with the gen2 memory size
detection.
What happens is first the uint8_t returned by
read_pci_config_byte() gets promoted to an int which gets
multiplied by another int from the MB() macro, and finally the
result gets sign extended to size_t.
Although this shouldn't be a problem in practice as all affected
gen2 platforms are 32bit AFAIK, so size_t will be 32 bits.
Reported-by: Bjorn Helgaas <[email protected]>
Suggested-by: H. Peter Anvin <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/early-quirks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index b0cc380..6e2537c 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -240,7 +240,7 @@ static u32 __init intel_stolen_base(int num, int slot, int func, size_t stolen_s
return base;
}
-#define KB(x) ((x) * 1024)
+#define KB(x) ((x) * 1024UL)
#define MB(x) (KB (KB (x)))
#define GB(x) (MB (KB (x)))