coreboot January 2017

coreboot@coreboot.org

75 participants
186 discussions

Re: [coreboot] How does intelmetool's support for Skylake?
by Zoran Stojsavljevic 05 Jan '17

05 Jan '17

Hello Shawn, Happy New Year to you too. I wish you and all Coreboot community to be blessed by Health. :-) Needless to say, I found your changes there, but just yesterday evening. Here they are: https://github.com/zamaudio/intelmetool/commit/052350ae131b34b95f55a56c35e3… I also fetched the latest coreboot few moments the same time, and checked: these changes are not incorporated in the latest Coreboot: 4.5-759-gab8f7d315e So, I'll ask kindly Damien to add these changes into Coreboot (there are a bit more lines that you added there). Damien (Zammit), could you, please, update Coreboot intelmetool with the latest changes? I'll look (later) into two latest net links you have provided to me. :-) Thank you, Zoran On Thu, Jan 5, 2017 at 7:22 AM, Shawn <citypw(a)gmail.com> wrote: > Hi Zoran, > > Happy new year;-) > > intelmetool merged the patch, plz check: > > https://github.com/zamaudio/intelmetool > > If you're going to only neutralize the ME, you can use external > programmer && try me_cleaner: > > https://github.com/corna/me_cleaner/ > > We've only tested a few coreboot supported mainboards on neutralizing > ME( I'm afarid your hardware isn't on the list-_-): > > https://github.com/hardenedlinux/hardenedlinux_ > profiles/tree/master/coreboot > > On Wed, Jan 4, 2017 at 8:28 PM, Zoran Stojsavljevic > <zoran.stojsavljevic(a)gmail.com> wrote: > > Hello Shawn, > > > > I am late, I apologize... New Year, everything is slow, me either. > > > > For me, the link you have provided does not work?! it is HTTP 404 (page > not > > found). Could you, please, repost the valid link? Or to attach the given > > patch to this email? > > > > With the normal Coreboot intelmetool (where I added one more printk() to > > explore what are the device ids the tool looks into), I have the > following: > > > > [root@localhost intelmetool]# uname -a > > Linux localhost.localdomain 4.8.15-300.fc25.x86_64 #1 SMP Thu Dec 15 > > 23:10:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > > [1]+ Done emacs intelmetool.h > > [root@localhost intelmetool]# ./intelmetool -s > > dev->vendor_id = 0x8086, dev->device_id = 0x9c22 > > dev->vendor_id = 0x8086, dev->device_id = 0x9c03 > > dev->vendor_id = 0x8086, dev->device_id = 0x9c43 > > Bad news, you have a `8 Series LPC Controller` so you have ME hardware on > > board and you can't control or disable it, continuing... > > > > Error mapping physical memory 0x0000004275159040 [0x4000] ERRNO=1 > > Segmentation fault (core dumped) > > > > [root@localhost intelmetool]# lspci -nn | grep 9c22 > > 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller > > [8086:9c22] (rev 04) > > [root@localhost intelmetool]# lspci -nn | grep 9c03 > > 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA > Controller 1 > > [AHCI mode] [8086:9c03] (rev 04) > > [root@localhost intelmetool]# lspci -nn | grep 9c43 > > 00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller > > [8086:9c43] (rev 04) > > [root@localhost intelmetool]# > > > > Yet, in intelmetool.h it says explicitly: > > > > // Definitely has ME and is very difficult to remove > > [snap] > > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_FULL 0x9c41 > > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_PREM 0x9c43 > > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_BASE 0x9c45 > > > > Coreboot ME pros, any comment on my HW (i5-4300U HSW ULT + PCH > LynxPoint)? > > Appreciate any help! > > > > Thank you, > > Zoran > > > > On Fri, Dec 30, 2016 at 11:25 AM, Shawn <citypw(a)gmail.com> wrote: > >> > >> This is a work around patch( I think?): > >> > >> https://github.com/hardenedlinux/intelmetool/commit/ > ad778fc347b2bb0494abe2186632a072b8ad1a11 > >> > >> ./intelmetool -s > >> RCBA at 0x00000000 > >> MEI not hidden on PCI, checking if visible > >> MEI found: [8086:9d3a] Sunrise Point-LP CSME HECI > >> > >> ME Status : 0xa0000245 > >> ME Status 2 : 0x86110306 > >> > >> ME: FW Partition Table : OK > >> ME: Bringup Loader Failure : NO > >> ME: Firmware Init Complete : YES > >> ME: Manufacturing Mode : NO > >> ME: Boot Options Present : NO > >> ME: Update In Progress : NO > >> ME: Current Working State : Normal > >> ME: Current Operation State : M0 with UMA > >> ME: Current Operation Mode : Normal > >> ME: Error Code : No Error > >> ME: Progress Phase : Clean Moff->Mx wake > >> ME: Power Management Event : Pseudo-global reset > >> ME: Progress Phase State : Unknown 0x11 > >> > >> PCI READ [bc] : 0x000000bc > >> ME: Extend Register not valid > >> > >> ME seems okay on this board > >> WRITE [00] : CB: 0x80040007 > >> WRITE [00] : CB: 0x000002ff > >> READ [08] : CB: 0x801c0007 > >> READ [08] : CB: 0x000082ff > >> READ [08] : CB: 0x000b0000 > >> READ [08] : CB: 0x0000049c > >> READ [08] : CB: 0x000b0000 > >> READ [08] : CB: 0x0000049c > >> READ [08] : CB: 0x000b0000 > >> READ [08] : CB: 0x0000049c > >> ME: Firmware Version 11.0.1180.0 (code) 11.0.1180.0 (recovery) > >> 11.0.1180.0 (fitc) > >> WRITE [00] : CB: 0x80080007 > >> WRITE [00] : CB: 0x00000203 > >> WRITE [00] : CB: 0x00000000 > >> READ [08] : CB: 0x800d0007 > >> READ [08] : CB: 0x00008203 > >> READ [08] : CB: 0x00000000 > >> READ [08] : CB: 0x111a4004 > >> READ [08] : CB: 0x00000031 > >> ME Capability: Full Network manageability : OFF > >> ME Capability: Regular Network manageability : OFF > >> ME Capability: Manageability : OFF > >> ME Capability: Small business technology : OFF > >> ME Capability: Level III manageability : OFF > >> ME Capability: IntelR Anti-Theft (AT) : OFF > >> ME Capability: IntelR Capability Licensing Service (CLS) : ON > >> ME Capability: IntelR Power Sharing Technology (MPC) : OFF > >> ME Capability: ICC Over Clocking : ON > >> ME Capability: Protected Audio Video Path (PAVP) : ON > >> ME Capability: IPV6 : OFF > >> ME Capability: KVM Remote Control (KVM) : OFF > >> ME Capability: Outbreak Containment Heuristic (OCH) : OFF > >> ME Capability: Virtual LAN (VLAN) : ON > >> ME Capability: TLS : OFF > >> ME Capability: Wireless LAN (WLAN) : OFF > >> exiting > >> > >> On Fri, Dec 30, 2016 at 11:04 AM, Shawn <citypw(a)gmail.com> wrote: > >> > Hi Zoran, > >> > > >> > Thanks for the info. I added my Device ID into the intelmetool.h: > >> > > >> > diff --git a/intelmetool.h b/intelmetool.h > >> > index d79d6b0..16ca43a 100644 > >> > --- a/intelmetool.h > >> > +++ b/intelmetool.h > >> > @@ -225,6 +225,7 @@ > >> > #define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914 > >> > #define PCI_DEVICE_ID_INTEL_ICH9R 0x2916 > >> > #define PCI_DEVICE_ID_INTEL_ICH9 0x2918 > >> > +#define PCI_DEVICE_ID_INTEL_SUNRISE 0x9d3a > >> > > >> > #define PCI_DEV_CAN_DISABLE_ME_IF_PRESENT(x) ( \ > >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH8 ) || \ > >> > @@ -232,6 +233,7 @@ > >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DH ) || \ > >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DO ) || \ > >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9R ) || \ > >> > + ( (x) == PCI_DEVICE_ID_INTEL_SUNRISE ) || \ > >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9 )) > >> > > >> > // Not sure at all > >> > > >> > This one should be the ME? > >> > +-16.0 Intel Corporation Sunrise Point-LP CSME HECI [8086:9d3a] > >> > > >> > #./intelmetool -s > >> > Not sure if ME hardware is present because you have a `Sunrise > >> > Point-LP CSME HECI`, but it is possible to disable it if you do, > >> > continuing... > >> > RCBA at 0x00000000 > >> > MEI not hidden on PCI, checking if visible > >> > MEI device not found, huh? > >> > exiting > >> > > >> > > >> > > >> > On Thu, Dec 29, 2016 at 12:50 AM, Zoran Stojsavljevic > >> > <zoran.stojsavljevic(a)gmail.com> wrote: > >> >>>> I'm not sure if intelmetool support Skylake as well. > >> >> > >> >> Investigated more. The coreboot intelmetool is the latest one, as I > >> >> understood (comparing one from github and coreboot). > >> >> > >> >> And Sunrise Point is NOT supported (look into latest coreboot's > >> >> coreboot/util/intelmetool/intelmetool.h). You can try to add it (as > >> >> Device > >> >> ID), manually, peek around the C code, and see if this can help you. > >> >> > >> >> Zoran > >> >> > >> >> On Wed, Dec 28, 2016 at 5:26 PM, Zoran Stojsavljevic > >> >> <zoran.stojsavljevic(a)gmail.com> wrote: > >> >>> > >> >>> Hello Shawn, > >> >>> > >> >>> Please, follow my CLI transcript from my Future Fedora 26 VM over > >> >>> WIN10 > >> >>> (now rawhide) with Fedora 4.8.15 kernel implanted (kernel 4.10.0-rc0 > >> >>> gives > >> >>> me lot of griefs, I do not trust it, so I eliminated it for now): > >> >>> > >> >>> [zoran@localhost ~]$ cd projects/ > >> >>> [zoran@localhost projects]$ mkdir intelmetool > >> >>> [zoran@localhost projects]$ cd intelmetool/ > >> >>> [zoran@localhost intelmetool]$ pwd > >> >>> /home/zoran/projects/intelmetool > >> >>> [zoran@localhost intelmetool]$ uname -r > >> >>> 4.8.15-300.fc25.x86_64 > >> >>> [zoran@localhost intelmetool]$ git clone > >> >>> https://github.com/zamaudio/intelmetool.git > >> >>> Cloning into 'intelmetool'... > >> >>> remote: Counting objects: 214, done. > >> >>> remote: Total 214 (delta 0), reused 0 (delta 0), pack-reused 214 > >> >>> Receiving objects: 100% (214/214), 72.42 KiB | 0 bytes/s, done. > >> >>> Resolving deltas: 100% (125/125), done. > >> >>> [zoran@localhost intelmetool]$ ls -al > >> >>> total 12 > >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . > >> >>> drwxrwxr-x. 10 zoran zoran 4096 Dec 28 17:05 .. > >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 intelmetool > >> >>> [zoran@localhost intelmetool]$ cd intelmetool/ > >> >>> [zoran@localhost intelmetool]$ ls -al > >> >>> total 100 > >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . > >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. > >> >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git > >> >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore > >> >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c > >> >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h > >> >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE > >> >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile > >> >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c > >> >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h > >> >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c > >> >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c > >> >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h > >> >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md > >> >>> [zoran@localhost intelmetool]$ su -m > >> >>> Password: > >> >>> [root@localhost intelmetool]# make > >> >>> gcc -Wall -O0 -g -I. -c me_status.c -o me_status.o > >> >>> gcc -Wall -O0 -g -I. -c me.c -o me.o > >> >>> me.c: In function ‘mei_dump’: > >> >>> me.c:63:18: warning: variable ‘csr’ set but not used > >> >>> [-Wunused-but-set-variable] > >> >>> struct mei_csr *csr; > >> >>> ^~~ > >> >>> gcc -Wall -O0 -g -I. -c mmap.c -o mmap.o > >> >>> mmap.c: In function ‘map_physical_exact’: > >> >>> mmap.c:11:26: warning: passing argument 1 of ‘mmap’ makes pointer > from > >> >>> integer without a cast [-Wint-conversion] > >> >>> virt_addr = mmap(mapto, len, PROT_WRITE | PROT_READ, > >> >>> MAP_SHARED|MAP_FIXED, > >> >>> ^~~~~ > >> >>> In file included from mmap.h:4:0, > >> >>> from mmap.c:1: > >> >>> /usr/include/sys/mman.h:57:14: note: expected ‘void *’ but argument > is > >> >>> of > >> >>> type ‘uint64_t {aka long unsigned int}’ > >> >>> extern void *mmap (void *__addr, size_t __len, int __prot, > >> >>> ^~~~ > >> >>> gcc -Wall -O0 -g -I. -o intelmetool intelmetool.o me_status.o me.o > >> >>> mmap.o > >> >>> -lpci > >> >>> [root@localhost intelmetool]# date > >> >>> Wed Dec 28 17:07:26 CET 2016 > >> >>> [root@localhost intelmetool]# ls -al > >> >>> total 228 > >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:07 . > >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. > >> >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git > >> >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore > >> >>> -rwxr-xr-x. 1 root root 47008 Dec 28 17:07 intelmetool > >> >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c > >> >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h > >> >>> -rw-rw-r--. 1 zoran zoran 22144 Dec 28 17:06 intelmetool.o > >> >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE > >> >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile > >> >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c > >> >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h > >> >>> -rw-r--r--. 1 root root 28984 Dec 28 17:07 me.o > >> >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c > >> >>> -rw-r--r--. 1 root root 15704 Dec 28 17:07 me_status.o > >> >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c > >> >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h > >> >>> -rw-r--r--. 1 root root 7648 Dec 28 17:07 mmap.o > >> >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md > >> >>> [root@localhost intelmetool]# ./intelmetool > >> >>> ME is not present on your board because we found a `82371AB/EB/MB > >> >>> PIIX4 > >> >>> ISA`, you are safe, exiting > >> >>> [root@localhost intelmetool]# > >> >>> _______ > >> >>> > >> >>> Do NOT forget: I run Fedora rawhide on VMWorkstation 12.5.2 Type 2 > HYP > >> >>> on > >> >>> the top of WIN10 64 Pro! > >> >>> > >> >>> Please, do the same on Mint18 distro on raw HW, and see if this will > >> >>> give > >> >>> you some different results then what you have presently? > >> >>> > >> >>> Please, let us know! > >> >>> > >> >>> Zoran > >> >>> > >> >>> On Wed, Dec 28, 2016 at 11:06 AM, Shawn <citypw(a)gmail.com> wrote: > >> >>>> > >> >>>> Hi Zoran, > >> >>>> > >> >>>> I created hwdb.bin via: > >> >>>> > >> >>>> # udevadm hwdb --update > >> >>>> > >> >>>> The result is still "segfault". dmesg: > >> >>>> > >> >>>> [ 972.044664] intelmetool[5055]: segfault at 16 ip > 000000000040169e > >> >>>> sp 000072ed96a44680 error 4 in intelmetool[400000+6000] > >> >>>> [ 972.044674] grsec: Segmentation fault occurred at > 0000000000000016 > >> >>>> in /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 > >> >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 > >> >>>> [ 972.044685] grsec: denied resource overstep by requesting 4096 > for > >> >>>> RLIMIT_CORE against limit 0 for > >> >>>> /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 > >> >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 > >> >>>> > >> >>>> > >> >>>> On Mon, Dec 26, 2016 at 9:49 PM, Zoran Stojsavljevic > >> >>>> <zoran.stojsavljevic(a)gmail.com> wrote: > >> >>>> > Not sure if your strace log has anything to do with intelmetool. > >> >>>> > > >> >>>> > I did on your strace log the following (and in RED is possible > >> >>>> > cause of > >> >>>> > your > >> >>>> > problems): > >> >>>> > > >> >>>> > [zoran@localhost projects]$ cat crash.log | grep ENOENT > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > open("/usr/share/misc/pci.ids.gz", O_RDONLY) = -1 ENOENT (No > such > >> >>>> > file > >> >>>> > or > >> >>>> > directory) > >> >>>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/ > socket"}, > >> >>>> > 110) > >> >>>> > = -1 > >> >>>> > ENOENT (No such file or directory) > >> >>>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/ > socket"}, > >> >>>> > 110) > >> >>>> > = -1 > >> >>>> > ENOENT (No such file or directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > open("/root/.pciids-cache", O_RDONLY) = -1 ENOENT (No such file > >> >>>> > or > >> >>>> > directory) > >> >>>> > open("/etc/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 > ENOENT > >> >>>> > (No > >> >>>> > such > >> >>>> > file or directory) > >> >>>> > open("/etc/udev/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No > such > >> >>>> > file or > >> >>>> > directory) > >> >>>> > open("/usr/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 > >> >>>> > ENOENT > >> >>>> > (No > >> >>>> > such file or directory) > >> >>>> > open("/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 > ENOENT > >> >>>> > (No > >> >>>> > such > >> >>>> > file or directory) > >> >>>> > [zoran@localhost projects]$ > >> >>>> > > >> >>>> > I guess, you have one very important missing file in your Linux > >> >>>> > configuration, this one: /etc/systemd/hwdb/hwdb.bin... > >> >>>> > /etc/udev/hwdb.bin ?! > >> >>>> > > >> >>>> > Here is good read: > >> >>>> > https://www.freedesktop.org/software/systemd/man/hwdb.html > >> >>>> > > >> >>>> > > >> >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic= > systemd-hwdb&ampsect=8 > >> >>>> > > >> >>>> > Have no idea who is creating this file, but you can check your > >> >>>> > Linux > >> >>>> > distro > >> >>>> > / tree with the following paths to find hwdb.bin: > >> >>>> > > >> >>>> > /etc/systemd/hwdb/hwdb.bin > >> >>>> > /etc/udev/hwdb.bin <<======= In my Fedora > >> >>>> > rawhide VM > >> >>>> > (future Fedora 26) I have here hwdb.bin ======= > >> >>>> > /usr/lib/systemd/hwdb/hwdb.bin > >> >>>> > /lib/systemd/hwdb/hwdb.bin > >> >>>> > > >> >>>> > If you don't have in any, please, create one with the following > >> >>>> > link: > >> >>>> > > >> >>>> > > >> >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic= > systemd-hwdb&ampsect=8 > >> >>>> > > >> >>>> > Please, let us know! > >> >>>> > > >> >>>> > Zoran > >> >>>> > > >> >>>> > On Mon, Dec 26, 2016 at 3:42 PM, Shawn <citypw(a)gmail.com> wrote: > >> >>>> >> > >> >>>> >> Hi, > >> >>>> >> > >> >>>> >> intelmetool occurs "segfault" on my laptop running Mint 18 with > >> >>>> >> PaX/Grsecurity 4.7.10. The PCI info: > >> >>>> >> > >> >>>> >> -[0000:00]-+-00.0 Intel Corporation Sky Lake Host Bridge/DRAM > >> >>>> >> Registers [8086:1904] > >> >>>> >> +-02.0 Intel Corporation Sky Lake Integrated > Graphics > >> >>>> >> [8086:1916] > >> >>>> >> +-04.0 Intel Corporation Skylake Processor Thermal > >> >>>> >> Subsystem [8086:1903] > >> >>>> >> +-14.0 Intel Corporation Sunrise Point-LP USB 3.0 > xHCI > >> >>>> >> Controller [8086:9d2f] > >> >>>> >> +-14.2 Intel Corporation Sunrise Point-LP Thermal > >> >>>> >> subsystem [8086:9d31] > >> >>>> >> +-15.0 Intel Corporation Sunrise Point-LP Serial IO > >> >>>> >> I2C > >> >>>> >> Controller [8086:9d60] > >> >>>> >> +-15.1 Intel Corporation Sunrise Point-LP Serial IO > >> >>>> >> I2C > >> >>>> >> Controller [8086:9d61] > >> >>>> >> +-16.0 Intel Corporation Sunrise Point-LP CSME HECI > >> >>>> >> [8086:9d3a] > >> >>>> >> +-1c.0-[01]----00.0 NVIDIA Corporation GM107M > [GeForce > >> >>>> >> GTX > >> >>>> >> 960M] [10de:139b] > >> >>>> >> +-1c.4-[02]----00.0 Samsung Electronics Co Ltd NVMe > >> >>>> >> SSD > >> >>>> >> Controller [144d:a802] > >> >>>> >> +-1c.6-[03]----00.0 Qualcomm Atheros Killer E2400 > >> >>>> >> Gigabit > >> >>>> >> Ethernet Controller [1969:e0a1] > >> >>>> >> +-1c.7-[04]----00.0 Qualcomm Atheros QCA6174 > 802.11ac > >> >>>> >> Wireless Network Adapter [168c:003e] > >> >>>> >> +-1d.0-[05]----00.0 Samsung Electronics Co Ltd NVMe > >> >>>> >> SSD > >> >>>> >> Controller [144d:a802] > >> >>>> >> +-1d.2-[06-3e]-- > >> >>>> >> +-1f.0 Intel Corporation Sunrise Point-LP LPC > >> >>>> >> Controller > >> >>>> >> [8086:9d48] > >> >>>> >> +-1f.2 Intel Corporation Sunrise Point-LP PMC > >> >>>> >> [8086:9d21] > >> >>>> >> +-1f.3 Intel Corporation Sunrise Point-LP HD Audio > >> >>>> >> [8086:9d70] > >> >>>> >> \-1f.4 Intel Corporation Sunrise Point-LP SMBus > >> >>>> >> [8086:9d23] > >> >>>> >> > >> >>>> >> The crash log was attached! I'm not sure if intelmetool support > >> >>>> >> Skylake as well. One tiny feature of PaX/Grsecurity prevent the > >> >>>> >> ioperm > >> >>>> >> for killing the potential threats in case which > >> >>>> >> the adversary re-flash the SPI ROM once they get the root priv. > It > >> >>>> >> does affect flashrom but intelmetool. I also ran intelmetool on > >> >>>> >> the > >> >>>> >> distro( Mint 18) kernel and got the same result. > >> >>>> >> > >> >>>> >> > >> >>>> >> -- > >> >>>> >> GNU powered it... > >> >>>> >> GPL protect it... > >> >>>> >> God blessing it... > >> >>>> >> > >> >>>> >> regards > >> >>>> >> Shawn > >> >>>> >> > >> >>>> >> -- > >> >>>> >> coreboot mailing list: coreboot(a)coreboot.org > >> >>>> >> https://www.coreboot.org/mailman/listinfo/coreboot > >> >>>> > > >> >>>> > > >> >>>> > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> GNU powered it... > >> >>>> GPL protect it... > >> >>>> God blessing it... > >> >>>> > >> >>>> regards > >> >>>> Shawn > >> >>> > >> >>> > >> >> > >> > > >> > > >> > > >> > -- > >> > GNU powered it... > >> > GPL protect it... > >> > God blessing it... > >> > > >> > regards > >> > Shawn > >> > >> > >> > >> -- > >> GNU powered it... > >> GPL protect it... > >> God blessing it... > >> > >> regards > >> Shawn > > > > > > > > -- > GNU powered it... > GPL protect it... > God blessing it... > > regards > Shawn >

1 0

Re: [coreboot] 答复: 答复: 答复: logical error for smm hander in coreboot.
by Zoran Stojsavljevic 05 Jan '17

05 Jan '17

Hello Tank, I am reading your messages and I am thinking, since the use case you are presenting here does not make any sense to me. You are managing DTS (Digital Thermal Sensor), this is something inherently integrated on silicon die (I think per core), and there is no need to manage it from SMM prospective. The gradient of Temperature is slow, you can start checking it from ramstage every minimum 100ms, which is anyhow great overkill (minimum should be 1000ms), in my opinion. Except if you are not putting/on purpose missing heatsink on the top of CPU and experimenting how long the CPU can work. Yes, MSRs 0x19B/0x19C are General Purpose MSRs (presented in all CORE and ATOM families), and they are accessible from anywhere, anytime, I am not sure, but there is also built-in HW T monitor which, while detecting ~5C below T junction, issues automatically PROCHOT# active low, which shutdowns all cores and platform to S5 state (PROCHOT# signal should go to EC or PMIC as well). PROCHOT# : https://www.manualslib.com/manual/407246/Intel-Celeron-Processor-E3000-Ther… Other that that, in Linux you can have a thermal application (user space) which will every second scan DTS, and show you the graphical value (I guess, INTEL for this has so-called TAT tool (also works as test load balancer for cores and integrated GFX), but there are also other apps for monitoring as well). Why you need to monitor DTS in SMM, that is my question (seems completely unnecessary)? What for? You are NOT going to apply turbo mode in Coreboot, as well as play performance boost with TPD1 to TDP2 (not wise at all to do these boosts in BSPs)?! Thank you, Zoran On Thu, Jan 5, 2017 at 6:20 AM, Tang Tank <js_nj_tanktang(a)outlook.com> wrote: > Hi Aaron, > > Yes, I do this as you say. > Add a ID like CBMEM_ID_MP_SMM(cbmem_add (CBMEM_ID_MP_SMM, > sync_data_size)), and pass addr to smm_runtime when smm relocation. > It seems ok to install and boot win10/boot ubuntu, but it will hang when > install ubuntu. > I have none debugging methods for this issue. So I hope to define a > static variable to do this and have a try. > > Thanks > Tank > > 发件人: Aaron Durbin <adurbin(a)google.com> > 发送时间: 2017年1月4日 19:47 > 收件人: Tang Tank > 抄送: Nico Huber; Zoran Stojsavljevic; coreboot > 主题: Re: 答复: 答复: [coreboot] logical error for smm hander in coreboot. > > On Wed, Jan 4, 2017 at 7:12 PM, Tang Tank <js_nj_tanktang(a)outlook.com> > wrote: > > Hi Nico, > > > > The MSRs can access and modify at any time. But DTS feature need to > done in smm. > > I need to check this msr 0x19b/0x19c and set the trigger temperature > dynamically in smm. > > I will set a software gpe to notify that the _tmp method vaule in the > thermal zone has been changed when a dts smi occured. > > And then OS will change the speed of fan(active temperature), power > and freq of cpus (passive temperature) or shutdown (critial temperature). > > So do you know the way to define a static variable which can been used > under smm stage and ram stage? > > Now I reserved a fixed memory addr in ramstage, hard code the pointer > to the addr in smi hander and complete the dts feature in win10 > successfully. > > But I found that this will cause a hang when boot linux OSs such as > ubuntu. > > You can't just use a fixed memory address w/o reserving the memory > from the OS. If you need to read and write this memory from SMM and > ASL I suggest you add the memory to cbmem which will reserve it from > the OS. From there you can reference the memory in ASL and from SMM > (once both are in told about the memory address). > > > > > > > Thanks > > Tank > > > > 发件人: Nico Huber <nico.huber(a)secunet.com> > > 发送时间: 2017年1月4日 7:37 > > 收件人: Tang Tank; Aaron Durbin; Zoran Stojsavljevic > > 抄送: coreboot > > 主题: Re: 答复: [coreboot] logical error for smm hander in coreboot. > > > > Hi Tank, > > > > On 04.01.2017 02:39, Tang Tank wrote: > >> Hi Nico , Aaron, Zoran, > >> > >> Thank you for your help! > >> Smi_sts will been cleared after southbridge_smi_handler runs. > >> I am working for intel apollake now, need to do a thermal feature > named DTS(Digital Thermal Sensor). > >> This need to check and modify MSR in smm for every core . > > > > is this MSR only accessible from SMM? or where does the requirement to > > do it in SMM come from? It sounds like something that's better done in > > the OS or ACPI. > > > > Nico > > > >> And when I add a mechanism to sync up bsp and aps like below struct > , I found that I can't define and use the same static variable in ramstage > and smmstage. > >> How can I do this? > >> > >> typedef struct { > >> spin_lock busy; > >> volatile ap_procedure procedure; > >> volatile void *parameter; > >> volatile u32 run; > >> volatile bool present; > >> } smm_cpu_data; > >> > >> typedef struct { > >> smm_cpu_data *cpu_data; > >> volatile u8 cpu_count; > >> volatile u32 bsp_index; //we will assusme > index 0 as bsp > >> volatile bool all_cores_is_sync; > >> volatile u64 time_out_ticker; > >> } smm_mp_sync_data; > >> > >> Thanks, > >> Tank > >> > >> 发件人: Aaron Durbin <adurbin(a)google.com> > >> 发送时间: 2017年1月3日 7:23 > >> 收件人: Nico Huber > >> 抄送: Tang Tank; coreboot > >> 主题: Re: [coreboot] logical error for smm hander in coreboot. > >> > >> On Tue, Jan 3, 2017 at 6:37 AM, Nico Huber <nico.huber(a)secunet.com> > wrote: > >>> Hi Tank, > >>> > >>> On 03.01.2017 04:20, Tang Tank wrote: > >>>> > >>>> Hi all, > >>>> > >>>> > >>>> For smm handler (func smm_handler_start) in > coreboot/src/cpu/x86/smm/smm_module_handler.c, > >>>> there may be a logical error. > >>>> > >>>> If I have 4 cores in my mainboard in the following special > conditions: > >>>> 1. core0 run into smm_handler_start and smi_handler_status will > be SMI_LOCKED. > >>>> 2. core1/2 run into smm_handler_start and pause since > smi_handler_status is locked. > >>>> 3. core0 release smi_handler_status and then core4 run into > smm_handler_start, it will do > >>>> southbridge_smi_handler again. > >>> > >>> looking at the code, I too see that possible race. But... > >>> > >>>> > >>>> So is there have a reliable way of doing smm multi processors > services in coreboot? > >>> > >>> ...IMO, this isn't unreliable. After the first run of a cpu/northbridge > >>> /southbridge_smi_handler() function, the cause of the SMI should be > >>> handled and thus the second run should do nothing (but checking for the > >>> SMI's cause). > >>> > >>> Does that help? I wasn't sure if I got your question right. > >> > >> > >> Or you have to wait for all the CPUs to check in before dealing with > >> the SMM handler logic. One would also have to deal with SMIs that were > >> not broadcast since the other CPUs would never check in. > >> > >>> > >>> Nico > >>> > >>> > >>> -- > >>> coreboot mailing list: coreboot(a)coreboot.org > >>> https://www.coreboot.org/mailman/listinfo/coreboot > > > coreboot Info Page > www.coreboot.org > coreboot project mailing list. To see the collection of prior postings to > the list, visit the coreboot Archives. Using coreboot > > > > > > > coreboot Info Page > > www.coreboot.org > > coreboot project mailing list. To see the collection of prior postings > to the list, visit the coreboot Archives. Using coreboot > > > >> > >> > >> coreboot Info Page > >> www.coreboot.org > >> coreboot project mailing list. To see the collection of prior postings > to the list, visit the coreboot Archives. Using coreboot > > > >

1 0

Re: [coreboot] How does intelmetool's support for Skylake?
by Shawn 05 Jan '17

05 Jan '17

Hi Zoran, Happy new year;-) intelmetool merged the patch, plz check: https://github.com/zamaudio/intelmetool If you're going to only neutralize the ME, you can use external programmer && try me_cleaner: https://github.com/corna/me_cleaner/ We've only tested a few coreboot supported mainboards on neutralizing ME( I'm afarid your hardware isn't on the list-_-): https://github.com/hardenedlinux/hardenedlinux_profiles/tree/master/coreboot On Wed, Jan 4, 2017 at 8:28 PM, Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote: > Hello Shawn, > > I am late, I apologize... New Year, everything is slow, me either. > > For me, the link you have provided does not work?! it is HTTP 404 (page not > found). Could you, please, repost the valid link? Or to attach the given > patch to this email? > > With the normal Coreboot intelmetool (where I added one more printk() to > explore what are the device ids the tool looks into), I have the following: > > [root@localhost intelmetool]# uname -a > Linux localhost.localdomain 4.8.15-300.fc25.x86_64 #1 SMP Thu Dec 15 > 23:10:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > [1]+ Done emacs intelmetool.h > [root@localhost intelmetool]# ./intelmetool -s > dev->vendor_id = 0x8086, dev->device_id = 0x9c22 > dev->vendor_id = 0x8086, dev->device_id = 0x9c03 > dev->vendor_id = 0x8086, dev->device_id = 0x9c43 > Bad news, you have a `8 Series LPC Controller` so you have ME hardware on > board and you can't control or disable it, continuing... > > Error mapping physical memory 0x0000004275159040 [0x4000] ERRNO=1 > Segmentation fault (core dumped) > > [root@localhost intelmetool]# lspci -nn | grep 9c22 > 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller > [8086:9c22] (rev 04) > [root@localhost intelmetool]# lspci -nn | grep 9c03 > 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA Controller 1 > [AHCI mode] [8086:9c03] (rev 04) > [root@localhost intelmetool]# lspci -nn | grep 9c43 > 00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller > [8086:9c43] (rev 04) > [root@localhost intelmetool]# > > Yet, in intelmetool.h it says explicitly: > > // Definitely has ME and is very difficult to remove > [snap] > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_FULL 0x9c41 > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_PREM 0x9c43 > #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_BASE 0x9c45 > > Coreboot ME pros, any comment on my HW (i5-4300U HSW ULT + PCH LynxPoint)? > Appreciate any help! > > Thank you, > Zoran > > On Fri, Dec 30, 2016 at 11:25 AM, Shawn <citypw(a)gmail.com> wrote: >> >> This is a work around patch( I think?): >> >> https://github.com/hardenedlinux/intelmetool/commit/ad778fc347b2bb0494abe21… >> >> ./intelmetool -s >> RCBA at 0x00000000 >> MEI not hidden on PCI, checking if visible >> MEI found: [8086:9d3a] Sunrise Point-LP CSME HECI >> >> ME Status : 0xa0000245 >> ME Status 2 : 0x86110306 >> >> ME: FW Partition Table : OK >> ME: Bringup Loader Failure : NO >> ME: Firmware Init Complete : YES >> ME: Manufacturing Mode : NO >> ME: Boot Options Present : NO >> ME: Update In Progress : NO >> ME: Current Working State : Normal >> ME: Current Operation State : M0 with UMA >> ME: Current Operation Mode : Normal >> ME: Error Code : No Error >> ME: Progress Phase : Clean Moff->Mx wake >> ME: Power Management Event : Pseudo-global reset >> ME: Progress Phase State : Unknown 0x11 >> >> PCI READ [bc] : 0x000000bc >> ME: Extend Register not valid >> >> ME seems okay on this board >> WRITE [00] : CB: 0x80040007 >> WRITE [00] : CB: 0x000002ff >> READ [08] : CB: 0x801c0007 >> READ [08] : CB: 0x000082ff >> READ [08] : CB: 0x000b0000 >> READ [08] : CB: 0x0000049c >> READ [08] : CB: 0x000b0000 >> READ [08] : CB: 0x0000049c >> READ [08] : CB: 0x000b0000 >> READ [08] : CB: 0x0000049c >> ME: Firmware Version 11.0.1180.0 (code) 11.0.1180.0 (recovery) >> 11.0.1180.0 (fitc) >> WRITE [00] : CB: 0x80080007 >> WRITE [00] : CB: 0x00000203 >> WRITE [00] : CB: 0x00000000 >> READ [08] : CB: 0x800d0007 >> READ [08] : CB: 0x00008203 >> READ [08] : CB: 0x00000000 >> READ [08] : CB: 0x111a4004 >> READ [08] : CB: 0x00000031 >> ME Capability: Full Network manageability : OFF >> ME Capability: Regular Network manageability : OFF >> ME Capability: Manageability : OFF >> ME Capability: Small business technology : OFF >> ME Capability: Level III manageability : OFF >> ME Capability: IntelR Anti-Theft (AT) : OFF >> ME Capability: IntelR Capability Licensing Service (CLS) : ON >> ME Capability: IntelR Power Sharing Technology (MPC) : OFF >> ME Capability: ICC Over Clocking : ON >> ME Capability: Protected Audio Video Path (PAVP) : ON >> ME Capability: IPV6 : OFF >> ME Capability: KVM Remote Control (KVM) : OFF >> ME Capability: Outbreak Containment Heuristic (OCH) : OFF >> ME Capability: Virtual LAN (VLAN) : ON >> ME Capability: TLS : OFF >> ME Capability: Wireless LAN (WLAN) : OFF >> exiting >> >> On Fri, Dec 30, 2016 at 11:04 AM, Shawn <citypw(a)gmail.com> wrote: >> > Hi Zoran, >> > >> > Thanks for the info. I added my Device ID into the intelmetool.h: >> > >> > diff --git a/intelmetool.h b/intelmetool.h >> > index d79d6b0..16ca43a 100644 >> > --- a/intelmetool.h >> > +++ b/intelmetool.h >> > @@ -225,6 +225,7 @@ >> > #define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914 >> > #define PCI_DEVICE_ID_INTEL_ICH9R 0x2916 >> > #define PCI_DEVICE_ID_INTEL_ICH9 0x2918 >> > +#define PCI_DEVICE_ID_INTEL_SUNRISE 0x9d3a >> > >> > #define PCI_DEV_CAN_DISABLE_ME_IF_PRESENT(x) ( \ >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH8 ) || \ >> > @@ -232,6 +233,7 @@ >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DH ) || \ >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DO ) || \ >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9R ) || \ >> > + ( (x) == PCI_DEVICE_ID_INTEL_SUNRISE ) || \ >> > ( (x) == PCI_DEVICE_ID_INTEL_ICH9 )) >> > >> > // Not sure at all >> > >> > This one should be the ME? >> > +-16.0 Intel Corporation Sunrise Point-LP CSME HECI [8086:9d3a] >> > >> > #./intelmetool -s >> > Not sure if ME hardware is present because you have a `Sunrise >> > Point-LP CSME HECI`, but it is possible to disable it if you do, >> > continuing... >> > RCBA at 0x00000000 >> > MEI not hidden on PCI, checking if visible >> > MEI device not found, huh? >> > exiting >> > >> > >> > >> > On Thu, Dec 29, 2016 at 12:50 AM, Zoran Stojsavljevic >> > <zoran.stojsavljevic(a)gmail.com> wrote: >> >>>> I'm not sure if intelmetool support Skylake as well. >> >> >> >> Investigated more. The coreboot intelmetool is the latest one, as I >> >> understood (comparing one from github and coreboot). >> >> >> >> And Sunrise Point is NOT supported (look into latest coreboot's >> >> coreboot/util/intelmetool/intelmetool.h). You can try to add it (as >> >> Device >> >> ID), manually, peek around the C code, and see if this can help you. >> >> >> >> Zoran >> >> >> >> On Wed, Dec 28, 2016 at 5:26 PM, Zoran Stojsavljevic >> >> <zoran.stojsavljevic(a)gmail.com> wrote: >> >>> >> >>> Hello Shawn, >> >>> >> >>> Please, follow my CLI transcript from my Future Fedora 26 VM over >> >>> WIN10 >> >>> (now rawhide) with Fedora 4.8.15 kernel implanted (kernel 4.10.0-rc0 >> >>> gives >> >>> me lot of griefs, I do not trust it, so I eliminated it for now): >> >>> >> >>> [zoran@localhost ~]$ cd projects/ >> >>> [zoran@localhost projects]$ mkdir intelmetool >> >>> [zoran@localhost projects]$ cd intelmetool/ >> >>> [zoran@localhost intelmetool]$ pwd >> >>> /home/zoran/projects/intelmetool >> >>> [zoran@localhost intelmetool]$ uname -r >> >>> 4.8.15-300.fc25.x86_64 >> >>> [zoran@localhost intelmetool]$ git clone >> >>> https://github.com/zamaudio/intelmetool.git >> >>> Cloning into 'intelmetool'... >> >>> remote: Counting objects: 214, done. >> >>> remote: Total 214 (delta 0), reused 0 (delta 0), pack-reused 214 >> >>> Receiving objects: 100% (214/214), 72.42 KiB | 0 bytes/s, done. >> >>> Resolving deltas: 100% (125/125), done. >> >>> [zoran@localhost intelmetool]$ ls -al >> >>> total 12 >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . >> >>> drwxrwxr-x. 10 zoran zoran 4096 Dec 28 17:05 .. >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 intelmetool >> >>> [zoran@localhost intelmetool]$ cd intelmetool/ >> >>> [zoran@localhost intelmetool]$ ls -al >> >>> total 100 >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. >> >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git >> >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore >> >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c >> >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h >> >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE >> >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile >> >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c >> >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h >> >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c >> >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c >> >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h >> >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md >> >>> [zoran@localhost intelmetool]$ su -m >> >>> Password: >> >>> [root@localhost intelmetool]# make >> >>> gcc -Wall -O0 -g -I. -c me_status.c -o me_status.o >> >>> gcc -Wall -O0 -g -I. -c me.c -o me.o >> >>> me.c: In function ‘mei_dump’: >> >>> me.c:63:18: warning: variable ‘csr’ set but not used >> >>> [-Wunused-but-set-variable] >> >>> struct mei_csr *csr; >> >>> ^~~ >> >>> gcc -Wall -O0 -g -I. -c mmap.c -o mmap.o >> >>> mmap.c: In function ‘map_physical_exact’: >> >>> mmap.c:11:26: warning: passing argument 1 of ‘mmap’ makes pointer from >> >>> integer without a cast [-Wint-conversion] >> >>> virt_addr = mmap(mapto, len, PROT_WRITE | PROT_READ, >> >>> MAP_SHARED|MAP_FIXED, >> >>> ^~~~~ >> >>> In file included from mmap.h:4:0, >> >>> from mmap.c:1: >> >>> /usr/include/sys/mman.h:57:14: note: expected ‘void *’ but argument is >> >>> of >> >>> type ‘uint64_t {aka long unsigned int}’ >> >>> extern void *mmap (void *__addr, size_t __len, int __prot, >> >>> ^~~~ >> >>> gcc -Wall -O0 -g -I. -o intelmetool intelmetool.o me_status.o me.o >> >>> mmap.o >> >>> -lpci >> >>> [root@localhost intelmetool]# date >> >>> Wed Dec 28 17:07:26 CET 2016 >> >>> [root@localhost intelmetool]# ls -al >> >>> total 228 >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:07 . >> >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. >> >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git >> >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore >> >>> -rwxr-xr-x. 1 root root 47008 Dec 28 17:07 intelmetool >> >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c >> >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h >> >>> -rw-rw-r--. 1 zoran zoran 22144 Dec 28 17:06 intelmetool.o >> >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE >> >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile >> >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c >> >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h >> >>> -rw-r--r--. 1 root root 28984 Dec 28 17:07 me.o >> >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c >> >>> -rw-r--r--. 1 root root 15704 Dec 28 17:07 me_status.o >> >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c >> >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h >> >>> -rw-r--r--. 1 root root 7648 Dec 28 17:07 mmap.o >> >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md >> >>> [root@localhost intelmetool]# ./intelmetool >> >>> ME is not present on your board because we found a `82371AB/EB/MB >> >>> PIIX4 >> >>> ISA`, you are safe, exiting >> >>> [root@localhost intelmetool]# >> >>> _______ >> >>> >> >>> Do NOT forget: I run Fedora rawhide on VMWorkstation 12.5.2 Type 2 HYP >> >>> on >> >>> the top of WIN10 64 Pro! >> >>> >> >>> Please, do the same on Mint18 distro on raw HW, and see if this will >> >>> give >> >>> you some different results then what you have presently? >> >>> >> >>> Please, let us know! >> >>> >> >>> Zoran >> >>> >> >>> On Wed, Dec 28, 2016 at 11:06 AM, Shawn <citypw(a)gmail.com> wrote: >> >>>> >> >>>> Hi Zoran, >> >>>> >> >>>> I created hwdb.bin via: >> >>>> >> >>>> # udevadm hwdb --update >> >>>> >> >>>> The result is still "segfault". dmesg: >> >>>> >> >>>> [ 972.044664] intelmetool[5055]: segfault at 16 ip 000000000040169e >> >>>> sp 000072ed96a44680 error 4 in intelmetool[400000+6000] >> >>>> [ 972.044674] grsec: Segmentation fault occurred at 0000000000000016 >> >>>> in /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 >> >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 >> >>>> [ 972.044685] grsec: denied resource overstep by requesting 4096 for >> >>>> RLIMIT_CORE against limit 0 for >> >>>> /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 >> >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 >> >>>> >> >>>> >> >>>> On Mon, Dec 26, 2016 at 9:49 PM, Zoran Stojsavljevic >> >>>> <zoran.stojsavljevic(a)gmail.com> wrote: >> >>>> > Not sure if your strace log has anything to do with intelmetool. >> >>>> > >> >>>> > I did on your strace log the following (and in RED is possible >> >>>> > cause of >> >>>> > your >> >>>> > problems): >> >>>> > >> >>>> > [zoran@localhost projects]$ cat crash.log | grep ENOENT >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > open("/usr/share/misc/pci.ids.gz", O_RDONLY) = -1 ENOENT (No such >> >>>> > file >> >>>> > or >> >>>> > directory) >> >>>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, >> >>>> > 110) >> >>>> > = -1 >> >>>> > ENOENT (No such file or directory) >> >>>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, >> >>>> > 110) >> >>>> > = -1 >> >>>> > ENOENT (No such file or directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > open("/root/.pciids-cache", O_RDONLY) = -1 ENOENT (No such file >> >>>> > or >> >>>> > directory) >> >>>> > open("/etc/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT >> >>>> > (No >> >>>> > such >> >>>> > file or directory) >> >>>> > open("/etc/udev/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such >> >>>> > file or >> >>>> > directory) >> >>>> > open("/usr/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 >> >>>> > ENOENT >> >>>> > (No >> >>>> > such file or directory) >> >>>> > open("/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT >> >>>> > (No >> >>>> > such >> >>>> > file or directory) >> >>>> > [zoran@localhost projects]$ >> >>>> > >> >>>> > I guess, you have one very important missing file in your Linux >> >>>> > configuration, this one: /etc/systemd/hwdb/hwdb.bin... >> >>>> > /etc/udev/hwdb.bin ?! >> >>>> > >> >>>> > Here is good read: >> >>>> > https://www.freedesktop.org/software/systemd/man/hwdb.html >> >>>> > >> >>>> > >> >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd-hwdb&ampsect=8 >> >>>> > >> >>>> > Have no idea who is creating this file, but you can check your >> >>>> > Linux >> >>>> > distro >> >>>> > / tree with the following paths to find hwdb.bin: >> >>>> > >> >>>> > /etc/systemd/hwdb/hwdb.bin >> >>>> > /etc/udev/hwdb.bin <<======= In my Fedora >> >>>> > rawhide VM >> >>>> > (future Fedora 26) I have here hwdb.bin ======= >> >>>> > /usr/lib/systemd/hwdb/hwdb.bin >> >>>> > /lib/systemd/hwdb/hwdb.bin >> >>>> > >> >>>> > If you don't have in any, please, create one with the following >> >>>> > link: >> >>>> > >> >>>> > >> >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd-hwdb&ampsect=8 >> >>>> > >> >>>> > Please, let us know! >> >>>> > >> >>>> > Zoran >> >>>> > >> >>>> > On Mon, Dec 26, 2016 at 3:42 PM, Shawn <citypw(a)gmail.com> wrote: >> >>>> >> >> >>>> >> Hi, >> >>>> >> >> >>>> >> intelmetool occurs "segfault" on my laptop running Mint 18 with >> >>>> >> PaX/Grsecurity 4.7.10. The PCI info: >> >>>> >> >> >>>> >> -[0000:00]-+-00.0 Intel Corporation Sky Lake Host Bridge/DRAM >> >>>> >> Registers [8086:1904] >> >>>> >> +-02.0 Intel Corporation Sky Lake Integrated Graphics >> >>>> >> [8086:1916] >> >>>> >> +-04.0 Intel Corporation Skylake Processor Thermal >> >>>> >> Subsystem [8086:1903] >> >>>> >> +-14.0 Intel Corporation Sunrise Point-LP USB 3.0 xHCI >> >>>> >> Controller [8086:9d2f] >> >>>> >> +-14.2 Intel Corporation Sunrise Point-LP Thermal >> >>>> >> subsystem [8086:9d31] >> >>>> >> +-15.0 Intel Corporation Sunrise Point-LP Serial IO >> >>>> >> I2C >> >>>> >> Controller [8086:9d60] >> >>>> >> +-15.1 Intel Corporation Sunrise Point-LP Serial IO >> >>>> >> I2C >> >>>> >> Controller [8086:9d61] >> >>>> >> +-16.0 Intel Corporation Sunrise Point-LP CSME HECI >> >>>> >> [8086:9d3a] >> >>>> >> +-1c.0-[01]----00.0 NVIDIA Corporation GM107M [GeForce >> >>>> >> GTX >> >>>> >> 960M] [10de:139b] >> >>>> >> +-1c.4-[02]----00.0 Samsung Electronics Co Ltd NVMe >> >>>> >> SSD >> >>>> >> Controller [144d:a802] >> >>>> >> +-1c.6-[03]----00.0 Qualcomm Atheros Killer E2400 >> >>>> >> Gigabit >> >>>> >> Ethernet Controller [1969:e0a1] >> >>>> >> +-1c.7-[04]----00.0 Qualcomm Atheros QCA6174 802.11ac >> >>>> >> Wireless Network Adapter [168c:003e] >> >>>> >> +-1d.0-[05]----00.0 Samsung Electronics Co Ltd NVMe >> >>>> >> SSD >> >>>> >> Controller [144d:a802] >> >>>> >> +-1d.2-[06-3e]-- >> >>>> >> +-1f.0 Intel Corporation Sunrise Point-LP LPC >> >>>> >> Controller >> >>>> >> [8086:9d48] >> >>>> >> +-1f.2 Intel Corporation Sunrise Point-LP PMC >> >>>> >> [8086:9d21] >> >>>> >> +-1f.3 Intel Corporation Sunrise Point-LP HD Audio >> >>>> >> [8086:9d70] >> >>>> >> \-1f.4 Intel Corporation Sunrise Point-LP SMBus >> >>>> >> [8086:9d23] >> >>>> >> >> >>>> >> The crash log was attached! I'm not sure if intelmetool support >> >>>> >> Skylake as well. One tiny feature of PaX/Grsecurity prevent the >> >>>> >> ioperm >> >>>> >> for killing the potential threats in case which >> >>>> >> the adversary re-flash the SPI ROM once they get the root priv. It >> >>>> >> does affect flashrom but intelmetool. I also ran intelmetool on >> >>>> >> the >> >>>> >> distro( Mint 18) kernel and got the same result. >> >>>> >> >> >>>> >> >> >>>> >> -- >> >>>> >> GNU powered it... >> >>>> >> GPL protect it... >> >>>> >> God blessing it... >> >>>> >> >> >>>> >> regards >> >>>> >> Shawn >> >>>> >> >> >>>> >> -- >> >>>> >> coreboot mailing list: coreboot(a)coreboot.org >> >>>> >> https://www.coreboot.org/mailman/listinfo/coreboot >> >>>> > >> >>>> > >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> GNU powered it... >> >>>> GPL protect it... >> >>>> God blessing it... >> >>>> >> >>>> regards >> >>>> Shawn >> >>> >> >>> >> >> >> > >> > >> > >> > -- >> > GNU powered it... >> > GPL protect it... >> > God blessing it... >> > >> > regards >> > Shawn >> >> >> >> -- >> GNU powered it... >> GPL protect it... >> God blessing it... >> >> regards >> Shawn > > -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

答复: 答复: 答复: logical error for smm hander in coreboot.
by Tang Tank 05 Jan '17

05 Jan '17

Hi Aaron, Yes, I do this as you say. Add a ID like CBMEM_ID_MP_SMM(cbmem_add (CBMEM_ID_MP_SMM, sync_data_size)), and pass addr to smm_runtime when smm relocation. It seems ok to install and boot win10/boot ubuntu, but it will hang when install ubuntu. I have none debugging methods for this issue. So I hope to define a static variable to do this and have a try. Thanks Tank 发件人: Aaron Durbin <adurbin(a)google.com> 发送时间: 2017年1月4日 19:47 收件人: Tang Tank 抄送: Nico Huber; Zoran Stojsavljevic; coreboot 主题: Re: 答复: 答复: [coreboot] logical error for smm hander in coreboot. On Wed, Jan 4, 2017 at 7:12 PM, Tang Tank <js_nj_tanktang(a)outlook.com> wrote: > Hi Nico, > > The MSRs can access and modify at any time. But DTS feature need to done in smm. > I need to check this msr 0x19b/0x19c and set the trigger temperature dynamically in smm. > I will set a software gpe to notify that the _tmp method vaule in the thermal zone has been changed when a dts smi occured. > And then OS will change the speed of fan(active temperature), power and freq of cpus (passive temperature) or shutdown (critial temperature). > So do you know the way to define a static variable which can been used under smm stage and ram stage? > Now I reserved a fixed memory addr in ramstage, hard code the pointer to the addr in smi hander and complete the dts feature in win10 successfully. > But I found that this will cause a hang when boot linux OSs such as ubuntu. You can't just use a fixed memory address w/o reserving the memory from the OS. If you need to read and write this memory from SMM and ASL I suggest you add the memory to cbmem which will reserve it from the OS. From there you can reference the memory in ASL and from SMM (once both are in told about the memory address). > > > Thanks > Tank > > 发件人: Nico Huber <nico.huber(a)secunet.com> > 发送时间: 2017年1月4日 7:37 > 收件人: Tang Tank; Aaron Durbin; Zoran Stojsavljevic > 抄送: coreboot > 主题: Re: 答复: [coreboot] logical error for smm hander in coreboot. > > Hi Tank, > > On 04.01.2017 02:39, Tang Tank wrote: >> Hi Nico , Aaron, Zoran, >> >> Thank you for your help! >> Smi_sts will been cleared after southbridge_smi_handler runs. >> I am working for intel apollake now, need to do a thermal feature named DTS(Digital Thermal Sensor). >> This need to check and modify MSR in smm for every core . > > is this MSR only accessible from SMM? or where does the requirement to > do it in SMM come from? It sounds like something that's better done in > the OS or ACPI. > > Nico > >> And when I add a mechanism to sync up bsp and aps like below struct , I found that I can't define and use the same static variable in ramstage and smmstage. >> How can I do this? >> >> typedef struct { >> spin_lock busy; >> volatile ap_procedure procedure; >> volatile void *parameter; >> volatile u32 run; >> volatile bool present; >> } smm_cpu_data; >> >> typedef struct { >> smm_cpu_data *cpu_data; >> volatile u8 cpu_count; >> volatile u32 bsp_index; //we will assusme index 0 as bsp >> volatile bool all_cores_is_sync; >> volatile u64 time_out_ticker; >> } smm_mp_sync_data; >> >> Thanks, >> Tank >> >> 发件人: Aaron Durbin <adurbin(a)google.com> >> 发送时间: 2017年1月3日 7:23 >> 收件人: Nico Huber >> 抄送: Tang Tank; coreboot >> 主题: Re: [coreboot] logical error for smm hander in coreboot. >> >> On Tue, Jan 3, 2017 at 6:37 AM, Nico Huber <nico.huber(a)secunet.com> wrote: >>> Hi Tank, >>> >>> On 03.01.2017 04:20, Tang Tank wrote: >>>> >>>> Hi all, >>>> >>>> >>>> For smm handler (func smm_handler_start) in coreboot/src/cpu/x86/smm/smm_module_handler.c, >>>> there may be a logical error. >>>> >>>> If I have 4 cores in my mainboard in the following special conditions: >>>> 1. core0 run into smm_handler_start and smi_handler_status will be SMI_LOCKED. >>>> 2. core1/2 run into smm_handler_start and pause since smi_handler_status is locked. >>>> 3. core0 release smi_handler_status and then core4 run into smm_handler_start, it will do >>>> southbridge_smi_handler again. >>> >>> looking at the code, I too see that possible race. But... >>> >>>> >>>> So is there have a reliable way of doing smm multi processors services in coreboot? >>> >>> ...IMO, this isn't unreliable. After the first run of a cpu/northbridge >>> /southbridge_smi_handler() function, the cause of the SMI should be >>> handled and thus the second run should do nothing (but checking for the >>> SMI's cause). >>> >>> Does that help? I wasn't sure if I got your question right. >> >> >> Or you have to wait for all the CPUs to check in before dealing with >> the SMM handler logic. One would also have to deal with SMIs that were >> not broadcast since the other CPUs would never check in. >> >>> >>> Nico >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot coreboot Info Page www.coreboot.org coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot > > > coreboot Info Page > www.coreboot.org > coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot > >> >> >> coreboot Info Page >> www.coreboot.org >> coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot >

1 0

Re: [coreboot] 答复: 答复: logical error for smm hander in coreboot.
by Aaron Durbin 05 Jan '17

05 Jan '17

On Wed, Jan 4, 2017 at 7:12 PM, Tang Tank <js_nj_tanktang(a)outlook.com> wrote: > Hi Nico, > > The MSRs can access and modify at any time. But DTS feature need to done in smm. > I need to check this msr 0x19b/0x19c and set the trigger temperature dynamically in smm. > I will set a software gpe to notify that the _tmp method vaule in the thermal zone has been changed when a dts smi occured. > And then OS will change the speed of fan(active temperature), power and freq of cpus (passive temperature) or shutdown (critial temperature). > So do you know the way to define a static variable which can been used under smm stage and ram stage? > Now I reserved a fixed memory addr in ramstage, hard code the pointer to the addr in smi hander and complete the dts feature in win10 successfully. > But I found that this will cause a hang when boot linux OSs such as ubuntu. You can't just use a fixed memory address w/o reserving the memory from the OS. If you need to read and write this memory from SMM and ASL I suggest you add the memory to cbmem which will reserve it from the OS. From there you can reference the memory in ASL and from SMM (once both are in told about the memory address). > > > Thanks > Tank > > 发件人: Nico Huber <nico.huber(a)secunet.com> > 发送时间: 2017年1月4日 7:37 > 收件人: Tang Tank; Aaron Durbin; Zoran Stojsavljevic > 抄送: coreboot > 主题: Re: 答复: [coreboot] logical error for smm hander in coreboot. > > Hi Tank, > > On 04.01.2017 02:39, Tang Tank wrote: >> Hi Nico , Aaron, Zoran, >> >> Thank you for your help! >> Smi_sts will been cleared after southbridge_smi_handler runs. >> I am working for intel apollake now, need to do a thermal feature named DTS(Digital Thermal Sensor). >> This need to check and modify MSR in smm for every core . > > is this MSR only accessible from SMM? or where does the requirement to > do it in SMM come from? It sounds like something that's better done in > the OS or ACPI. > > Nico > >> And when I add a mechanism to sync up bsp and aps like below struct , I found that I can't define and use the same static variable in ramstage and smmstage. >> How can I do this? >> >> typedef struct { >> spin_lock busy; >> volatile ap_procedure procedure; >> volatile void *parameter; >> volatile u32 run; >> volatile bool present; >> } smm_cpu_data; >> >> typedef struct { >> smm_cpu_data *cpu_data; >> volatile u8 cpu_count; >> volatile u32 bsp_index; //we will assusme index 0 as bsp >> volatile bool all_cores_is_sync; >> volatile u64 time_out_ticker; >> } smm_mp_sync_data; >> >> Thanks, >> Tank >> >> 发件人: Aaron Durbin <adurbin(a)google.com> >> 发送时间: 2017年1月3日 7:23 >> 收件人: Nico Huber >> 抄送: Tang Tank; coreboot >> 主题: Re: [coreboot] logical error for smm hander in coreboot. >> >> On Tue, Jan 3, 2017 at 6:37 AM, Nico Huber <nico.huber(a)secunet.com> wrote: >>> Hi Tank, >>> >>> On 03.01.2017 04:20, Tang Tank wrote: >>>> >>>> Hi all, >>>> >>>> >>>> For smm handler (func smm_handler_start) in coreboot/src/cpu/x86/smm/smm_module_handler.c, >>>> there may be a logical error. >>>> >>>> If I have 4 cores in my mainboard in the following special conditions: >>>> 1. core0 run into smm_handler_start and smi_handler_status will be SMI_LOCKED. >>>> 2. core1/2 run into smm_handler_start and pause since smi_handler_status is locked. >>>> 3. core0 release smi_handler_status and then core4 run into smm_handler_start, it will do >>>> southbridge_smi_handler again. >>> >>> looking at the code, I too see that possible race. But... >>> >>>> >>>> So is there have a reliable way of doing smm multi processors services in coreboot? >>> >>> ...IMO, this isn't unreliable. After the first run of a cpu/northbridge >>> /southbridge_smi_handler() function, the cause of the SMI should be >>> handled and thus the second run should do nothing (but checking for the >>> SMI's cause). >>> >>> Does that help? I wasn't sure if I got your question right. >> >> >> Or you have to wait for all the CPUs to check in before dealing with >> the SMM handler logic. One would also have to deal with SMIs that were >> not broadcast since the other CPUs would never check in. >> >>> >>> Nico >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot > > > coreboot Info Page > www.coreboot.org > coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot > >> >> >> coreboot Info Page >> www.coreboot.org >> coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot >

1 0

Re: [coreboot] 答复: logical error for smm hander in coreboot.
by Nico Huber 05 Jan '17

05 Jan '17

Hi Tank, On 04.01.2017 02:39, Tang Tank wrote: > Hi Nico , Aaron, Zoran, > > Thank you for your help! > Smi_sts will been cleared after southbridge_smi_handler runs. > I am working for intel apollake now, need to do a thermal feature named DTS(Digital Thermal Sensor). > This need to check and modify MSR in smm for every core . is this MSR only accessible from SMM? or where does the requirement to do it in SMM come from? It sounds like something that's better done in the OS or ACPI. Nico > And when I add a mechanism to sync up bsp and aps like below struct , I found that I can't define and use the same static variable in ramstage and smmstage. > How can I do this? > > typedef struct { > spin_lock busy; > volatile ap_procedure procedure; > volatile void *parameter; > volatile u32 run; > volatile bool present; > } smm_cpu_data; > > typedef struct { > smm_cpu_data *cpu_data; > volatile u8 cpu_count; > volatile u32 bsp_index; //we will assusme index 0 as bsp > volatile bool all_cores_is_sync; > volatile u64 time_out_ticker; > } smm_mp_sync_data; > > Thanks, > Tank > > 发件人: Aaron Durbin <adurbin(a)google.com> > 发送时间: 2017年1月3日 7:23 > 收件人: Nico Huber > 抄送: Tang Tank; coreboot > 主题: Re: [coreboot] logical error for smm hander in coreboot. > > On Tue, Jan 3, 2017 at 6:37 AM, Nico Huber <nico.huber(a)secunet.com> wrote: >> Hi Tank, >> >> On 03.01.2017 04:20, Tang Tank wrote: >>> >>> Hi all, >>> >>> >>> For smm handler (func smm_handler_start) in coreboot/src/cpu/x86/smm/smm_module_handler.c, >>> there may be a logical error. >>> >>> If I have 4 cores in my mainboard in the following special conditions: >>> 1. core0 run into smm_handler_start and smi_handler_status will be SMI_LOCKED. >>> 2. core1/2 run into smm_handler_start and pause since smi_handler_status is locked. >>> 3. core0 release smi_handler_status and then core4 run into smm_handler_start, it will do >>> southbridge_smi_handler again. >> >> looking at the code, I too see that possible race. But... >> >>> >>> So is there have a reliable way of doing smm multi processors services in coreboot? >> >> ...IMO, this isn't unreliable. After the first run of a cpu/northbridge >> /southbridge_smi_handler() function, the cause of the SMI should be >> handled and thus the second run should do nothing (but checking for the >> SMI's cause). >> >> Does that help? I wasn't sure if I got your question right. > > > Or you have to wait for all the CPUs to check in before dealing with > the SMM handler logic. One would also have to deal with SMIs that were > not broadcast since the other CPUs would never check in. > >> >> Nico >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot > > > coreboot Info Page > www.coreboot.org > coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot

2 1

Re: [coreboot] 答复: logical error for smm hander in coreboot.
by Aaron Durbin 04 Jan '17

04 Jan '17

On Tue, Jan 3, 2017 at 7:39 PM, Tang Tank <js_nj_tanktang(a)outlook.com> wrote: > Hi Nico , Aaron, Zoran, > > Thank you for your help! > Smi_sts will been cleared after southbridge_smi_handler runs. > I am working for intel apollake now, need to do a thermal feature named DTS(Digital Thermal Sensor). > This need to check and modify MSR in smm for every core . > And when I add a mechanism to sync up bsp and aps like below struct , I found that I can't define and use the same static variable in ramstage and smmstage. > How can I do this? smmstage and ramstage are 2 completely different programs. You would need to port over the MP semantics into SMM. As you noted there's no support for this in SMM currently. > > typedef struct { > spin_lock busy; > volatile ap_procedure procedure; > volatile void *parameter; > volatile u32 run; > volatile bool present; > } smm_cpu_data; > > typedef struct { > smm_cpu_data *cpu_data; > volatile u8 cpu_count; > volatile u32 bsp_index; //we will assusme index 0 as bsp > volatile bool all_cores_is_sync; > volatile u64 time_out_ticker; > } smm_mp_sync_data; > > Thanks, > Tank > > 发件人: Aaron Durbin <adurbin(a)google.com> > 发送时间: 2017年1月3日 7:23 > 收件人: Nico Huber > 抄送: Tang Tank; coreboot > 主题: Re: [coreboot] logical error for smm hander in coreboot. > > On Tue, Jan 3, 2017 at 6:37 AM, Nico Huber <nico.huber(a)secunet.com> wrote: >> Hi Tank, >> >> On 03.01.2017 04:20, Tang Tank wrote: >>> >>> Hi all, >>> >>> >>> For smm handler (func smm_handler_start) in coreboot/src/cpu/x86/smm/smm_module_handler.c, >>> there may be a logical error. >>> >>> If I have 4 cores in my mainboard in the following special conditions: >>> 1. core0 run into smm_handler_start and smi_handler_status will be SMI_LOCKED. >>> 2. core1/2 run into smm_handler_start and pause since smi_handler_status is locked. >>> 3. core0 release smi_handler_status and then core4 run into smm_handler_start, it will do >>> southbridge_smi_handler again. >> >> looking at the code, I too see that possible race. But... >> >>> >>> So is there have a reliable way of doing smm multi processors services in coreboot? >> >> ...IMO, this isn't unreliable. After the first run of a cpu/northbridge >> /southbridge_smi_handler() function, the cause of the SMI should be >> handled and thus the second run should do nothing (but checking for the >> SMI's cause). >> >> Does that help? I wasn't sure if I got your question right. > > > Or you have to wait for all the CPUs to check in before dealing with > the SMM handler logic. One would also have to deal with SMIs that were > not broadcast since the other CPUs would never check in. > >> >> Nico >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot > > > coreboot Info Page > www.coreboot.org > coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot > >

1 0

Re: [coreboot] How does intelmetool's support for Skylake?
by Zoran Stojsavljevic 04 Jan '17

04 Jan '17

Hello Shawn, I am late, I apologize... New Year, everything is slow, me either. For me, the link you have provided does not work?! it is HTTP 404 (page not found). Could you, please, repost the valid link? Or to attach the given patch to this email? With the normal Coreboot intelmetool (where I added one more printk() to explore what are the device ids the tool looks into), I have the following: [root@localhost intelmetool]# uname -a Linux localhost.localdomain 4.8.15-300.fc25.x86_64 #1 SMP Thu Dec 15 23:10:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [1]+ Done emacs intelmetool.h [root@localhost intelmetool]# ./intelmetool -s dev->vendor_id = 0x8086, dev->device_id = 0x9c22 dev->vendor_id = 0x8086, dev->device_id = 0x9c03 *dev->vendor_id = 0x8086, dev->device_id = 0x9c43* *Bad news, you have a `8 Series LPC Controller` so you have ME hardware on board and you can't control or disable it, continuing...* *Error mapping physical memory 0x0000004275159040 [0x4000] ERRNO=1* *Segmentation fault (core dumped)* [root@localhost intelmetool]# lspci -nn | grep 9c22 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller [8086:9c22] (rev 04) [root@localhost intelmetool]# lspci -nn | grep 9c03 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] [8086:9c03] (rev 04) [root@localhost intelmetool]# lspci -nn | grep 9c43 00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller [8086:9c43] (rev 04) [root@localhost intelmetool]# Yet, in intelmetool.h it says explicitly: // Definitely has ME and is very difficult to remove [snap] #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_FULL 0x9c41 *#define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_PREM 0x9c43* #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_BASE 0x9c45 Coreboot ME pros, any comment on my HW (i5-4300U HSW ULT + PCH LynxPoint)? Appreciate any help! Thank you, Zoran On Fri, Dec 30, 2016 at 11:25 AM, Shawn <citypw(a)gmail.com> wrote: > This is a work around patch( I think?): > https://github.com/hardenedlinux/intelmetool/commit/ > ad778fc347b2bb0494abe2186632a072b8ad1a11 > > ./intelmetool -s > RCBA at 0x00000000 > MEI not hidden on PCI, checking if visible > MEI found: [8086:9d3a] Sunrise Point-LP CSME HECI > > ME Status : 0xa0000245 > ME Status 2 : 0x86110306 > > ME: FW Partition Table : OK > ME: Bringup Loader Failure : NO > ME: Firmware Init Complete : YES > ME: Manufacturing Mode : NO > ME: Boot Options Present : NO > ME: Update In Progress : NO > ME: Current Working State : Normal > ME: Current Operation State : M0 with UMA > ME: Current Operation Mode : Normal > ME: Error Code : No Error > ME: Progress Phase : Clean Moff->Mx wake > ME: Power Management Event : Pseudo-global reset > ME: Progress Phase State : Unknown 0x11 > > PCI READ [bc] : 0x000000bc > ME: Extend Register not valid > > ME seems okay on this board > WRITE [00] : CB: 0x80040007 > WRITE [00] : CB: 0x000002ff > READ [08] : CB: 0x801c0007 > READ [08] : CB: 0x000082ff > READ [08] : CB: 0x000b0000 > READ [08] : CB: 0x0000049c > READ [08] : CB: 0x000b0000 > READ [08] : CB: 0x0000049c > READ [08] : CB: 0x000b0000 > READ [08] : CB: 0x0000049c > ME: Firmware Version 11.0.1180.0 (code) 11.0.1180.0 (recovery) > 11.0.1180.0 (fitc) > WRITE [00] : CB: 0x80080007 > WRITE [00] : CB: 0x00000203 > WRITE [00] : CB: 0x00000000 > READ [08] : CB: 0x800d0007 > READ [08] : CB: 0x00008203 > READ [08] : CB: 0x00000000 > READ [08] : CB: 0x111a4004 > READ [08] : CB: 0x00000031 > ME Capability: Full Network manageability : OFF > ME Capability: Regular Network manageability : OFF > ME Capability: Manageability : OFF > ME Capability: Small business technology : OFF > ME Capability: Level III manageability : OFF > ME Capability: IntelR Anti-Theft (AT) : OFF > ME Capability: IntelR Capability Licensing Service (CLS) : ON > ME Capability: IntelR Power Sharing Technology (MPC) : OFF > ME Capability: ICC Over Clocking : ON > ME Capability: Protected Audio Video Path (PAVP) : ON > ME Capability: IPV6 : OFF > ME Capability: KVM Remote Control (KVM) : OFF > ME Capability: Outbreak Containment Heuristic (OCH) : OFF > ME Capability: Virtual LAN (VLAN) : ON > ME Capability: TLS : OFF > ME Capability: Wireless LAN (WLAN) : OFF > exiting > > On Fri, Dec 30, 2016 at 11:04 AM, Shawn <citypw(a)gmail.com> wrote: > > Hi Zoran, > > > > Thanks for the info. I added my Device ID into the intelmetool.h: > > > > diff --git a/intelmetool.h b/intelmetool.h > > index d79d6b0..16ca43a 100644 > > --- a/intelmetool.h > > +++ b/intelmetool.h > > @@ -225,6 +225,7 @@ > > #define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914 > > #define PCI_DEVICE_ID_INTEL_ICH9R 0x2916 > > #define PCI_DEVICE_ID_INTEL_ICH9 0x2918 > > +#define PCI_DEVICE_ID_INTEL_SUNRISE 0x9d3a > > > > #define PCI_DEV_CAN_DISABLE_ME_IF_PRESENT(x) ( \ > > ( (x) == PCI_DEVICE_ID_INTEL_ICH8 ) || \ > > @@ -232,6 +233,7 @@ > > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DH ) || \ > > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DO ) || \ > > ( (x) == PCI_DEVICE_ID_INTEL_ICH9R ) || \ > > + ( (x) == PCI_DEVICE_ID_INTEL_SUNRISE ) || \ > > ( (x) == PCI_DEVICE_ID_INTEL_ICH9 )) > > > > // Not sure at all > > > > This one should be the ME? > > +-16.0 Intel Corporation Sunrise Point-LP CSME HECI [8086:9d3a] > > > > #./intelmetool -s > > Not sure if ME hardware is present because you have a `Sunrise > > Point-LP CSME HECI`, but it is possible to disable it if you do, > > continuing... > > RCBA at 0x00000000 > > MEI not hidden on PCI, checking if visible > > MEI device not found, huh? > > exiting > > > > > > > > On Thu, Dec 29, 2016 at 12:50 AM, Zoran Stojsavljevic > > <zoran.stojsavljevic(a)gmail.com> wrote: > >>>> I'm not sure if intelmetool support Skylake as well. > >> > >> Investigated more. The coreboot intelmetool is the latest one, as I > >> understood (comparing one from github and coreboot). > >> > >> And Sunrise Point is NOT supported (look into latest coreboot's > >> coreboot/util/intelmetool/intelmetool.h). You can try to add it (as > Device > >> ID), manually, peek around the C code, and see if this can help you. > >> > >> Zoran > >> > >> On Wed, Dec 28, 2016 at 5:26 PM, Zoran Stojsavljevic > >> <zoran.stojsavljevic(a)gmail.com> wrote: > >>> > >>> Hello Shawn, > >>> > >>> Please, follow my CLI transcript from my Future Fedora 26 VM over WIN10 > >>> (now rawhide) with Fedora 4.8.15 kernel implanted (kernel 4.10.0-rc0 > gives > >>> me lot of griefs, I do not trust it, so I eliminated it for now): > >>> > >>> [zoran@localhost ~]$ cd projects/ > >>> [zoran@localhost projects]$ mkdir intelmetool > >>> [zoran@localhost projects]$ cd intelmetool/ > >>> [zoran@localhost intelmetool]$ pwd > >>> /home/zoran/projects/intelmetool > >>> [zoran@localhost intelmetool]$ uname -r > >>> 4.8.15-300.fc25.x86_64 > >>> [zoran@localhost intelmetool]$ git clone > >>> https://github.com/zamaudio/intelmetool.git > >>> Cloning into 'intelmetool'... > >>> remote: Counting objects: 214, done. > >>> remote: Total 214 (delta 0), reused 0 (delta 0), pack-reused 214 > >>> Receiving objects: 100% (214/214), 72.42 KiB | 0 bytes/s, done. > >>> Resolving deltas: 100% (125/125), done. > >>> [zoran@localhost intelmetool]$ ls -al > >>> total 12 > >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . > >>> drwxrwxr-x. 10 zoran zoran 4096 Dec 28 17:05 .. > >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 intelmetool > >>> [zoran@localhost intelmetool]$ cd intelmetool/ > >>> [zoran@localhost intelmetool]$ ls -al > >>> total 100 > >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . > >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. > >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git > >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore > >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c > >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h > >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE > >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile > >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c > >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h > >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c > >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c > >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h > >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md > >>> [zoran@localhost intelmetool]$ su -m > >>> Password: > >>> [root@localhost intelmetool]# make > >>> gcc -Wall -O0 -g -I. -c me_status.c -o me_status.o > >>> gcc -Wall -O0 -g -I. -c me.c -o me.o > >>> me.c: In function ‘mei_dump’: > >>> me.c:63:18: warning: variable ‘csr’ set but not used > >>> [-Wunused-but-set-variable] > >>> struct mei_csr *csr; > >>> ^~~ > >>> gcc -Wall -O0 -g -I. -c mmap.c -o mmap.o > >>> mmap.c: In function ‘map_physical_exact’: > >>> mmap.c:11:26: warning: passing argument 1 of ‘mmap’ makes pointer from > >>> integer without a cast [-Wint-conversion] > >>> virt_addr = mmap(mapto, len, PROT_WRITE | PROT_READ, > >>> MAP_SHARED|MAP_FIXED, > >>> ^~~~~ > >>> In file included from mmap.h:4:0, > >>> from mmap.c:1: > >>> /usr/include/sys/mman.h:57:14: note: expected ‘void *’ but argument is > of > >>> type ‘uint64_t {aka long unsigned int}’ > >>> extern void *mmap (void *__addr, size_t __len, int __prot, > >>> ^~~~ > >>> gcc -Wall -O0 -g -I. -o intelmetool intelmetool.o me_status.o me.o > mmap.o > >>> -lpci > >>> [root@localhost intelmetool]# date > >>> Wed Dec 28 17:07:26 CET 2016 > >>> [root@localhost intelmetool]# ls -al > >>> total 228 > >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:07 . > >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. > >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git > >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore > >>> -rwxr-xr-x. 1 root root 47008 Dec 28 17:07 intelmetool > >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c > >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h > >>> -rw-rw-r--. 1 zoran zoran 22144 Dec 28 17:06 intelmetool.o > >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE > >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile > >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c > >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h > >>> -rw-r--r--. 1 root root 28984 Dec 28 17:07 me.o > >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c > >>> -rw-r--r--. 1 root root 15704 Dec 28 17:07 me_status.o > >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c > >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h > >>> -rw-r--r--. 1 root root 7648 Dec 28 17:07 mmap.o > >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md > >>> [root@localhost intelmetool]# ./intelmetool > >>> ME is not present on your board because we found a `82371AB/EB/MB PIIX4 > >>> ISA`, you are safe, exiting > >>> [root@localhost intelmetool]# > >>> _______ > >>> > >>> Do NOT forget: I run Fedora rawhide on VMWorkstation 12.5.2 Type 2 HYP > on > >>> the top of WIN10 64 Pro! > >>> > >>> Please, do the same on Mint18 distro on raw HW, and see if this will > give > >>> you some different results then what you have presently? > >>> > >>> Please, let us know! > >>> > >>> Zoran > >>> > >>> On Wed, Dec 28, 2016 at 11:06 AM, Shawn <citypw(a)gmail.com> wrote: > >>>> > >>>> Hi Zoran, > >>>> > >>>> I created hwdb.bin via: > >>>> > >>>> # udevadm hwdb --update > >>>> > >>>> The result is still "segfault". dmesg: > >>>> > >>>> [ 972.044664] intelmetool[5055]: segfault at 16 ip 000000000040169e > >>>> sp 000072ed96a44680 error 4 in intelmetool[400000+6000] > >>>> [ 972.044674] grsec: Segmentation fault occurred at 0000000000000016 > >>>> in /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 > >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 > >>>> [ 972.044685] grsec: denied resource overstep by requesting 4096 for > >>>> RLIMIT_CORE against limit 0 for > >>>> /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 > >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 > >>>> > >>>> > >>>> On Mon, Dec 26, 2016 at 9:49 PM, Zoran Stojsavljevic > >>>> <zoran.stojsavljevic(a)gmail.com> wrote: > >>>> > Not sure if your strace log has anything to do with intelmetool. > >>>> > > >>>> > I did on your strace log the following (and in RED is possible > cause of > >>>> > your > >>>> > problems): > >>>> > > >>>> > [zoran@localhost projects]$ cat crash.log | grep ENOENT > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > open("/usr/share/misc/pci.ids.gz", O_RDONLY) = -1 ENOENT (No such > file > >>>> > or > >>>> > directory) > >>>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, > 110) > >>>> > = -1 > >>>> > ENOENT (No such file or directory) > >>>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, > 110) > >>>> > = -1 > >>>> > ENOENT (No such file or directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > open("/root/.pciids-cache", O_RDONLY) = -1 ENOENT (No such file or > >>>> > directory) > >>>> > open("/etc/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT > (No > >>>> > such > >>>> > file or directory) > >>>> > open("/etc/udev/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such > >>>> > file or > >>>> > directory) > >>>> > open("/usr/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 > ENOENT > >>>> > (No > >>>> > such file or directory) > >>>> > open("/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT > (No > >>>> > such > >>>> > file or directory) > >>>> > [zoran@localhost projects]$ > >>>> > > >>>> > I guess, you have one very important missing file in your Linux > >>>> > configuration, this one: /etc/systemd/hwdb/hwdb.bin... > >>>> > /etc/udev/hwdb.bin ?! > >>>> > > >>>> > Here is good read: > >>>> > https://www.freedesktop.org/software/systemd/man/hwdb.html > >>>> > > >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic= > systemd-hwdb&ampsect=8 > >>>> > > >>>> > Have no idea who is creating this file, but you can check your Linux > >>>> > distro > >>>> > / tree with the following paths to find hwdb.bin: > >>>> > > >>>> > /etc/systemd/hwdb/hwdb.bin > >>>> > /etc/udev/hwdb.bin <<======= In my Fedora > rawhide VM > >>>> > (future Fedora 26) I have here hwdb.bin ======= > >>>> > /usr/lib/systemd/hwdb/hwdb.bin > >>>> > /lib/systemd/hwdb/hwdb.bin > >>>> > > >>>> > If you don't have in any, please, create one with the following > link: > >>>> > > >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic= > systemd-hwdb&ampsect=8 > >>>> > > >>>> > Please, let us know! > >>>> > > >>>> > Zoran > >>>> > > >>>> > On Mon, Dec 26, 2016 at 3:42 PM, Shawn <citypw(a)gmail.com> wrote: > >>>> >> > >>>> >> Hi, > >>>> >> > >>>> >> intelmetool occurs "segfault" on my laptop running Mint 18 with > >>>> >> PaX/Grsecurity 4.7.10. The PCI info: > >>>> >> > >>>> >> -[0000:00]-+-00.0 Intel Corporation Sky Lake Host Bridge/DRAM > >>>> >> Registers [8086:1904] > >>>> >> +-02.0 Intel Corporation Sky Lake Integrated Graphics > >>>> >> [8086:1916] > >>>> >> +-04.0 Intel Corporation Skylake Processor Thermal > >>>> >> Subsystem [8086:1903] > >>>> >> +-14.0 Intel Corporation Sunrise Point-LP USB 3.0 xHCI > >>>> >> Controller [8086:9d2f] > >>>> >> +-14.2 Intel Corporation Sunrise Point-LP Thermal > >>>> >> subsystem [8086:9d31] > >>>> >> +-15.0 Intel Corporation Sunrise Point-LP Serial IO I2C > >>>> >> Controller [8086:9d60] > >>>> >> +-15.1 Intel Corporation Sunrise Point-LP Serial IO I2C > >>>> >> Controller [8086:9d61] > >>>> >> +-16.0 Intel Corporation Sunrise Point-LP CSME HECI > >>>> >> [8086:9d3a] > >>>> >> +-1c.0-[01]----00.0 NVIDIA Corporation GM107M [GeForce > GTX > >>>> >> 960M] [10de:139b] > >>>> >> +-1c.4-[02]----00.0 Samsung Electronics Co Ltd NVMe SSD > >>>> >> Controller [144d:a802] > >>>> >> +-1c.6-[03]----00.0 Qualcomm Atheros Killer E2400 > Gigabit > >>>> >> Ethernet Controller [1969:e0a1] > >>>> >> +-1c.7-[04]----00.0 Qualcomm Atheros QCA6174 802.11ac > >>>> >> Wireless Network Adapter [168c:003e] > >>>> >> +-1d.0-[05]----00.0 Samsung Electronics Co Ltd NVMe SSD > >>>> >> Controller [144d:a802] > >>>> >> +-1d.2-[06-3e]-- > >>>> >> +-1f.0 Intel Corporation Sunrise Point-LP LPC > Controller > >>>> >> [8086:9d48] > >>>> >> +-1f.2 Intel Corporation Sunrise Point-LP PMC > [8086:9d21] > >>>> >> +-1f.3 Intel Corporation Sunrise Point-LP HD Audio > >>>> >> [8086:9d70] > >>>> >> \-1f.4 Intel Corporation Sunrise Point-LP SMBus > >>>> >> [8086:9d23] > >>>> >> > >>>> >> The crash log was attached! I'm not sure if intelmetool support > >>>> >> Skylake as well. One tiny feature of PaX/Grsecurity prevent the > ioperm > >>>> >> for killing the potential threats in case which > >>>> >> the adversary re-flash the SPI ROM once they get the root priv. It > >>>> >> does affect flashrom but intelmetool. I also ran intelmetool on the > >>>> >> distro( Mint 18) kernel and got the same result. > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> GNU powered it... > >>>> >> GPL protect it... > >>>> >> God blessing it... > >>>> >> > >>>> >> regards > >>>> >> Shawn > >>>> >> > >>>> >> -- > >>>> >> coreboot mailing list: coreboot(a)coreboot.org > >>>> >> https://www.coreboot.org/mailman/listinfo/coreboot > >>>> > > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> GNU powered it... > >>>> GPL protect it... > >>>> God blessing it... > >>>> > >>>> regards > >>>> Shawn > >>> > >>> > >> > > > > > > > > -- > > GNU powered it... > > GPL protect it... > > God blessing it... > > > > regards > > Shawn > > > > -- > GNU powered it... > GPL protect it... > God blessing it... > > regards > Shawn >

1 0

答复: logical error for smm hander in coreboot.
by Tang Tank 04 Jan '17

04 Jan '17

Hi Nico , Aaron, Zoran, Thank you for your help! Smi_sts will been cleared after southbridge_smi_handler runs. I am working for intel apollake now, need to do a thermal feature named DTS(Digital Thermal Sensor). This need to check and modify MSR in smm for every core . And when I add a mechanism to sync up bsp and aps like below struct , I found that I can't define and use the same static variable in ramstage and smmstage. How can I do this? typedef struct { spin_lock busy; volatile ap_procedure procedure; volatile void *parameter; volatile u32 run; volatile bool present; } smm_cpu_data; typedef struct { smm_cpu_data *cpu_data; volatile u8 cpu_count; volatile u32 bsp_index; //we will assusme index 0 as bsp volatile bool all_cores_is_sync; volatile u64 time_out_ticker; } smm_mp_sync_data; Thanks, Tank 发件人: Aaron Durbin <adurbin(a)google.com> 发送时间: 2017年1月3日 7:23 收件人: Nico Huber 抄送: Tang Tank; coreboot 主题: Re: [coreboot] logical error for smm hander in coreboot. On Tue, Jan 3, 2017 at 6:37 AM, Nico Huber <nico.huber(a)secunet.com> wrote: > Hi Tank, > > On 03.01.2017 04:20, Tang Tank wrote: >> >> Hi all, >> >> >> For smm handler (func smm_handler_start) in coreboot/src/cpu/x86/smm/smm_module_handler.c, >> there may be a logical error. >> >> If I have 4 cores in my mainboard in the following special conditions: >> 1. core0 run into smm_handler_start and smi_handler_status will be SMI_LOCKED. >> 2. core1/2 run into smm_handler_start and pause since smi_handler_status is locked. >> 3. core0 release smi_handler_status and then core4 run into smm_handler_start, it will do >> southbridge_smi_handler again. > > looking at the code, I too see that possible race. But... > >> >> So is there have a reliable way of doing smm multi processors services in coreboot? > > ...IMO, this isn't unreliable. After the first run of a cpu/northbridge > /southbridge_smi_handler() function, the cause of the SMI should be > handled and thus the second run should do nothing (but checking for the > SMI's cause). > > Does that help? I wasn't sure if I got your question right. Or you have to wait for all the CPUs to check in before dealing with the SMM handler logic. One would also have to deal with SMIs that were not broadcast since the other CPUs would never check in. > > Nico > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot coreboot Info Page www.coreboot.org coreboot project mailing list. To see the collection of prior postings to the list, visit the coreboot Archives. Using coreboot

1 0

Re: [coreboot] logical error for smm hander in coreboot.
by Zoran Stojsavljevic 03 Jan '17

03 Jan '17

Hello Tang, Not sure what is actually your question here? If you have 4 cores in your mainboard, the BIOS (any BIOS, looking into SEC + PEI phases), will work on the following way (more or less, it is view from 37000 feet, where commercial jetliners operate): [1] BIOS on main CPU will start after EC configures PMIC and PCH does the original HECI setup; [2] All four cores will be let go out of hard reset state, but they will compete who is the system one, and who are so-called application processors; The first which will configure the bare minimum wins, and it'll be Core 0 (called BSP - BootStrap Processor), all others will be Cores X, X = [1..3], application ones; [3] Core 0 (BSP) will continue running BIOS code, all others (application) cores will be put in waiting state, waiting for SIPI (Startup Inter-Processor Interrupt), send via BSP's LAPIC (MSIs - Message Serviced Interrupts are not allowed in BIOS); [4] While BSP runs, it runs also entering several times SMM mode using SMI, in order to set ACPI (Advanced Configuration and Power Interface) tables, or similar... Coreboot people can compare if the similar, described above) is happening with Coreboot code. Should, in my opinion (so NO multiprocessing done in Coreboot, my best guess). For x86 and x86_64 architectures. Zoran On Tue, Jan 3, 2017 at 4:20 AM, Tang Tank <js_nj_tanktang(a)outlook.com> wrote: > > Hi all, > > > For smm handler (func smm_handler_start) in > coreboot/src/cpu/x86/smm/smm_module_handler.c, > there may be a logical error. > > If I have 4 cores in my mainboard in the following special conditions: > 1. core0 run into smm_handler_start and smi_handler_status will be > SMI_LOCKED. > 2. core1/2 run into smm_handler_start and pause since > smi_handler_status is locked. > 3. core0 release smi_handler_status and then core4 run into > smm_handler_start, it will do > southbridge_smi_handler again. > > So is there have a reliable way of doing smm multi processors services > in coreboot? > > > Thanks > Tank > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

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 January 2017