Re: [coreboot] question on SMM

[Stefan Reinauer]

On 30-Jun-17 10: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 0xa, 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.


How do you do the relocation on a system where the vendor bios has 
already relocated the SMM_BASE (i.e. when not running on a machine you 
have the bios source code for)?




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.


SMM was never a blob on coreboot.



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?


You could add the security that your bios implemented back into your 
kernel SMM handler ;-) Look at the open source SMM handler in coreboot 
for how that is done.




Thoughts on this are welcome.

ron

On Fri, Jun 30, 2017 at 6:01 AM Alexander Couzens > wrote:


On Fri, 30 Jun 2017 04:25:06 +
ron minnich > 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_on_uefi_security_inspired_by_darth_venamis_s_misery_and_speed_racer_-_rafal_wojtczuk_-_corey_kallenberg



Stefan
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[ron minnich]

Again, I don't want to pretend this idea is general. Moving SMM to a
linux-as-ramfs payload might work on a small number of servers where we
have lots of control and not much variety. But thanks for the note Melvin.

On Sat, Jul 1, 2017 at 6:39 PM Melvin Walker via coreboot <
coreboot@coreboot.org> wrote:

> I'll correct my own statement.  I think my understanding was from a
> misinterpretation from some marketing material.  Only the authentication
> happens in the ACM, not the flash write.
>
>
> On Saturday, July 1, 2017 7:56 PM, Melvin Walker via coreboot <
> coreboot@coreboot.org> wrote:
>
>
> I don't have a computer with BIOS Guard, but doesn't that move flash
> writes to BIOS_ACM instead of SMM
>
> Melvin
>
>
> On Friday, June 30, 2017 3:06 AM, Igor Skochinsky via coreboot <
> coreboot@coreboot.org> wrote:
>
>
> 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%20-%20BIOS%20and%20SMM%20Internals%20-%20SPI%20Flash%20Protection%20Mechanisms.pdf
>
> [3]
> http://composter.com.ua/documents/Exploiting_Flash_Protection_Race_Condition.pdf
>
> [4]
> https://github.com/chipsec/chipsec/blob/master/chipsec/modules/common/bios_wp.py
> --
> WBR,
> Igormailto:rox...@skynet.be
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[Melvin Walker via coreboot]

I'll correct my own statement.  I think my understanding was from a 
misinterpretation from some marketing material.  Only the authentication 
happens in the ACM, not the flash write.   

On Saturday, July 1, 2017 7:56 PM, Melvin Walker via coreboot 
 wrote:
 

 I don't have a computer with BIOS Guard, but doesn't that move flash writes to 
BIOS_ACM instead of SMM
Melvin 

On Friday, June 30, 2017 3:06 AM, Igor Skochinsky via coreboot 
 wrote:
 

 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%20-%20BIOS%20and%20SMM%20Internals%20-%20SPI%20Flash%20Protection%20Mechanisms.pdf

[3] 
http://composter.com.ua/documents/Exploiting_Flash_Protection_Race_Condition.pdf

[4] 
https://github.com/chipsec/chipsec/blob/master/chipsec/modules/common/bios_wp.py
-- 
WBR,
 Igor                            mailto:rox...@skynet.be


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot


   -- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

   -- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[Melvin Walker via coreboot]

I don't have a computer with BIOS Guard, but doesn't that move flash writes to 
BIOS_ACM instead of SMM
Melvin 

On Friday, June 30, 2017 3:06 AM, Igor Skochinsky via coreboot 
 wrote:
 

 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%20-%20BIOS%20and%20SMM%20Internals%20-%20SPI%20Flash%20Protection%20Mechanisms.pdf

[3] 
http://composter.com.ua/documents/Exploiting_Flash_Protection_Race_Condition.pdf

[4] 
https://github.com/chipsec/chipsec/blob/master/chipsec/modules/common/bios_wp.py
-- 
WBR,
 Igor                            mailto:rox...@skynet.be


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot


   -- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[Nico Huber]

On 01.07.2017 02:08, ron minnich wrote:
> On Fri, Jun 30, 2017 at 4:28 PM Nico Huber  wrote:
> 
>>
>>
>> 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).
>>
>>
> That would be optimal -- just turn it off. We're seeing a problem with
> linux startup, while booting no smm enabled, where Linux really wants to do
> that OSL nonsense via SMI for ACPI. Can we really configure hardware such
> that an SMI is impossible, and will Linux continue to work if we do?

I hope so. I would expect that you can disable all SMIs by simply set-
ting the whole SMI_EN register 0. Some of them can't be routed to SCIs.
Wouldn't expect that you need them, though.

Regarding OSL, does it mean OS Load? It's not in the standard but im-
mediately reminded me of the APMC mechanism to switch from SMI to SCI.
Hope that does the trick: SMI_CMD in the FADT should be set to zero and
you'd have to set SCI_EN manually, I suppose. Spec says about SMI_CMD:

System port address of the SMI Command Port. During ACPI
OS initialization, OSPM can determine that the ACPI
hardware registers are owned by SMI (by way of the SCI_EN
bit), in which case the ACPI OS issues the ACPI_ENABLE
command to the SMI_CMD port. The SCI_EN bit effectively
tracks the ownership of the ACPI hardware registers. OSPM
issues commands to the SMI_CMD port synchronously from
the boot processor. This field is reserved and must be zero on
system that does not support System Management mode.

Other than that, there is the HW-Reduced ACPI Model that doesn't expect
SMM. But I don't know the implications of running that on a system that
isn't designed for it. Might be worth looking into it (ACPI 6.1 Chapters
3.11.1 and 4.1). It's mentioned as being useful for legacy free systems.

> 
> I like your idea a lot -- just do whatever it takes to make SMM interrupts
> turn into normal SCI -- I just don't know for sure it's possible to make it
> happen. But I'll look.
> 
> The remaining problem is the "security" offered by having an SMI gatekeeper
> on the flash. Given the history of such "security" approaches, I suspect
> we're better off without them. BUT, there is concern that if we don't use
> these approaches, there are scenarios where flash gets written by the wrong
> people.

What usually is done is either having a trusted, write-protected part
of the flash that can verify the remaining parts, or enough code in the
flash that can load updates on its own (or a combination of both, write
updates in the rw part first and let the ro part overwrite itself after
verification). You would write-protect (trusted parts of) the flash
before starting the fully-fledged, less trusted OS.

> 
>> 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.
>>
> 
> I agree with you here, but we can only kill one dragon at a time.
> 
> We ran supercomputers at LANL for years, up until 2010 or so, with no SMM
> and ACPI and all was well. I've never quite figured out what problem SMI
> and ACPI solved that could not have been solved better in other ways.

Well, beside fixing issues that ACPI brings with itself, there is a
valid idea underlying: Having an OS-independent way to write board-
specific OS drivers. I would expect the lists of board-specific quirks
(laptops mostly) in Linux to explode without ACPI. But that's just a
feeling...

Much of the SMM/ACPI craft is about legacy compatibility, though. I
guess that's what the HW-reduced model tries to fix.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[ron minnich]

On Fri, Jun 30, 2017 at 4:28 PM Nico Huber  wrote:

>
>
> 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).
>
>
That would be optimal -- just turn it off. We're seeing a problem with
linux startup, while booting no smm enabled, where Linux really wants to do
that OSL nonsense via SMI for ACPI. Can we really configure hardware such
that an SMI is impossible, and will Linux continue to work if we do?

I like your idea a lot -- just do whatever it takes to make SMM interrupts
turn into normal SCI -- I just don't know for sure it's possible to make it
happen. But I'll look.

The remaining problem is the "security" offered by having an SMI gatekeeper
on the flash. Given the history of such "security" approaches, I suspect
we're better off without them. BUT, there is concern that if we don't use
these approaches, there are scenarios where flash gets written by the wrong
people.



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

I agree with you here, but we can only kill one dragon at a time.

We ran supercomputers at LANL for years, up until 2010 or so, with no SMM
and ACPI and all was well. I've never quite figured out what problem SMI
and ACPI solved that could not have been solved better in other ways.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[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 0xa, 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

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[Marc Jones]

On Fri, Jun 30, 2017 at 11:47 AM 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 0xa, 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  wrote:
>
>> On Fri, 30 Jun 2017 04:25:06 +
>> ron minnich  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_on_uefi_security_inspired_by_darth_venamis_s_misery_and_speed_racer_-_rafal_wojtczuk_-_corey_kallenberg
>>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
http://marcjonesconsulting.com
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[Patrick Georgi via coreboot]

2017-06-30 19:46 GMT+02:00 ron minnich :

> 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
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[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 +, 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 0xa, 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  wrote:
> 
> > On Fri, 30 Jun 2017 04:25:06 +
> > ron minnich  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_on_uefi_security_inspired_by_darth_venamis_s_misery_and_speed_racer_-_rafal_wojtczuk_-_corey_kallenberg
> >

> -- 
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[ron minnich]

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 0xa, 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  wrote:

> On Fri, 30 Jun 2017 04:25:06 +
> ron minnich  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_on_uefi_security_inspired_by_darth_venamis_s_misery_and_speed_racer_-_rafal_wojtczuk_-_corey_kallenberg
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[Alexander Couzens]

On Fri, 30 Jun 2017 04:25:06 +
ron minnich  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_on_uefi_security_inspired_by_darth_venamis_s_misery_and_speed_racer_-_rafal_wojtczuk_-_corey_kallenberg


pgphuIb2yHbvn.pgp
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[Igor Skochinsky via coreboot]

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%20-%20BIOS%20and%20SMM%20Internals%20-%20SPI%20Flash%20Protection%20Mechanisms.pdf

[3] 
http://composter.com.ua/documents/Exploiting_Flash_Protection_Race_Condition.pdf

[4] 
https://github.com/chipsec/chipsec/blob/master/chipsec/modules/common/bios_wp.py
-- 
WBR,
 Igormailto:rox...@skynet.be


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] question on SMM

[Nico Huber]

Hi Ron,

On 30.06.2017 06:25, ron minnich 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?

it's a bit in the SPI configuration that Intel encourages everybody to
set (to give SMM a bigger attack surface and make the platform overall
less secure, I suppose?).

> 
> Thanks to anyone who can point me to chapter and verse of a data sheet.

Search for BIOS_CNTL / SMM_BWP in your PCH datasheet or (BIOS_SPI_BC /
EISS from Skylake/100 series on).

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] question on SMM

[ron minnich]

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?

Thanks to anyone who can point me to chapter and verse of a data sheet.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Question about smm handler bin

[fengwei zhang]

Hi all,

I am trying to impelement SMM support for K8/vt8237r, but I am strarking on
build smm handler bin. I understand I need to copy real smm handler to
location 0xa. From the ICH4 example, there are two extern varaibles
binary_smm_start and binary_smm_end, I know it defines in
/build/cpu/x86/smm/smm_wrap.ramstage.o. but how does that work?

Suppose I just want to put RSM instruction in the smmhandler, can I just
write instruction 0f aa(bianry code of RSM) to location 0xa and
0xa0001. I tried this, but my machine went freeze after I invoke SMI.

I am thinking I may need to more instructons, because the SMM start with 16
bits real mode, it may not recongnize the instruction, right?
But I am starking on how to build and copy SMM handler.

I would really appreciate if some one could help me this out.

Best,
Fengwei
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Question about smm handler bin

[Patrick Georgi]

Am 10.11.2010 18:30, schrieb fengwei zhang:
 Suppose I just want to put RSM instruction in the smmhandler, can I just
 write instruction 0f aa(bianry code of RSM) to location 0xa and
 0xa0001. I tried this, but my machine went freeze after I invoke SMI.
I think the SMI entry point is usually 0x8000 into the SMM segment, so
you'd need to put rsm at 0xa8000, not at 0xa.

 I am thinking I may need to more instructons, because the SMM start with
 16 bits real mode, it may not recongnize the instruction, right?
That could be accomodated by .code16 in the assembly code. We have
some semi-generic SMI handler, originally built to support i945/ICH7.
Not sure how much more generic it can be, Stefan might be able to answer
that.


Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Question about smm handler bin

[Rudolf Marek]

Hi all,

Does somebody know how to unlock the Aseg on AMD K8? VIA has some registers in 
K8m890 for that but it seems it does not work. In my implementation I simply did 
the code copy.


Dunno why it does not work the only thing I could think of is that the chipset 
simply returns the PCI read memory cycle back to to memory controller.


http://www.mail-archive.com/coreboot@coreboot.org/msg10310.html

Thanks,
Rudolf

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Question about smm handler bin

[Scott Duplichan]

  _  

From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On 
Behalf Of fengwei zhang
Sent: Wednesday, November 10, 2010 11:30 AM
To: coreboot@coreboot.org
Subject: [coreboot] Question about smm handler bin

 

Hi all,

I am trying to impelement SMM support for K8/vt8237r, but I am strarking on 
build smm handler bin. I understand I need to copy real
smm handler to location 0xa. From the ICH4 example, there are two extern 
varaibles binary_smm_start and binary_smm_end, I know
it defines in /build/cpu/x86/smm/smm_wrap.ramstage.o. but how does that work? 

Suppose I just want to put RSM instruction in the smmhandler, can I just write 
instruction 0f aa(bianry code of RSM) to location
0xa and 0xa0001. I tried this, but my machine went freeze after I invoke 
SMI. 

I am thinking I may need to more instructons, because the SMM start with 16 
bits real mode, it may not recongnize the instruction,
right?
But I am starking on how to build and copy SMM handler. 

I would really appreciate if some one could help me this out. 

Best,
Fengwei

 

 

Hello Fengwei,

 

I think the first instruction executed in your case will be at address A8000. 
The AMD BKDG states:

 

MSRC001_0111[SMM_BASE] + 8000h: SMI handler entry point.

 

As Rudolf said, you need to copy the code into the SMM code space, not the 
legacy video frame buffer space that occupies the same
address range. The BKDG explains how to do this.

 

Thanks,

Scott

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Question about smm handler bin

[Stefan Reinauer]

On 10.11.2010, at 09:30, fengwei zhang namedy...@gmail.com wrote:

 Hi all,
 
 I am trying to impelement SMM support for K8/vt8237r, but I am strarking on 
 build smm handler bin. I understand I need to copy real smm handler to 
 location 0xa. From the ICH4 example, there are two extern varaibles 
 binary_smm_start and binary_smm_end, I know it defines in 
 /build/cpu/x86/smm/smm_wrap.ramstage.o. but how does that work? 

The SMM handler is built as a separate binary and those external variables are 
set by the linker so the relocation code can find it.

 Suppose I just want to put RSM instruction in the smmhandler, can I just 
 write instruction 0f aa(bianry code of RSM) to location 0xa and 
 0xa0001. I tried this, but my machine went freeze after I invoke SMI. 

Besides what Patrick said about putting the code at 0xa8000
your relocation might went wrong. On power-on the SMM entry point is 0x38000 
until it it moved to 0xa8000


 
 I am thinking I may need to more instructons, because the SMM start with 16 
 bits real mode, it may not recongnize the instruction, right?
 But I am starking on how to build and copy SMM handler. 

I strongly suggest that you use and enhance the existing SMM handler. You will 
have to adapt two things
- the code that opens the ASEG for writing from non-SMM (i82801gx_smi.c)
- the north-/southbridge and CPU specific handlers (i82801gx_smihandler.c for 
example)

 I would really appreciate if some one could help me this out. 
 
 Best,
 Fengwei

Stefan
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Question about smm handler bin

[Rudolf Marek]

Yes, thanks for the pointers Scott. It looks enough would be to set the MTRR 
because if A-seg valid is 0 then one can copy it there! Just need to set

MTRRfix16K_A Register and most likely WrMem and RdMem must be set to 1.

Thanks,
Rudolf

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot