September 2017 - coreboot - mail.coreboot.org

Re: [coreboot] [kernel-hardening] ME and PSP
by Shawn Sept. 7, 2017

Sept. 7, 2017

Hi Sandy, On Thu, Sep 7, 2017 at 2:37 AM, Sandy Harris <sandyinchina(a)gmail.com> wrote: > Recently a few things have been revealed about how to disable the > Intel Management Engine (ME). > > http://blog.ptsecurity.com/2017/08/disabling-intel-me.html > https://www.theregister.co.uk/2017/08/29/intel_management_engine_can_be_dis… > > I have not seen anything on disabling the similar AMD feature called > PSP. Either appears to be a huge security hazard -- a device you have > little choice but to trust but that you have little control over, that > operates below the level of the main CPU & OS, that has access to > everything & that is Turing complete so it can do anything. > There's not much public research about AMD PSP yet. From the SW/FW/HW's perspective, a hardened kernel is still important( that's why PaX/Grsecurity matters a lot) to prevent some attack surfaces from lower level( let's say Hypervisor( RING -1)/SMM( RING -2/ME( RING -3)). But the lower level should be concerned as well. We've been pushing this solution into our customer's production and it's looking good so far: https://github.com/hardenedlinux/hardenedlinux_profiles/blob/master/slide/h… > By the time a hardened kernel loads, it may be too late to prevent ME > entirely, but are there other things the kernel could do? Issue a > syslog warning? Monitor ME activity somehow? Restrict its access to > the network so at least external attacks are blocked? > Intel ME has a OS kernel( ThreatdX/MINIX-based) running on a specific CPU( < v11 is ARC, >=v12 is x86). There's not much kernel can do about it except a few LKMs( mei/mei_me) can getting some info from the ME. > There are several different utilities to reduce ME danger, though I > have not looked at details & I have the impression most do not disable > it completely. Will current hardened kernels run on a system with ME > disabled? Is that tested? > There are two ways to "disable" ME: 1) Before Mark Ermolov and Maxim Goryachy disclosured this HAP "secrects" to the public, what me_cleaner( https://github.com/corna/me_cleaner/) does was removing more ME code modules as possible and only keep those necessary ones( like BUP/ROMP/etc). It's not 100% disable it but neutralization achieve the similar goal. me_cleaner is a free/libre software, all you need to prepare is a few cheap hardwares( external programmer): https://hardenedlinux.github.io/firmware/2016/11/17/neutralize_ME_firmware_… 2) Thanks to Mark Ermolov and Maxim Goryachy, now me_cleaner added an option( -s) can enabled the HAP bit but keep other code modules as well. Plz note that some private OEM firmware implementation might have some side-effects while coreboot is working perfectly( less SMIs helps?) so far. There are some public test results you can find: https://github.com/hardenedlinux/hardenedlinux_profiles/tree/master/coreboot https://github.com/corna/me_cleaner/issues/53 > The best summary of the issue I have seen -- though it is neither > up-to-date nor devoted to only the one issue is: > https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf > > There has been discussion on the Qubes users list: > https://groups.google.com/forum/#!forum/qubes-users > More fw/ME info: https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/me_in… https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/firmw… > The only plausible solutions suggested there boil down to not using > recent x86 chips at all. Either use older Intel/AMD parts without the > feature or go to IBM Power CPUs. > IMOHO, RISC-V will be the long-term solution in the future;-) btw: this might a little bit off-topic on kernel-hardening( I could be wrong if it weren't). Or feel free to ask question on coreboot's mailinglist: coreboot(a)coreboot.org -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

Re: [coreboot] About Paging, Realmode and what is going on
by ron minnich Sept. 7, 2017

Sept. 7, 2017

The original statement about BIOS -- that it was a second OS from the first day on -- is not correct. I am pretty sure the term BIOS (Basic Input Output Subsystem) comes from the early days, from CP/M. That's when I started hearing it anyway. The BIOS was the bottom half of CP/M. It provided an abstract device interface that the top half -- the part that came on a floppy -- could use. So the BIOS was not a second OS. It was 1/2 the OS you ran. Vendors created hardware and BIOS for the (usually 1024 byte) ROM and that ensured that CP/M could run on their box. The part of CP/M on the floppy, and the part in EEPROM, combined to provide a kernel. Kernel, of course, being a very loose term given the lack of processor modes. This was a very different model from, e.g., the minicomputers of the day, wherein the ROM was used to boot a kernel and then it got out of the way. So BIOS nature as a runtime entity was established very early on. Linux, for a long time, did not need no steenkin' BIOS (you can find that quote if you look back far enough). But those days are gone. ron On Wed, Sep 6, 2017 at 5:09 PM Julius Werner <jwerner(a)chromium.org> wrote: > > The awkward thing about BIOS is that it was a second OS from the first > > day on – while the reasonable philosophy behind firmware should be: > > Start the board, load the OS and go back into your flash until reboot. > > My history lessons may be failing me here, but IIRC the main reason > for that was memory: DOS wasn't a full OS in the modern sense, it was > pretty much just a shell and a collection of utility programs. All the > actual device driving was done by the BIOS. So if you compare it with > a modern GNU/Linux machine, the BIOS was equivalent to Linux and DOS > to the GNU parts. > > The original IBM PC had so little memory that they couldn't really > afford to waste any of it on stuff like device drivers. So they put > the drivers in flash where they could be executed in-place, which > became the BIOS. Most of DOS itself (essentially the command.com > shell) was just unloaded whenever you launched a program and re-loaded > from disk afterwards, and while the program was running it mostly > interacted with the BIOS directly. > > So you're right that from our current point of view that having > callbacks into firmware makes little sense, but back then they were > working with what they had and it was pretty much the only way to get > as much out of the machine as they needed. The BIOS was really the > first OS on the platform, and all those later ones that implement > their own drivers (Windows, Linux) are breaking with the intended > paradigm. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] About Paging, Realmode and what is going on
by Peter Stuge Sept. 7, 2017

Sept. 7, 2017

Zoran Stojsavljevic wrote: > > But a bootloader built as a payload could also be built to use BIOS > > interfaces. GRUB is one example of this. > > Let us assume the following configuration: > FSP -> Coreboot -> Payload: GRUB2 -> Linux > > No legacy interrupts, correct? Correct. > So, what is this for the architecture? CSM? UEFI look alike? Neither. There are no callbacks of any kind. Neither BIOS services nor UEFI runtime services (which are like BIOS services, but much more complicated for no reason other than inventor job security) are present here. coreboot does export a "coreboot tables" data structure in RAM, e.g. with a memory map, and depending on build settings potentially also legacy tables such as ACPI, which may required by the operating system. coreboot tables contain only data, no code. > I assume, the Linux image on the HDD/SSD was installed far before as CSM, > so there is already existing MBR, and some CSM implemented legacy services > (INTs) already exist, am I correct? No. The MBR is irrelevant in the above scenario, it is never read. GRUB2 uses its own disk and filesystem drivers to locate and load the configured kernel and possibly initramfs files. How the kernel and userland files got onto the disk drive is also irrelevant. Beyond a recognized partition table, GRUB configuration file and kernel files in the right directory on a supported filesystem, nothing else matters. The same is true for FILO. The payload directly reads the filesystem from disk, no boot sector is used. > I assume UEFI installed Linux would NOT run, since GRUB2 will be not able > to find MBR... I assume GRUB2 as payload to Coreboot assumes MBR/Legacy > (by default) implementation. Again, it does not matter how Linux was installed, as long as GRUB2 can locate the kernel on the filesystem. > Any comments on what I wrote here? ;-) coreboot with its payloads offers significant advantages over legacy BIOS and stillborn UEFI architectures. //Peter

4 4

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H
by Alberto Bursi Sept. 6, 2017

Sept. 6, 2017

On 09/06/2017 09:30 PM, Alberto Bursi wrote: > I've stumbled upon a Asrock IMB-A180-H board (a eKabini-based > "industrial" mini-itx motherboard) on ebay and since it is supported by > Coreboot I was considering about purchasing it. > > The APU onboard supports ECC ram (ECC so-dimms are kinda rare but I can > find them), while of course the Asrock site does not say anything about > ECC support (how unexpected). > > I was wondering if Coreboot can enable ECC ram support on this board, > and how to do so (I can read the docs on my own for the rest). > > I cc'ed this email to Martin Roth because while googling I found his > personal page in the coreboot wiki, and there he states he has 2 Asrock > IMB-A180 (same board with one HDMI and one LVDS port instead of 2 HDMI > ports), so he might know this board better. > > -Alberto > Sent too soon, now it has a proper subject line. -Alberto

1 0

(no subject)
by Alberto Bursi Sept. 6, 2017

Sept. 6, 2017

I've stumbled upon a Asrock IMB-A180-H board (a eKabini-based "industrial" mini-itx motherboard) on ebay and since it is supported by Coreboot I was considering about purchasing it. The APU onboard supports ECC ram (ECC so-dimms are kinda rare but I can find them), while of course the Asrock site does not say anything about ECC support (how unexpected). I was wondering if Coreboot can enable ECC ram support on this board, and how to do so (I can read the docs on my own for the rest). I cc'ed this email to Martin Roth because while googling I found his personal page in the coreboot wiki, and there he states he has 2 Asrock IMB-A180 (same board with one HDMI and one LVDS port instead of 2 HDMI ports), so he might know this board better. -Alberto

1 0

Re: [coreboot] Owner-controlled POWER9 Talos II [was: Disabling Intel ME 11 via undocumented mode]
by Timothy Pearson Sept. 6, 2017

Sept. 6, 2017

On 09/06/2017 06:48 AM, Rene Shuster wrote: > So a case of "Dig before you call"? > Anyways I'm re-sending my questions since it appears that you didn't > receive them yesterday... > > Timothy, > Ubuntu Server is officially supporting Power8 > ( https://www.ubuntu.com/download/server/power8 > <https://www.ubuntu.com/download/server/power8> ). Do you have insight > if they will support Power9? Yes, they will. > What's the name of the chipset your board > will be using? There is no chipset per se; as on most OpenPOWER systems the POWER PCIe lanes are brought directly out to the various on-board peripherals. Also c an we get a complete overview of all the I/O ports > with Make and Model#. I see what looks like 4 SATA ports (in 2 different > colors) on the board > ( https://static.rptorcs.com/TL2B01/images/boardsmall.png > <https://static.rptorcs.com/TL2B01/images/boardsmall.png> ), but they > are missing in the documentation > ( https://raptorcs.com/content/TL2B01/intro.html > <https://raptorcs.com/content/TL2B01/intro.html> ). The ports in question are driven off of the Microsemi SAS controller, so they work for both SAS and SATA. USB is driven by a TI USB 3.0 controller; serial is passed through the BMC (standard OpenPOWER design). > I would also like to > know what make & model the SATA controller is and the model of the > Broadcom NIC chip for example. BCM5719. There's some good info about the internals of the chip online [1] that provides a starting point to write a replacement firmware if you're interested. Otherwise, like all other peripherals, the NIC is behind the IOMMU and cannot access data in the CPU domain without kernel permission. > You might also want to add info to the site about the optional Microsemi > SAS 3.0 RAID controller. Right now it's unclear which one of their many > ICs will be onboard (I assume it will be > RAID-on-Chip: https://www.microsemi.com/product-directory/storage-ics/3689-raid-controlle… > <https://www.microsemi.com/product-directory/storage-ics/3689-raid-controlle…> ). I'll bring this up internally. It's the PM8068 controller (SmartIOC 2000). > > Else keep up the good work and t hanks for making this happen. No problem, thanks for the encouragement! [1] http://esec-lab.sogeti.com/static/publications/10-hack.lu-nicreverse_slides… -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com

3 2

Re: [coreboot] Owner-controlled POWER9 Talos II [was: Disabling Intel ME 11 via undocumented mode]
by Taiidan＠gmx.com Sept. 6, 2017

Sept. 6, 2017

What happened to Tim and the raptor sites? All of them are down and I get an error when sending him an email :'[

4 3

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Taiidan＠gmx.com Sept. 6, 2017

Sept. 6, 2017

I can't download the .pdf file for some reason (maybe the tla's got to it?) http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf can someone send it to me? Thanks Thoughts: Sad this is still not an actual method of disablement, but it doesn't really matter as anyone who buys *new* x86 hardware is still supporting wintel's development of newer and better anti-features, DRM and surveillance technology - one that can't even be me-cleaner/hap/etc nerfed will be released some day. I wish people spent their energy popularizing owner controlled arches instead of beating a dead horse. While IBM also makes surveillance tech they make POWER which as the last performance owner controlled arch that sells for attainable prices goes a long way to offset that. Heres to hoping IBM starts selling POWER workstations... I find it hard to believe that the NSA uses made in china intel stuff with ME chips present for their high security stuff (hap nerfed or not), I imagine top secret things are done on POWER (which has a USA cpu fab and no black boxes).

6 7

Re: [coreboot] [flashrom] Erase failure on Sapphire Pure Platinum H61 with coreboot
by Nico Huber Sept. 5, 2017

Sept. 5, 2017

Hi Nicola, On 02.09.2017 15:06, Nicola Corna wrote: > Hi, > > I have a Sapphire Pure Platinum H61 with coreboot and flashrom fails > to erase the flash chip (corrupting the image); attached you can find > the log. oh, the error message is rather subtle. I'll spare you the details. The actual problem is that your flash chip is rather unlikely and the write aai (0xad) and write disable (0x04) op codes are not in the list coreboot set as allowed op codes: > 0x98: 0x05030201 (OPMENU) > 0x9C: 0x0bd89f20 (OPMENU+4) Each byte here is one allowed op code. Now, to makes things worse, core- boot and flashrom use different sets of codes (e.g. flashrom uses read (0x03), coreboot uses fast read (0x0b)). The currently hardcoded list is define in sb/intel/bd82x6x/pch.h for your board. For full compatibi- lity with every coreboot feature that uses the flash (e.g. elog, flash console) and flashrom, you'd have to find a set of op codes that always works. One question, though, is this the original flash chip of your board? If not, any effort to make it supported is probably wasted. If it is the original chip, I'd go this way: Make the op menu that coreboot sets in bd82x6x/finalize.c configurable through the devicetree. I'd leave the defaults from pch.h in place in case the devietree settings are left at zero. >From the original op menu these are probably unneeded: byte program (0x02), either one of the block erasers (0x20 and 0xd8) and the fast read (0x0b). Probably working (with flashrom) op menu for your chip: 0x05030201 0x04ad9f20 > > Before coreboot's commit d533b16 the internal flashing worked after a > fresh start, while after a S3 resume it failed with the same error. > Starting from this commit, the internal flashing doesn't work at all. For the record, this commit enabled the SPI lockdown (e.g. locked the OPMENU). Which was previously only set after resume by accident. > > As suggested by Nico Huber, I tried with `-p > internal:ich_spi_mode=hwseq`, without success (log attached). > Ah, I see why it didn't detect a chip. In the hardware sequencing mode, the actual communication with the flash chip is left to the PCH. We can't even probe for the chip, so giving it `-c SST25VF032B` makes it fail. Nico

2 4

Re: [coreboot] INT 13, real mode, block write commands and coreboot
by Vincent Legoll Sept. 5, 2017

Sept. 5, 2017

Hello, Please keep the discussion on-list, for the sake of others searching for the same infos. On Tue, Sep 5, 2017 at 7:43 AM, ingegneriaforense(a)alice.it <ingegneriaforense(a)alice.it> >>Plug it in, dump it without mounting any eventual partitions, and you're > done. > You can derive from threre for other interfaces like SATA... > > Please, about Raspberry, are you sure that plugging a usb drive into it, any > partitions will not be mounting ? Maybe you have the Raspberry and you have > noticed this behavior ? I don't own a raspi, just another SBC like it. There is no PC BIOS on it, there is firmware for booting, but (I may be wrong) it is not active after boot. The automounting of partitions is a property of the operating system, so you should make sure to disable it if you don't want your usb keys to be automounted, Just search in the docs of your linux distribution of choice for a way to do that, should be fairly straightforward. (subjects to search: automount, udev, systemd, sysv-init, etc...) > I'll check to understand better the raspberry chain: BIOS->PAYLOAD->KERNEL > contacting the Raspberry technical support. I don't think you'll met a lot of ARM SBCs with coreboot, they are mostly using the u-boot bootloader. But the important thing for you is that the firmware is not used after boot and that the OS don't touch the HW. So, as long as the USB key is only plugged after boot, the firmware won't have the chance to touch it. After that a simple: dd if=/dev/sdX of=$HOME/usbkeyimage.raw bs=1M and you should have a copy of it to search what you're after. If you're paranoid, make three distinct copies, sha256sum the key, etc... You should learn how to use those tools. But beware this is only scratching the surface, if you're after someone who knows his thing, you'll have to eventually go deeper, as some disk firmwares have already been modified to hide some data even from the OS. -- Vincent Legoll

1 0