Lenovo T410 Coreboot
by A. Veek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
8 months, 1 week
Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?
by Daniel Kulesz
Hi,
I wanted to try caching of the MRC training data. As described in Timothy's post, I commented the following line:
> allow_config_restore = 0;
However, I was not able to measure any effects regarding boot time. Does this setting only work with cbfs enabled? And if so, is it necessary to set additionally any cbfs variables?
Cheers, Daniel
P.S.
Hope this time I've set the Reply-To header correctly.
> On 03/02/2017 02:17 PM, Paul Menzel wrote:
> > Dear Arthur, dear Timothy,
> >
> >
> > Am Donnerstag, den 02.03.2017, 13:38 -0600 schrieb Timothy Pearson:
> >> On 03/02/2017 01:30 PM, Arthur Heymans wrote:
> >>> Paul Menzel writes:
> >>>
> >>>> I think most of the time is spent in RAM initialization.
> >>>>
> >>>> 1. Do board owners with similar amount of memory (independent of the
> >>>> board) have similar numbers?
> >>>> 2. What are the ways to improve that? Is it possible? For example, can
> >>>> the modules be probed in parallel (if that isn?t done already)?
> >>>>
> >>>
> >>> I'm not the right person to answer this since I don't know this
> >>> code/hardware that well, but on modern Intel hardware native code uses
> >>> the MRC cache to store dram training results and restore those on
> >>> next boots (and resume from suspend) if no change in dimm configuration
> >>> was detected.
> >>>
> >>> Maybe something like this could also be applied here (or maybe it's already
> >>> the case since it includes code to access spi flash)?
> >>
> >> Yes, this is already implemented as an option, and it does a fairly
> >> decent job of reducing training overhead to almost nothing,
> >
> > Interesting. What option is that?
> >
> > Also, besides the file `s3nv` I don?t see anything else in CBFS. Where
> > is the training data cached?
>
> That's it. The cache is mandatory for S3 resume, and optional at boot.
>
> That being said, the pathways are present but are deactivated due to
> historical instability and are not tied in to an nvram variable at this
> time. If you want to test, you'll need to edit the source file
> "src/northbridge/amd/amdmct/mct_ddr3/mct_d.c"; near line 2730 you'll see
> a FIXME comment and this line:
>
> allow_config_restore = 0;
>
> Comment that line out and recompile to test. I strongly suggest running
> memtest across multiple warm and cold boots (and reboots) before
> determining the functionality is stable enough for use.
2 years
Re: [coreboot] question on SMM
by Igor Skochinsky
Hello ron,
Friday, June 30, 2017, 6:25:06 AM, you wrote:
rm> there's something I am certain I don't understand about SMM on intel chipsets.
rm> The question is pretty simple. Consider a system with a recent
rm> intel chipset and flash. Is there some special secret sauce that
rm> disables writing to flash unless in SMM and if so, what is it?
Originally there were two bits in BIOS_CNTL used to effectively enable this[1]:
> When BIOS_CNTL.BLE is set to 1, attempts to write enable the BIOS by
> setting BIOS_CNTL.BIOSWE to 1 will immediately generate a System
> Management Interrupt (SMI). It is the job of this SMI to determine
> whether or not it is permissible to write enable to the BIOS, and if
> not, immediately set BIOS_CNTL.BIOSWE back to 0; the end result being
> that the BIOS is not writable.
As described in the link, this logic is vulnerable to race conditions,
so Intel added yet another bit:
> This issue is mitigated by setting the SMM_BWP bit in the BIOS
> Control Register along with setting BIOS Lock Enable (BLE) and
> clearing BIOS Write Enable (BIOSWE). The SMM_BWP bit requires the
> processor to be in SMM in order to honor writes to the BIOS region
> of SPI flash, thereby mitigating the issue.
So in theory all recent BIOSes should set SMM_BWP. Whether they
actually do it can be checked with Chipsec[4].
For more background see [2] and [3]
[1] https://www.kb.cert.org/vuls/id/766164
[2] http://opensecuritytraining.info/IntroBIOS_files/Day2_03_Advanced%20x86%2...
[3] http://composter.com.ua/documents/Exploiting_Flash_Protection_Race_Condit...
[4] https://github.com/chipsec/chipsec/blob/master/chipsec/modules/common/bio...
--
WBR,
Igor mailto:roxfan@skynet.be
2 years, 1 month
Re: [coreboot] question on SMM
by Nico Huber
On 30.06.2017 19:46, ron minnich wrote:
> Thanks for the good explanations.
>
> So I have a question for you all. We've been doing some testing of
> linux-as-ramstage. We've done a proof of concept that linux can set up the
> SMM handler at 0xa0000, the relocate stub at 0x38000, run the relocate
> stub, and have a working smm handler. The smm handler can trampoline to
> 64-bit mode and call the kernel, using existing mechanisms. So our SMM
> handler, in this scenario, is a set of functions provided by the kernel,
> not a binary blob. The result is a teeny tiny SMM handler and complete
> elimination of the vendor-supplied SMM code.
>
> There are lots of benefits. The SMM is no longer at a fixed location --
> it's kind of ASLR for SMM code; there is very little code that runs in SMM;
> and the SMM handlers we implement run in 64-bit mode with full memory
> protections. The big one for me is that persistent firmware blobs are
> reduced by one -- it's part of a goal to create an air gap between firmware
> and kernel. Another part of this work is that we're going to discard
> firmware-supplied ACPI tables and use ones supplied by the kernel.
>
> I realize this is not a general approach. But for small, limited
> configurations, such as OCP servers which come in a small number of
> flavors, it's quite doable.
Sounds really doable, but I'm a bit confused here, maybe because I
didn't look at SMM handlers for some time. Did you evaluate if you
need SMM at all? I just thought if you add board specific code to
the kernel, why would you have to do anything in SMM? In the case
of ACPI, most interrupts are already directly routed to the kernel
(as SCI instead of SMI).
Also, if you are going to reimplement the vendor ACPI tables, why
not write kernel-native drivers? ACPI is just a weird OS-independent
way of writing drivers.
Nico
2 years, 1 month
Re: [coreboot] question on SMM
by Marc Jones
On Fri, Jun 30, 2017 at 11:47 AM ron minnich <rminnich(a)gmail.com> wrote:
> Thanks for the good explanations.
>
> So I have a question for you all. We've been doing some testing of
> linux-as-ramstage. We've done a proof of concept that linux can set up the
> SMM handler at 0xa0000, the relocate stub at 0x38000, run the relocate
> stub, and have a working smm handler. The smm handler can trampoline to
> 64-bit mode and call the kernel, using existing mechanisms. So our SMM
> handler, in this scenario, is a set of functions provided by the kernel,
> not a binary blob. The result is a teeny tiny SMM handler and complete
> elimination of the vendor-supplied SMM code.
>
> There are lots of benefits. The SMM is no longer at a fixed location --
> it's kind of ASLR for SMM code; there is very little code that runs in SMM;
> and the SMM handlers we implement run in 64-bit mode with full memory
> protections. The big one for me is that persistent firmware blobs are
> reduced by one -- it's part of a goal to create an air gap between firmware
> and kernel. Another part of this work is that we're going to discard
> firmware-supplied ACPI tables and use ones supplied by the kernel.
>
> I realize this is not a general approach. But for small, limited
> configurations, such as OCP servers which come in a small number of
> flavors, it's quite doable.
>
> The only question that has been raised: are we losing an essential
> security guarantee since flash is writeable in this kernel-based "SMM"? The
> big question is whether we're opening up the possibility of firmware
> getting changed, once the kernel is our "smm mode". Is there a reasonable
> mitigation we could use in the SMM handler before we trampoline back up to
> the kernel?
>
> Thoughts on this are welcome.
>
>
Cool, Seems like you could leverage the coreboot SMM handler rmodule. Aaron
probably has some comments on this.
As for the trampoline, are you exiting SMM to the kernel to handle the
event and then returning with a second software SMI? If that is the case,
the kernel wouldn't be able to write flash. How are you handling core
synching? Is the trampoline only for the BSP?
I'm uncertain about having any more attack surface if the kernel owns SMM
or not. Just seems like which side you want to trust.
Marc
> ron
>
> On Fri, Jun 30, 2017 at 6:01 AM Alexander Couzens <lynxis(a)fe80.eu> wrote:
>
>> On Fri, 30 Jun 2017 04:25:06 +0000
>> ron minnich <rminnich(a)gmail.com> wrote:
>>
>> > there's something I am certain I don't understand about SMM on
>
>
> intel
>> > chipsets.
>> >
>> > The question is pretty simple. Consider a system with a recent intel
>> > chipset and flash. Is there some special secret sauce that disables
>> > writing to flash unless in SMM and if so, what is it?
>>
>> There is also a talk explaining it (without SMM_BWP).
>>
>>
>> https://media.ccc.de/v/31c3_-_6129_-_en_-_saal_2_-_201412282030_-_attacks...
>>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
--
http://marcjonesconsulting.com
2 years, 1 month
Re: [coreboot] question on SMM
by Patrick Georgi
2017-06-30 19:46 GMT+02:00 ron minnich <rminnich(a)gmail.com>:
> The only question that has been raised: are we losing an essential
> security guarantee since flash is writeable in this kernel-based "SMM"? The
> big question is whether we're opening up the possibility of firmware
> getting changed, once the kernel is our "smm mode". Is there a reasonable
> mitigation we could use in the SMM handler before we trampoline back up to
> the kernel?
>
To expand on Trammell's comment, FILO has code to work around a similar
issue on some older AMD chipsets: There, you can lock down the chipset's
flash write capability, only to see it circumvented by manual SPI commands
to write to flash. The solution is to tell the SPI flash itself to go
read-only:
https://review.coreboot.org/cgit/filo.git/tree/drivers/sb600.c#n1204
If you're certain that you don't need any more flash writes (for a _long_
time - I believe that one even survived cold resets), that could be another
defensive layer.
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
2 years, 1 month
Re: [coreboot] question on SMM
by Trammell Hudson
You can reduce the window of time that the flash is writable by setting
the PRR registers and FLOCKDN bits before moving out of the bootblock --
this prevents even SMM from being able to write to the protected regions of
the flash. If someone can get code execution in the bootblock or
during S3 resume (Dark Jedi/Thunderstrike 2), they might have a window
of opportunity to overwrite the flash.
Handling upgrades requires that the bootblock consider if it should
lock the configuration, which does introduce a dependency on outside
data and would require additional consideration.
--
Trammell
On Fri, Jun 30, 2017 at 05:46:19PM +0000, ron minnich wrote:
> Thanks for the good explanations.
>
> So I have a question for you all. We've been doing some testing of
> linux-as-ramstage. We've done a proof of concept that linux can set up the
> SMM handler at 0xa0000, the relocate stub at 0x38000, run the relocate
> stub, and have a working smm handler. The smm handler can trampoline to
> 64-bit mode and call the kernel, using existing mechanisms. So our SMM
> handler, in this scenario, is a set of functions provided by the kernel,
> not a binary blob. The result is a teeny tiny SMM handler and complete
> elimination of the vendor-supplied SMM code.
>
> There are lots of benefits. The SMM is no longer at a fixed location --
> it's kind of ASLR for SMM code; there is very little code that runs in SMM;
> and the SMM handlers we implement run in 64-bit mode with full memory
> protections. The big one for me is that persistent firmware blobs are
> reduced by one -- it's part of a goal to create an air gap between firmware
> and kernel. Another part of this work is that we're going to discard
> firmware-supplied ACPI tables and use ones supplied by the kernel.
>
> I realize this is not a general approach. But for small, limited
> configurations, such as OCP servers which come in a small number of
> flavors, it's quite doable.
>
> The only question that has been raised: are we losing an essential security
> guarantee since flash is writeable in this kernel-based "SMM"? The big
> question is whether we're opening up the possibility of firmware getting
> changed, once the kernel is our "smm mode". Is there a reasonable
> mitigation we could use in the SMM handler before we trampoline back up to
> the kernel?
>
> Thoughts on this are welcome.
>
> ron
>
> On Fri, Jun 30, 2017 at 6:01 AM Alexander Couzens <lynxis(a)fe80.eu> wrote:
>
> > On Fri, 30 Jun 2017 04:25:06 +0000
> > ron minnich <rminnich(a)gmail.com> wrote:
> >
> > > there's something I am certain I don't understand about SMM on intel
> > > chipsets.
> > >
> > > The question is pretty simple. Consider a system with a recent intel
> > > chipset and flash. Is there some special secret sauce that disables
> > > writing to flash unless in SMM and if so, what is it?
> >
> > There is also a talk explaining it (without SMM_BWP).
> >
> >
> > https://media.ccc.de/v/31c3_-_6129_-_en_-_saal_2_-_201412282030_-_attacks...
> >
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
2 years, 1 month
Re: [coreboot] question on SMM
by Alexander Couzens
On Fri, 30 Jun 2017 04:25:06 +0000
ron minnich <rminnich(a)gmail.com> wrote:
> there's something I am certain I don't understand about SMM on intel
> chipsets.
>
> The question is pretty simple. Consider a system with a recent intel
> chipset and flash. Is there some special secret sauce that disables
> writing to flash unless in SMM and if so, what is it?
There is also a talk explaining it (without SMM_BWP).
https://media.ccc.de/v/31c3_-_6129_-_en_-_saal_2_-_201412282030_-_attacks...
2 years, 1 month
New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com
Hi,
Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan.
31 new defect(s) introduced to coreboot found with Coverity Scan.
24 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 20 of 31 defect(s)
** CID 1376829: (OVERRUN)
________________________________________________________________________________________________________
*** CID 1376829: (OVERRUN)
/3rdparty/chromeec/power/intel_x86.c: 403 in common_intel_x86_handle_rsmrst()
397 {
398 /*
399 * Pass through RSMRST asynchronously, as PCH may not react
400 * immediately to power changes.
401 */
402 int rsmrst_in = gpio_get_level(GPIO_RSMRST_L_PGOOD);
>>> CID 1376829: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_RSMRST_L" in call to "gpio_get_level".
403 int rsmrst_out = gpio_get_level(GPIO_PCH_RSMRST_L);
404
405 /* Nothing to do. */
406 if (rsmrst_in == rsmrst_out)
407 return;
408
/3rdparty/chromeec/power/intel_x86.c: 426 in common_intel_x86_handle_rsmrst()
420 * and deasserting RSMRST to PCH.
421 */
422 if (rsmrst_in)
423 msleep(10);
424 #endif
425
>>> CID 1376829: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_RSMRST_L" in call to "gpio_set_level".
426 gpio_set_level(GPIO_PCH_RSMRST_L, rsmrst_in);
427
428 CPRINTS("Pass through GPIO_RSMRST_L_PGOOD: %d", rsmrst_in);
** CID 1353202: Memory - corruptions (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353202: Memory - corruptions (OVERRUN)
/3rdparty/chromeec/board/oak/board.c: 204 in board_extpower_buffer_to_soc()
198 * There is a level shift for AC_OK & LID_OPEN signal between AP & EC,
199 * disable it (drive high) when AP is off, otherwise enable it (drive low).
200 */
201 static void board_extpower_buffer_to_soc(void)
202 {
203 /* Drive high when AP is off (G3), else drive low */
>>> CID 1353202: Memory - corruptions (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_LEVEL_SHIFT_EN_L" in call to "gpio_set_level".
204 gpio_set_level(GPIO_LEVEL_SHIFT_EN_L,
205 chipset_in_state(CHIPSET_STATE_HARD_OFF) ? 1 : 0);
206 }
207
208 /* Initialize board. */
209 static void board_init(void)
** CID 1353187: Memory - corruptions (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353187: Memory - corruptions (OVERRUN)
/3rdparty/chromeec/board/glados/board.c: 265 in board_extpower()
259
260 /**
261 * Buffer the AC present GPIO to the PCH.
262 */
263 static void board_extpower(void)
264 {
>>> CID 1353187: Memory - corruptions (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_ACOK" in call to "gpio_set_level".
265 gpio_set_level(GPIO_PCH_ACOK, extpower_is_present());
266 }
267 DECLARE_HOOK(HOOK_AC_CHANGE, board_extpower, HOOK_PRIO_DEFAULT);
268
269 /**
270 * Set active charge port -- only one port can be active at a time.
** CID 1353185: (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353185: (OVERRUN)
/3rdparty/chromeec/board/chell/board.c: 389 in board_chipset_startup()
383 }
384 }
385
386 /* Called on AP S5 -> S3 transition */
387 static void board_chipset_startup(void)
388 {
>>> CID 1353185: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_USB1_ENABLE" in call to "gpio_set_level".
389 gpio_set_level(GPIO_USB1_ENABLE, 1);
390 gpio_set_level(GPIO_ENABLE_TOUCHPAD, 1);
391 }
392 DECLARE_HOOK(HOOK_CHIPSET_STARTUP, board_chipset_startup, HOOK_PRIO_DEFAULT);
393
394 /* Called on AP S3 -> S5 transition */
/3rdparty/chromeec/board/chell/board.c: 390 in board_chipset_startup()
384 }
385
386 /* Called on AP S5 -> S3 transition */
387 static void board_chipset_startup(void)
388 {
389 gpio_set_level(GPIO_USB1_ENABLE, 1);
>>> CID 1353185: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_ENABLE_TOUCHPAD" in call to "gpio_set_level".
390 gpio_set_level(GPIO_ENABLE_TOUCHPAD, 1);
391 }
392 DECLARE_HOOK(HOOK_CHIPSET_STARTUP, board_chipset_startup, HOOK_PRIO_DEFAULT);
393
394 /* Called on AP S3 -> S5 transition */
395 static void board_chipset_shutdown(void)
** CID 1353184: (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353184: (OVERRUN)
/3rdparty/chromeec/board/oak/board.c: 605 in board_chipset_shutdown()
599 DECLARE_HOOK(HOOK_CHIPSET_PRE_INIT, board_chipset_pre_init, HOOK_PRIO_DEFAULT);
600
601 /* Called on AP S3 -> S5 transition */
602 static void board_chipset_shutdown(void)
603 {
604 /* Disable level shift to SoC when shutting down */
>>> CID 1353184: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_LEVEL_SHIFT_EN_L" in call to "gpio_set_level".
605 gpio_set_level(GPIO_LEVEL_SHIFT_EN_L, 1);
606 #if BOARD_REV >= OAK_REV5
607 /* Disable DP muxer */
608 gpio_set_level(GPIO_DP_MUX_EN_L , 1);
609 gpio_set_level(GPIO_PARADE_MUX_EN, 0);
610 #endif
/3rdparty/chromeec/board/oak/board.c: 608 in board_chipset_shutdown()
602 static void board_chipset_shutdown(void)
603 {
604 /* Disable level shift to SoC when shutting down */
605 gpio_set_level(GPIO_LEVEL_SHIFT_EN_L, 1);
606 #if BOARD_REV >= OAK_REV5
607 /* Disable DP muxer */
>>> CID 1353184: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_DP_MUX_EN_L" in call to "gpio_set_level".
608 gpio_set_level(GPIO_DP_MUX_EN_L , 1);
609 gpio_set_level(GPIO_PARADE_MUX_EN, 0);
610 #endif
611 }
612 DECLARE_HOOK(HOOK_CHIPSET_SHUTDOWN, board_chipset_shutdown, HOOK_PRIO_DEFAULT);
613
/3rdparty/chromeec/board/oak/board.c: 609 in board_chipset_shutdown()
603 {
604 /* Disable level shift to SoC when shutting down */
605 gpio_set_level(GPIO_LEVEL_SHIFT_EN_L, 1);
606 #if BOARD_REV >= OAK_REV5
607 /* Disable DP muxer */
608 gpio_set_level(GPIO_DP_MUX_EN_L , 1);
>>> CID 1353184: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PARADE_MUX_EN" in call to "gpio_set_level".
609 gpio_set_level(GPIO_PARADE_MUX_EN, 0);
610 #endif
611 }
612 DECLARE_HOOK(HOOK_CHIPSET_SHUTDOWN, board_chipset_shutdown, HOOK_PRIO_DEFAULT);
613
614
/3rdparty/chromeec/board/chell/board.c: 397 in board_chipset_shutdown()
391 }
392 DECLARE_HOOK(HOOK_CHIPSET_STARTUP, board_chipset_startup, HOOK_PRIO_DEFAULT);
393
394 /* Called on AP S3 -> S5 transition */
395 static void board_chipset_shutdown(void)
396 {
>>> CID 1353184: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_USB1_ENABLE" in call to "gpio_set_level".
397 gpio_set_level(GPIO_USB1_ENABLE, 0);
398 gpio_set_level(GPIO_ENABLE_TOUCHPAD, 0);
399 }
400 DECLARE_HOOK(HOOK_CHIPSET_SHUTDOWN, board_chipset_shutdown, HOOK_PRIO_DEFAULT);
401
402 /* Called on AP S3 -> S0 transition */
/3rdparty/chromeec/board/chell/board.c: 398 in board_chipset_shutdown()
392 DECLARE_HOOK(HOOK_CHIPSET_STARTUP, board_chipset_startup, HOOK_PRIO_DEFAULT);
393
394 /* Called on AP S3 -> S5 transition */
395 static void board_chipset_shutdown(void)
396 {
397 gpio_set_level(GPIO_USB1_ENABLE, 0);
>>> CID 1353184: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_ENABLE_TOUCHPAD" in call to "gpio_set_level".
398 gpio_set_level(GPIO_ENABLE_TOUCHPAD, 0);
399 }
400 DECLARE_HOOK(HOOK_CHIPSET_SHUTDOWN, board_chipset_shutdown, HOOK_PRIO_DEFAULT);
401
402 /* Called on AP S3 -> S0 transition */
403 static void board_chipset_resume(void)
** CID 1353182: Memory - corruptions (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353182: Memory - corruptions (OVERRUN)
/3rdparty/chromeec/board/chell/usb_pd_policy.c: 297 in svdm_dp_post_config()
291 static void svdm_dp_post_config(int port)
292 {
293 dp_flags[port] |= DP_FLAGS_DP_ON;
294 if (!(dp_flags[port] & DP_FLAGS_HPD_HI_PENDING))
295 return;
296
>>> CID 1353182: Memory - corruptions (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "port ? GPIO_USB_C1_DP_HPD : GPIO_USB_C0_DP_HPD" (which evaluates to 53) in call to "gpio_set_level".
297 gpio_set_level(PORT_TO_HPD(port), 1);
298
299 /* set the minimum time delay (2ms) for the next HPD IRQ */
300 hpd_deadline[port] = get_time().val + HPD_USTREAM_DEBOUNCE_LVL;
301 }
302
** CID 1376828: Uninitialized variables (UNINIT)
/3rdparty/chromeec/util/genvif.c: 296 in write_pdo_to_vif()
________________________________________________________________________________________________________
*** CID 1376828: Uninitialized variables (UNINIT)
/3rdparty/chromeec/util/genvif.c: 296 in write_pdo_to_vif()
290 pnum, current);
291 else
292 fprintf(vif, "Snk_PDO_Op_Current%d: %d\r\n",
293 pnum, current);
294 }
295
>>> CID 1376828: Uninitialized variables (UNINIT)
>>> Using uninitialized value "power".
296 return power;
297 }
298
299 /**
300 * Carriage and line feed, '\r\n', is needed because the file is processed
301 * on a Windows machine.
** CID 1376827: (OVERRUN)
________________________________________________________________________________________________________
*** CID 1376827: (OVERRUN)
/3rdparty/chromeec/board/oak/board.c: 595 in board_chipset_pre_init()
589 static void board_chipset_pre_init(void)
590 {
591 /* Enable level shift of AC_OK when power on */
592 board_extpower_buffer_to_soc();
593 #if BOARD_REV >= OAK_REV5
594 /* Enable DP muxer */
>>> CID 1376827: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_DP_MUX_EN_L" in call to "gpio_set_level".
595 gpio_set_level(GPIO_DP_MUX_EN_L , 0);
596 gpio_set_level(GPIO_PARADE_MUX_EN, 1);
597 #endif
598 }
599 DECLARE_HOOK(HOOK_CHIPSET_PRE_INIT, board_chipset_pre_init, HOOK_PRIO_DEFAULT);
600
/3rdparty/chromeec/board/oak/board.c: 596 in board_chipset_pre_init()
590 {
591 /* Enable level shift of AC_OK when power on */
592 board_extpower_buffer_to_soc();
593 #if BOARD_REV >= OAK_REV5
594 /* Enable DP muxer */
595 gpio_set_level(GPIO_DP_MUX_EN_L , 0);
>>> CID 1376827: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PARADE_MUX_EN" in call to "gpio_set_level".
596 gpio_set_level(GPIO_PARADE_MUX_EN, 1);
597 #endif
598 }
599 DECLARE_HOOK(HOOK_CHIPSET_PRE_INIT, board_chipset_pre_init, HOOK_PRIO_DEFAULT);
600
601 /* Called on AP S3 -> S5 transition */
** CID 1376826: Memory - illegal accesses (UNINIT)
/3rdparty/chromeec/util/genvif.c: 528 in main()
________________________________________________________________________________________________________
*** CID 1376826: Memory - illegal accesses (UNINIT)
/3rdparty/chromeec/util/genvif.c: 528 in main()
522
523 default:
524 abort();
525 }
526 } while (nopt != -1);
527
>>> CID 1376826: Memory - illegal accesses (UNINIT)
>>> Using uninitialized value "board".
528 if (out == NULL || board == NULL)
529 return 1;
530
531 /* Make sure VIF directory exists */
532 vifdir = opendir(out);
533 if (vifdir == NULL) {
** CID 1376825: Control flow issues (DEADCODE)
/3rdparty/chromeec/driver/tcpm/tcpci.c: 390 in tcpci_get_chip_info()
________________________________________________________________________________________________________
*** CID 1376825: Control flow issues (DEADCODE)
/3rdparty/chromeec/driver/tcpm/tcpci.c: 390 in tcpci_get_chip_info()
384 /* Even if the chip doesn't implement get_fw_version, we
385 * return success.*/
386 val = -1;
387 error = EC_SUCCESS;
388 }
389 if (error)
>>> CID 1376825: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "return error;".
390 return error;
391 /* This may vary chip to chip. For now everything fits in this format */
392 i->fw_version_number = val;
393
394 return EC_SUCCESS;
395 }
** CID 1376824: Memory - illegal accesses (UNINIT)
/3rdparty/chromeec/util/genvif.c: 528 in main()
________________________________________________________________________________________________________
*** CID 1376824: Memory - illegal accesses (UNINIT)
/3rdparty/chromeec/util/genvif.c: 528 in main()
522
523 default:
524 abort();
525 }
526 } while (nopt != -1);
527
>>> CID 1376824: Memory - illegal accesses (UNINIT)
>>> Using uninitialized value "out".
528 if (out == NULL || board == NULL)
529 return 1;
530
531 /* Make sure VIF directory exists */
532 vifdir = opendir(out);
533 if (vifdir == NULL) {
** CID 1353302: Memory - illegal accesses (OVERRUN)
/3rdparty/chromeec/chip/stm32/keyboard_raw.c: 66 in keyboard_raw_drive_column()
________________________________________________________________________________________________________
*** CID 1353302: Memory - illegal accesses (OVERRUN)
/3rdparty/chromeec/chip/stm32/keyboard_raw.c: 66 in keyboard_raw_drive_column()
60
61 for (i = 0; i < ARRAY_SIZE(kb_out_ports); i++) {
62 uint32_t bsrr = 0;
63 int j;
64
65 for (j = GPIO_KB_OUT00; j <= GPIO_KB_OUT12; j++) {
>>> CID 1353302: Memory - illegal accesses (OVERRUN)
>>> Overrunning array "gpio_list" of 44 16-byte elements at element index 47 (byte offset 752) using index "j" (which evaluates to 47).
66 if (gpio_list[j].port != kb_out_ports[i])
67 continue;
68
69 if (out == KEYBOARD_COLUMN_ALL) {
70 /* drive low (clear bit) */
71 bsrr |= gpio_list[j].mask << 16;
** CID 1353276: Memory - corruptions (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353276: Memory - corruptions (OVERRUN)
/3rdparty/chromeec/board/chell/usb_pd_policy.c: 348 in svdm_exit_dp_mode()
342 return 1;
343 }
344
345 static void svdm_exit_dp_mode(int port)
346 {
347 svdm_safe_dp_mode(port);
>>> CID 1353276: Memory - corruptions (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "port ? GPIO_USB_C1_DP_HPD : GPIO_USB_C0_DP_HPD" (which evaluates to 53) in call to "gpio_set_level".
348 gpio_set_level(PORT_TO_HPD(port), 0);
349 }
350
351 static int svdm_enter_gfu_mode(int port, uint32_t mode_caps)
352 {
353 /* Always enter GFU mode */
** CID 1353275: (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353275: (OVERRUN)
/3rdparty/chromeec/board/samus/power_sequence.c: 108 in chipset_reset_rtc()
102 {
103 /*
104 * Assert RTCRST# to the PCH long enough for it to latch the
105 * assertion and reset the internal RTC backed state.
106 */
107 CPRINTS("Asserting RTCRST# to PCH");
>>> CID 1353275: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_RTCRST_L" in call to "gpio_set_level".
108 gpio_set_level(GPIO_PCH_RTCRST_L, 0);
109 udelay(100);
110 gpio_set_level(GPIO_PCH_RTCRST_L, 1);
111 udelay(10 * MSEC);
112 }
113
/3rdparty/chromeec/board/samus/power_sequence.c: 110 in chipset_reset_rtc()
104 * Assert RTCRST# to the PCH long enough for it to latch the
105 * assertion and reset the internal RTC backed state.
106 */
107 CPRINTS("Asserting RTCRST# to PCH");
108 gpio_set_level(GPIO_PCH_RTCRST_L, 0);
109 udelay(100);
>>> CID 1353275: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_RTCRST_L" in call to "gpio_set_level".
110 gpio_set_level(GPIO_PCH_RTCRST_L, 1);
111 udelay(10 * MSEC);
112 }
113
114 void chipset_reset(int cold_reset)
115 {
** CID 1353274: (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353274: (OVERRUN)
/3rdparty/chromeec/board/samus/power_sequence.c: 564 in lb_power()
558 */
559 if (enabled) {
560 i2c_lock(I2C_PORT_LIGHTBAR, 1);
561 msleep(10);
562 }
563
>>> CID 1353274: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_LIGHTBAR_RESET_L" in call to "gpio_get_level".
564 if (enabled != gpio_get_level(GPIO_LIGHTBAR_RESET_L)) {
565 ret = 1;
566 gpio_set_level(GPIO_LIGHTBAR_RESET_L, enabled);
567 msleep(1);
568 }
569 if (enabled) {
/3rdparty/chromeec/board/samus/power_sequence.c: 566 in lb_power()
560 i2c_lock(I2C_PORT_LIGHTBAR, 1);
561 msleep(10);
562 }
563
564 if (enabled != gpio_get_level(GPIO_LIGHTBAR_RESET_L)) {
565 ret = 1;
>>> CID 1353274: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_LIGHTBAR_RESET_L" in call to "gpio_set_level".
566 gpio_set_level(GPIO_LIGHTBAR_RESET_L, enabled);
567 msleep(1);
568 }
569 if (enabled) {
570 lb_init(0);
571 msleep(100);
** CID 1353262: (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353262: (OVERRUN)
/3rdparty/chromeec/board/samus/power_sequence.c: 76 in chipset_force_shutdown()
70 CPRINTS("%s()", __func__);
71
72 /*
73 * Force off. This condition will reset once the state machine
74 * transitions to G3.
75 */
>>> CID 1353262: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_DPWROK" in call to "gpio_set_level".
76 gpio_set_level(GPIO_PCH_DPWROK, 0);
77 gpio_set_level(GPIO_PCH_RSMRST_L, 0);
78 }
79
80 static void chipset_force_g3(void)
81 {
/3rdparty/chromeec/board/samus/power_sequence.c: 77 in chipset_force_shutdown()
71
72 /*
73 * Force off. This condition will reset once the state machine
74 * transitions to G3.
75 */
76 gpio_set_level(GPIO_PCH_DPWROK, 0);
>>> CID 1353262: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_RSMRST_L" in call to "gpio_set_level".
77 gpio_set_level(GPIO_PCH_RSMRST_L, 0);
78 }
79
80 static void chipset_force_g3(void)
81 {
82 CPRINTS("Forcing G3");
/3rdparty/chromeec/power/braswell.c: 67 in chipset_force_shutdown()
61 * Force power off. This condition will reset once the state machine
62 * transitions to G3.
63 */
64 #ifndef CONFIG_PMIC
65 gpio_set_level(GPIO_PCH_SYS_PWROK, 0);
66 #endif
>>> CID 1353262: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_RSMRST_L" in call to "gpio_set_level".
67 gpio_set_level(GPIO_PCH_RSMRST_L, 0);
68 forcing_shutdown = 1;
69 }
70
71 void chipset_reset(int cold_reset)
72 {
** CID 1353259: (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353259: (OVERRUN)
/3rdparty/chromeec/board/samus/power_sequence.c: 85 in chipset_force_g3()
79
80 static void chipset_force_g3(void)
81 {
82 CPRINTS("Forcing G3");
83
84 gpio_disable_interrupt(GPIO_VCORE_PGOOD);
>>> CID 1353259: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_PWROK" in call to "gpio_set_level".
85 gpio_set_level(GPIO_PCH_PWROK, 0);
86 gpio_set_level(GPIO_SYS_PWROK, 0);
87 gpio_set_level(GPIO_PP1050_EN, 0);
88 gpio_set_level(GPIO_PP1200_EN, 0);
89 gpio_set_level(GPIO_PP1800_EN, 0);
90 gpio_set_level(GPIO_PP3300_DSW_GATED_EN, 0);
/3rdparty/chromeec/board/samus/power_sequence.c: 95 in chipset_force_g3()
89 gpio_set_level(GPIO_PP1800_EN, 0);
90 gpio_set_level(GPIO_PP3300_DSW_GATED_EN, 0);
91 gpio_set_level(GPIO_PP5000_USB_EN, 0);
92 /* Disable PP5000 if allowed */
93 if (!pp5000_in_g3)
94 gpio_set_level(GPIO_PP5000_EN, 0);
>>> CID 1353259: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_RSMRST_L" in call to "gpio_set_level".
95 gpio_set_level(GPIO_PCH_RSMRST_L, 0);
96 gpio_set_level(GPIO_PCH_DPWROK, 0);
97 gpio_set_level(GPIO_PP3300_DSW_EN, 0);
98 wireless_set_state(WIRELESS_OFF);
99 }
100
/3rdparty/chromeec/board/samus/power_sequence.c: 96 in chipset_force_g3()
90 gpio_set_level(GPIO_PP3300_DSW_GATED_EN, 0);
91 gpio_set_level(GPIO_PP5000_USB_EN, 0);
92 /* Disable PP5000 if allowed */
93 if (!pp5000_in_g3)
94 gpio_set_level(GPIO_PP5000_EN, 0);
95 gpio_set_level(GPIO_PCH_RSMRST_L, 0);
>>> CID 1353259: (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_DPWROK" in call to "gpio_set_level".
96 gpio_set_level(GPIO_PCH_DPWROK, 0);
97 gpio_set_level(GPIO_PP3300_DSW_EN, 0);
98 wireless_set_state(WIRELESS_OFF);
99 }
100
101 static void chipset_reset_rtc(void)
** CID 1353251: Memory - corruptions (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353251: Memory - corruptions (OVERRUN)
/3rdparty/chromeec/common/usb_port_power_smart.c: 41 in usb_charge_set_control_mode()
35 #ifdef CONFIG_USB_PORT_POWER_SMART_SIMPLE
36 /*
37 * One single shared control signal, so the last mode set to either
38 * port wins. Also, only CTL1 can be set; the other pins are
39 * hard-wired.
40 */
>>> CID 1353251: Memory - corruptions (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_USB_CTL1" in call to "gpio_set_level".
41 gpio_set_level(GPIO_USB_CTL1, mode & 0x4);
42 #else
43 if (port_id == 0) {
44 gpio_set_level(GPIO_USB1_CTL1, mode & 0x4);
45 gpio_set_level(GPIO_USB1_CTL2, mode & 0x2);
46 gpio_set_level(GPIO_USB1_CTL3, mode & 0x1);
** CID 1353242: Memory - corruptions (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353242: Memory - corruptions (OVERRUN)
/3rdparty/chromeec/power/tegra.c: 134 in set_ap_reset()
128 * @param asserted Assert (=1) or deassert (=0) the signal. This is the
129 * logical level of the pin, not the physical level.
130 */
131 static void set_ap_reset(int asserted)
132 {
133 /* Signal is active-low */
>>> CID 1353242: Memory - corruptions (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_AP_RESET_L" in call to "gpio_set_level".
134 gpio_set_level(GPIO_AP_RESET_L, asserted ? 0 : 1);
135 }
136
137 /**
138 * Set the PMIC PWRON signal.
139 *
** CID 1353226: Memory - corruptions (OVERRUN)
________________________________________________________________________________________________________
*** CID 1353226: Memory - corruptions (OVERRUN)
/3rdparty/chromeec/board/samus/extpower.c: 70 in extpower_shutdown()
64 }
65 DECLARE_HOOK(HOOK_CHIPSET_PRE_INIT, extpower_buffer_to_pch, HOOK_PRIO_DEFAULT);
66
67 static void extpower_shutdown(void)
68 {
69 /* Drive ACOK buffer to PCH low when shutting down */
>>> CID 1353226: Memory - corruptions (OVERRUN)
>>> Overrunning callee's array of size 44 by passing argument "GPIO_PCH_ACOK" in call to "gpio_set_level".
70 gpio_set_level(GPIO_PCH_ACOK, 0);
71 }
72 DECLARE_HOOK(HOOK_CHIPSET_SHUTDOWN, extpower_shutdown, HOOK_PRIO_DEFAULT);
73
74 void extpower_interrupt(enum gpio_signal signal)
75 {
________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0...
To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0...
2 years, 1 month
