-----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-----
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.
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
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
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
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
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
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...
