coreboot July 2017

coreboot@coreboot.org

54 participants
131 discussions

Re: [coreboot] Ethernet/Wifi not working with coreboot/seabios/me_cleaner on a Thinkpad x230
by John Lewis 04 Jul '17

04 Jul '17

Hi Guys, On Chromebooks, it's quite easy for the time to go completely wrong because of no CMOS battery (so you lose the time and get something stupid if the battery completely drains or is disconnected), which then stops Network Manager from being able to connect (at least with wifi), for reasons best known to devs ... In systemd based distros you need to use timedatectl to correct such a situation. If it's not that then please ignore me. Regards, John. On 04/07/17 13:27, Zoran Stojsavljevic wrote: > Hello Marcel, > > Which OS you are using on the top of Coreboot/SeaBIOS? I assume Linux. > If Linux, could you, please, post your complete dmesg log of the > current session after you are fully up and running user space? > > Thank you, > Zoran > > On Mon, Jul 3, 2017 at 5:23 PM, Marcel Maci <elpinguino(a)gmx.ch > <mailto:elpinguino@gmx.ch>> wrote: > > > Hi, I've flashed coreboot with seaBIOS and me_cleaner to my Thinkpad > x230 and everything works fine except the network. Neither wifi nor > ethernet works. Could this be a problem with the gbe.bin I've used > (I extracted it with ifdtool -x from the factory bios and the first > time I did this on another Thinkpad x230 it worked perfectly)? > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot > <https://mail.coreboot.org/mailman/listinfo/coreboot> > > > >

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 04 Jul '17

04 Jul '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1376956: Memory - illegal accesses (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/cpuF15MmioMap.c: 236 in cpuF15AddingMmioMap() ________________________________________________________________________________________________________ *** CID 1376956: Memory - illegal accesses (OVERRUN) /src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/cpuF15MmioMap.c: 236 in cpuF15AddingMmioMap() 230 // ____________ 231 // | | 232 // new base new limit 233 234 MmioRange[MmioPair].Base = (MmioRange[MmioPair].Base <= NewMmioRange.Base) ? MmioRange[MmioPair].Base : NewMmioRange.Base; 235 MmioRange[MmioPair].Modified = TRUE; >>> CID 1376956: Memory - illegal accesses (OVERRUN) >>> Overrunning array "MmioRange" of 12 20-byte elements at element index 12 (byte offset 240) using index "MmioPair + i" (which evaluates to 12). 236 for (i = 1; NewMmioRange.Limit >= MmioRange[MmioPair + i].Base; i++) { 237 if ((NewMmioRange.Attribute.MmioPostedRange == MmioRange[MmioPair + i].Attribute.MmioPostedRange) && 238 (NewMmioRange.Attribute.MmioReadableRange == MmioRange[MmioPair + i].Attribute.MmioReadableRange) && 239 (NewMmioRange.Attribute.MmioWritableRange == MmioRange[MmioPair + i].Attribute.MmioWritableRange) && 240 (NewMmioRange.Attribute.MmioSecuredRange == MmioRange[MmioPair + i].Attribute.MmioSecuredRange) && 241 (NewMmioRange.Destination.DstNode == MmioRange[MmioPair + i].Destination.DstNode) && ** CID 1376955: Memory - illegal accesses (OVERRUN) /src/vendorcode/amd/agesa/f16kb/Proc/CPU/Family/0x16/cpuF16MmioMap.c: 228 in cpuF16AddingMmioMap() ________________________________________________________________________________________________________ *** CID 1376955: Memory - illegal accesses (OVERRUN) /src/vendorcode/amd/agesa/f16kb/Proc/CPU/Family/0x16/cpuF16MmioMap.c: 228 in cpuF16AddingMmioMap() 222 // ____________ 223 // | | 224 // new base new limit 225 226 MmioRange[MmioPair].Base = (MmioRange[MmioPair].Base <= NewMmioRange.Base) ? MmioRange[MmioPair].Base : NewMmioRange.Base; 227 MmioRange[MmioPair].Modified = TRUE; >>> CID 1376955: Memory - illegal accesses (OVERRUN) >>> Overrunning array "MmioRange" of 12 20-byte elements at element index 12 (byte offset 240) using index "MmioPair + i" (which evaluates to 12). 228 for (i = 1; NewMmioRange.Limit >= MmioRange[MmioPair + i].Base; i++) { 229 if ((NewMmioRange.Attribute.MmioPostedRange == MmioRange[MmioPair + i].Attribute.MmioPostedRange) && 230 (NewMmioRange.Attribute.MmioReadableRange == MmioRange[MmioPair + i].Attribute.MmioReadableRange) && 231 (NewMmioRange.Attribute.MmioWritableRange == MmioRange[MmioPair + i].Attribute.MmioWritableRange) && 232 (NewMmioRange.Attribute.MmioSecuredRange == MmioRange[MmioPair + i].Attribute.MmioSecuredRange)) { 233 MmioRange[MmioPair].Limit = MmioRange[MmioPair + i].Limit; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Overclocking Opteron 6200 from coreboot ?
by BogDan Vatra 04 Jul '17

04 Jul '17

Hello, I finally managed to complete my system [0], even that all CPUs together are *almost* twice faster than my i7, I want to be change *almost* into *more than*, and the only way to do that is to overclock my CPUs (or to buy more expensive ones). Now the big question is: Is it possible to do it from coreboot? If yes, then will the CPU temperature protection still work? E.g. will it turn off the computer if the cpu temp will go above 70 degree Celsius? If is not possible from coreboot, then, will it be possible to do it from Linux? Does anyone has experience on this matter that can share ? Thanks, BogDan. [0] CPU: 2x Opteron 6276 MB: KGPED16 other uninteresting things.

1 0

Re: [coreboot] more smm questions
by ron minnich 03 Jul '17

03 Jul '17

well more later but I now seem to be fighting a bug in qemu. man I hate it when that happens. On Mon, Jul 3, 2017 at 2:10 PM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > Let me also enter this discussion, to clear somehow my ignorance in this > area, which is significant. Last few days I was refreshing my mind about > what I know about SMM and SMI, and the following went out of this research > (in lieu of the Original Post). > > So this is what I understood about SMM, in general, and HSEG, also TSEG. > Let me put some assumption, after I read what I read... ;-) > [1] SMM (as my best understanding is) always runs in real (16 bit) mode; > [2] For HSEG to be visible (ONLY to SMM mode), the *system management RAM > control register* must be programmed in BIOS (register belongs to PCH); > as such the memory around FEEA_0000h-FEEB_FFFFh will be hardcoded to; > [3] For TSEG, the same *system management RAM control register *is > programmed, with some to 8MB of memory, beneath PCIe devices DRAM mapping, > and this memory is NOT visible to OS (as well as HSEG); > [4] Once SMI is entered, there are very complex mechanisms of HW shadowing > executed in background, not visible to SW guys; in nutshell, the following > will happen... > [A] HSEG will be remapped to A0000 - BFFFF by HW; > [B] Parts of TSEG will be remapped beneath A0000 by HW (where real > mode memory resides); > > Now, the following is to happen: the SMI handler will save the current > core context in SMRAM/TSEG, using SMBASE value. Then, all cores except one > (have no idea how this core is delegated - probably BSP core) will enter > sleep state. The lowest core 0 will have SMBASE: 3000(0)h + constant 8000, > where the current core 0 context will be saved (actually by > remapping/shadowing to TSEG), and core 1 will have probably the same SMBASE > + constant, but with the index 1, so its context will be saved in other > region of TSEG... etc! It is some HW magic not completely clear to me!? > > More or less, this is the theory. This is how I understood it, people. > > Floor all yours. Please, continue discussion. > > Zoran > On Mon, Jul 3, 2017 at 7:01 PM, ron minnich <rminnich(a)gmail.com> wrote: > >> I've got a question right at this code: >> >> https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94a… >> >> /* Check revision to see if AMD64 style SMM_BASE >> * Intel Core Solo/Duo: 0x30007 >> * Intel Core2 Solo/Duo: 0x30100 >> * Intel SandyBridge: 0x30101 >> * AMD64: 0x3XX64 >> * This check does not make much sense, unless someone ports >> * SMI handling to AMD64 CPUs. >> */ >> >> mov $0x38000 + 0x7efc, %ebx >> addr32 mov (%ebx), %al >> cmp $0x64, %al >> je 1f >> >> mov $0x38000 + 0x7ef8, %ebx >> jmp smm_relocate >> 1: >> mov $0x38000 + 0x7f00, %ebx >> >> As I read it, it tests for %al being 0x64 and, if so, it assumes the >> offset is at 7f00. As I read the intel x86 docs, this is wrong, or qemu is >> wrong. As I read the docs and Xeno's writeups, the offset is at 0x7ef8 on >> 64-bit processors. But the ich9 version at least in qemu is 0x20064, and >> that would mean coreboot thinks the register is at 7f00, which it does not >> appear to be. >> >> So: am I missing something? does this work on amd64 today? where is the >> offset on modern em64t CPUs? And why does it work on coreboot with q35, >> qemu, and multiple cores if this offset is wrong? >> >> Also, a different question. The offset at 7ef8 is a 32-bit number on >> 64-bit systems. It seems to me this implies that the the save state can be >> located anywhere in the low 4G memory on a per-core basis. I'm a bit lost >> on the need for the large contiguous SMM save state area. >> >> So, for example, it seems to me we could leave a very small SMM stub at >> 0xa0000, and as long as it had a simple way to set its offset at 7ef8 it >> could put its save state at any convenient location. Why do we need the >> giant contiguous memory area for save state if this is the case? >> >> The main motivation for the TSEG seems to be the requirement of the large >> contiguous save state area for SMM, but I don't see anything that says it >> has to be physically contiguous, given the existence of the 32-bit offset. >> >> Current status btw is that linux is able to set up the relocation area >> and I'm able to run SMIs from the command line and the code Linux sets up >> gets run. >> >> It seems to me we ought to be able to break a lot of these fixed address >> issues and as a result reduce attack surface, but we'll see. I'm got lots >> of ignorance, little knowledge, and this can be good or bad :-) >> >> ron >> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >

1 0

Re: [coreboot] more smm questions
by Zoran Stojsavljevic 03 Jul '17

03 Jul '17

Let me also enter this discussion, to clear somehow my ignorance in this area, which is significant. Last few days I was refreshing my mind about what I know about SMM and SMI, and the following went out of this research (in lieu of the Original Post). So this is what I understood about SMM, in general, and HSEG, also TSEG. Let me put some assumption, after I read what I read... ;-) [1] SMM (as my best understanding is) always runs in real (16 bit) mode; [2] For HSEG to be visible (ONLY to SMM mode), the *system management RAM control register* must be programmed in BIOS (register belongs to PCH); as such the memory around FEEA_0000h-FEEB_FFFFh will be hardcoded to; [3] For TSEG, the same *system management RAM control register *is programmed, with some to 8MB of memory, beneath PCIe devices DRAM mapping, and this memory is NOT visible to OS (as well as HSEG); [4] Once SMI is entered, there are very complex mechanisms of HW shadowing executed in background, not visible to SW guys; in nutshell, the following will happen... [A] HSEG will be remapped to A0000 - BFFFF by HW; [B] Parts of TSEG will be remapped beneath A0000 by HW (where real mode memory resides); Now, the following is to happen: the SMI handler will save the current core context in SMRAM/TSEG, using SMBASE value. Then, all cores except one (have no idea how this core is delegated - probably BSP core) will enter sleep state. The lowest core 0 will have SMBASE: 3000(0)h + constant 8000, where the current core 0 context will be saved (actually by remapping/shadowing to TSEG), and core 1 will have probably the same SMBASE + constant, but with the index 1, so its context will be saved in other region of TSEG... etc! It is some HW magic not completely clear to me!? More or less, this is the theory. This is how I understood it, people. Floor all yours. Please, continue discussion. Zoran On Mon, Jul 3, 2017 at 7:01 PM, ron minnich <rminnich(a)gmail.com> wrote: > I've got a question right at this code: > https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b > 94acb67e97/src/cpu/x86/smm/smmrelocate.S#L101 > > /* Check revision to see if AMD64 style SMM_BASE > * Intel Core Solo/Duo: 0x30007 > * Intel Core2 Solo/Duo: 0x30100 > * Intel SandyBridge: 0x30101 > * AMD64: 0x3XX64 > * This check does not make much sense, unless someone ports > * SMI handling to AMD64 CPUs. > */ > > mov $0x38000 + 0x7efc, %ebx > addr32 mov (%ebx), %al > cmp $0x64, %al > je 1f > > mov $0x38000 + 0x7ef8, %ebx > jmp smm_relocate > 1: > mov $0x38000 + 0x7f00, %ebx > > As I read it, it tests for %al being 0x64 and, if so, it assumes the > offset is at 7f00. As I read the intel x86 docs, this is wrong, or qemu is > wrong. As I read the docs and Xeno's writeups, the offset is at 0x7ef8 on > 64-bit processors. But the ich9 version at least in qemu is 0x20064, and > that would mean coreboot thinks the register is at 7f00, which it does not > appear to be. > > So: am I missing something? does this work on amd64 today? where is the > offset on modern em64t CPUs? And why does it work on coreboot with q35, > qemu, and multiple cores if this offset is wrong? > > Also, a different question. The offset at 7ef8 is a 32-bit number on > 64-bit systems. It seems to me this implies that the the save state can be > located anywhere in the low 4G memory on a per-core basis. I'm a bit lost > on the need for the large contiguous SMM save state area. > > So, for example, it seems to me we could leave a very small SMM stub at > 0xa0000, and as long as it had a simple way to set its offset at 7ef8 it > could put its save state at any convenient location. Why do we need the > giant contiguous memory area for save state if this is the case? > > The main motivation for the TSEG seems to be the requirement of the large > contiguous save state area for SMM, but I don't see anything that says it > has to be physically contiguous, given the existence of the 32-bit offset. > > Current status btw is that linux is able to set up the relocation area and > I'm able to run SMIs from the command line and the code Linux sets up gets > run. > > It seems to me we ought to be able to break a lot of these fixed address > issues and as a result reduce attack surface, but we'll see. I'm got lots > of ignorance, little knowledge, and this can be good or bad :-) > > ron > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] question on SMM
by Stefan Reinauer 03 Jul '17

03 Jul '17

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 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. 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 <lynxis(a)fe80.eu > <mailto:lynxis@fe80.eu>> wrote: > > On Fri, 30 Jun 2017 04:25:06 +0000 > ron minnich <rminnich(a)gmail.com <mailto:rminnich@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_o… > > Stefan

1 0

Re: [coreboot] more smm questions
by Stefan Reinauer 03 Jul '17

03 Jul '17

On 03-Jul-17 10:01, ron minnich wrote: > I've got a question right at this code: > https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94a… > > /* Check revision to see if AMD64 style SMM_BASE > * Intel Core Solo/Duo: 0x30007 > * Intel Core2 Solo/Duo: 0x30100 > * Intel SandyBridge: 0x30101 > * AMD64: 0x3XX64 > * This check does not make much sense, unless someone ports > * SMI handling to AMD64 CPUs. > */ > > mov $0x38000 + 0x7efc, %ebx > addr32 mov (%ebx), %al > cmp $0x64, %al > je 1f > > mov $0x38000 + 0x7ef8, %ebx > jmp smm_relocate > 1: > mov $0x38000 + 0x7f00, %ebx > > As I read it, it tests for %al being 0x64 and, if so, it assumes the > offset is at 7f00. As I read the intel x86 docs, this is wrong, or > qemu is wrong. As I read the docs and Xeno's writeups, the offset is > at 0x7ef8 on 64-bit processors. But the ich9 version at least in qemu > is 0x20064, and that would mean coreboot thinks the register is at > 7f00, which it does not appear to be. > > So: am I missing something? does this work on amd64 today? where is > the offset on modern em64t CPUs? And why does it work on coreboot with > q35, qemu, and multiple cores if this offset is wrong? Not sure what the issue you are seeing is, but you can assume that Qemu is getting that part of the hardware emulation wrong. What chipset emulations are you trying? Q35? Or Ich9? Do they behave the same? The ICH9 (southbridge) should have very little to do with this particular piece of the code, because it's the southbridge, but the code is dependent on the CPU you emulate. Last time I checked, Qemu could not emulate SMM properly. > > Also, a different question. The offset at 7ef8 is a 32-bit number on > 64-bit systems. It seems to me this implies that the the save state > can be located anywhere in the low 4G memory on a per-core basis. I'm > a bit lost on the need for the large contiguous SMM save state area. This is the code that is used to move the initial SMM offset from 0x38000 to some other place. The safe state is always located at a fixed offset from SMM_BASE. > > So, for example, it seems to me we could leave a very small SMM stub > at 0xa0000, and as long as it had a simple way to set its offset at > 7ef8 it could put its save state at any convenient location. Why do we > need the giant contiguous memory area for save state if this is the case? There is no giant contiguous memory involved. It's only a few hundred bytes for the state. The way we layed it out is to save maximum space when you have a lot of CPU cores. Read the documentation graphics in one of those files. The code (besides the trampoline) is also shared between all cores. > > The main motivation for the TSEG seems to be the requirement of the > large contiguous save state area for SMM, but I don't see anything > that says it has to be physically contiguous, given the existence of > the 32-bit offset. Traditionally you want to protect the SMM handler from being overwritten by the OS. That protection requires a defined (thus contiguous) piece of memory. > > Current status btw is that linux is able to set up the relocation area > and I'm able to run SMIs from the command line and the code Linux sets > up gets run. > > It seems to me we ought to be able to break a lot of these fixed > address issues and as a result reduce attack surface, but we'll see. > I'm got lots of ignorance, little knowledge, and this can be good or > bad :-) There really are no fixed address issues, except for the initial setup (and those will be hard to fix unless you change the silicon) Stefan

1 0

more smm questions
by ron minnich 03 Jul '17

03 Jul '17

I've got a question right at this code: https://github.com/coreboot/coreboot/blob/fec0328c5f653233859d4aec7dae0b94a… /* Check revision to see if AMD64 style SMM_BASE * Intel Core Solo/Duo: 0x30007 * Intel Core2 Solo/Duo: 0x30100 * Intel SandyBridge: 0x30101 * AMD64: 0x3XX64 * This check does not make much sense, unless someone ports * SMI handling to AMD64 CPUs. */ mov $0x38000 + 0x7efc, %ebx addr32 mov (%ebx), %al cmp $0x64, %al je 1f mov $0x38000 + 0x7ef8, %ebx jmp smm_relocate 1: mov $0x38000 + 0x7f00, %ebx As I read it, it tests for %al being 0x64 and, if so, it assumes the offset is at 7f00. As I read the intel x86 docs, this is wrong, or qemu is wrong. As I read the docs and Xeno's writeups, the offset is at 0x7ef8 on 64-bit processors. But the ich9 version at least in qemu is 0x20064, and that would mean coreboot thinks the register is at 7f00, which it does not appear to be. So: am I missing something? does this work on amd64 today? where is the offset on modern em64t CPUs? And why does it work on coreboot with q35, qemu, and multiple cores if this offset is wrong? Also, a different question. The offset at 7ef8 is a 32-bit number on 64-bit systems. It seems to me this implies that the the save state can be located anywhere in the low 4G memory on a per-core basis. I'm a bit lost on the need for the large contiguous SMM save state area. So, for example, it seems to me we could leave a very small SMM stub at 0xa0000, and as long as it had a simple way to set its offset at 7ef8 it could put its save state at any convenient location. Why do we need the giant contiguous memory area for save state if this is the case? The main motivation for the TSEG seems to be the requirement of the large contiguous save state area for SMM, but I don't see anything that says it has to be physically contiguous, given the existence of the 32-bit offset. Current status btw is that linux is able to set up the relocation area and I'm able to run SMIs from the command line and the code Linux sets up gets run. It seems to me we ought to be able to break a lot of these fixed address issues and as a result reduce attack surface, but we'll see. I'm got lots of ignorance, little knowledge, and this can be good or bad :-) ron

1 0

Re: [coreboot] question on SMM
by Igor Skochinsky 02 Jul '17

02 Jul '17

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-… [3] http://composter.com.ua/documents/Exploiting_Flash_Protection_Race_Conditio… [4] https://github.com/chipsec/chipsec/blob/master/chipsec/modules/common/bios_… -- WBR, Igor mailto:roxfan@skynet.be

3 3

Re: [coreboot] question on SMM
by Nico Huber 01 Jul '17

01 Jul '17

On 01.07.2017 02:08, ron minnich wrote: > On Fri, Jun 30, 2017 at 4:28 PM Nico Huber <nico.h(a)gmx.de> 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

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2017