coreboot September 2017

coreboot@coreboot.org

57 participants
132 discussions

Re: [coreboot] [kernel-hardening] ME and PSP
by ron minnich 07 Sep '17

07 Sep '17

On Thu, Sep 7, 2017 at 1:07 AM Shawn <citypw(a)gmail.com> wrote: > > RISC-V doesn't have NDA issues like x86 which the firmware freedom > will get benefit of it. > Speaking as someone who has been working on and off with riscv for almost four years, and who has ported coreboot several times and plan 9 once, I can tell you it's not that easy. Chips being produced today will require blobs, for dram and usb at least. RISCV does not require a license. That's the big change, and it is a great change. But that one difference is not enough to eliminate the problems we have with the x86 world today. All the really hard parts of coreboot ports have involved things not related to the instruction set, such as DRAM, PCI configuration, and so on. All those things can be done in a proprietary way without violating RISCV rules. I don't think we can assume that an open, unlicensed instruction set guarantees open, unlicensed, blob-free CPUs and platforms. It's just not so. If we wait for that to happen, we're going to be disappointed.

1 0

Re: [coreboot] About Paging, Realmode and what is going on
by ron minnich 07 Sep '17

07 Sep '17

On Thu, Sep 7, 2017 at 1:43 AM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > Please, could you try to do this with INTEL ATOM or CORE in this time for > this price? ;-) > > > This is a very interesting point about time to market, which is everything nowadays. I regret that ARM decided to take such a strong UEFI position with the v8 but maybe the market will force them back to more openness. Zoran, you make a good economic point for openness. Let's hope RISCV avoids the same UEFI mistake, though companies like HP seem to want to push them into UEFI.

1 0

Moving the command line for Linux kernel payloads
by Trammell Hudson 07 Sep '17

07 Sep '17

A minor installation improvement that I've found is to rearrange the Linux kernel command line to be last segment in the payload. This allows me to tweak boot time parameters without having to re-write the entire kernel and initrd in the flash. Is there a current or historical reason for the ordering? diff --git a/util/cbfstool/cbfs-payload-linux.c b/util/cbfstool/cbfs-payload-linux.c index 6b4bf27..ccbcb33 100644 --- a/util/cbfstool/cbfs-payload-linux.c +++ b/util/cbfstool/cbfs-payload-linux.c @@ -312,14 +312,14 @@ int parse_bzImage_to_payload(const struct buffer *input, bzp_output_segment(&bzp, &bzp.trampoline, PAYLOAD_SEGMENT_CODE, TRAMPOLINE_ENTRY_LOC); - /* cmdline */ - bzp_output_segment(&bzp, &bzp.cmdline, - PAYLOAD_SEGMENT_DATA, COMMAND_LINE_LOC); - /* initrd */ bzp_output_segment(&bzp, &bzp.initrd, PAYLOAD_SEGMENT_DATA, initrd_base); + /* cmdline */ + bzp_output_segment(&bzp, &bzp.cmdline, + PAYLOAD_SEGMENT_DATA, COMMAND_LINE_LOC); + /* Terminating entry segment. */ bzp_output_segment(&bzp, NULL, PAYLOAD_SEGMENT_ENTRY, TRAMPOLINE_ENTRY_LOC); -- Trammell

3 2

Re: [coreboot] About Paging, Realmode and what is going on
by Peter Stuge 07 Sep '17

07 Sep '17

Julius Werner wrote: > while the program was running it mostly interacted with the BIOS directly. Not in general - that is/was highly dependent on the program. BIOS interrupt services offer a hardware abstraction, but they come at a (high! interrupts are very expensive!) cost. For anything performance sensitive, e.g. games, multitasking environments (DESQview, Windows) or terminal emulators communicating via serial ports which may or may not have a FIFO, the BIOS overhead is simply unacceptable. Such programs instead interacted directly with the hardware, having implemented drivers for some graphics and sound cards, UARTs etc. Even the mouse BIOS interrupt services are pretty much unusable for anything serious. //Peter

1 0

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H
by Nico Huber 07 Sep '17

07 Sep '17

Hello Alberto, 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). it's rather unlikely that a board supports it when the manufacturer doesn't mention it. ECC support needs additional traces on the main- board (as the bus is 72 bits wide instead of 64 bits). So just having compatible chips doesn't suffice. Nico

2 1

Re: [coreboot] About Paging, Realmode and what is going on
by Zoran Stojsavljevic 07 Sep '17

07 Sep '17

> 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.* This is the reason why INTEL has no chance to win IoT race with ARM (just in few special use cases). With all these compatibilities, and test modes, INTEL is forcing customers to the HW CLOSED model, forcing as well Firmware CLOSED model (with 10x more silicon/HW extensions to comply, and end users/customers are paying for that). Since there are gazillion of boot registers which need to be set-up properly for modes to work as intended. Having concept of Device Tree Usage (HW OPEN model, forcing FW/BSP OPEN model), I can, having one very smart HW designer (with random IO controller order with ARM SoCs: i.MX6/7/8, tegra, etc.), build the whole ARM based SoC HW and whole system SW including FW, application tools rich root-tree, and Device Drivers in few weeks using YOCTO. Board Plug & Play, ready for Application, written in Qt5, Java, C++ with all tools, U name it! https://events.linuxfoundation.org/sites/events/files/slides/petazzoni- device-tree-dummies.pdf So, Device Tree Usage + YOCTO = 2 experienced men work from scratch with the COMPLETE embedded solution for 2 to 3 weeks. Mini com express for around 20 to 100 EUR a piece? Please, could you try to do this with INTEL ATOM or CORE in this time for this price? ;-) Zoran Stojsavljevic On Thu, Sep 7, 2017 at 2:23 AM, ron minnich <rminnich(a)gmail.com> wrote: > 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 > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

R: Re: INT 13, real mode, block write commands and coreboot
by ingegneriaforense＠alice.it 07 Sep '17

07 Sep '17

Dear Vincent, dear guys thanks very much for your reply. >I don't own a raspi, just another SBC like it. I think that the embedded solution is the best. However, Raspberry hasn't SATA ports, only USBs. Please, can you suggest me a SBC like Raspy that also allows SATA connections (eSATA) ? Important is that the SBC support UBUNTU / UBUNTU-like O.S. >There is no PC BIOS on it, there is firmware for booting, but (I may be wrong) it is not active after boot. In fact, this is the important thing; I need of a system whose firmware for booting 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 Ok, I'm agree with you. I have no problem to block the automounting for UBUNTU / UBUNTU-like O.S. In fact my aim is to use: dd if=/dev/sdX of=$HOME/usbkeyimage.raw bs=1M to make an image of the suspect drive. I hope to hear you soon. Thanks in advance. Best Regards. Vincenzo. Forensic Consultant Tribunale di Lecce Studio: Strada di Garibaldi - Contrada Paradisi 73010 Lequile (LE) cell: 339.7968555 skype: vincenzo.di_salvo ----Messaggio originale---- Da: vincent.legoll(a)gmail.com Data: 5-set-2017 9.57 A: "ingegneriaforense(a)alice.it"<ingegneriaforense(a)alice.it>, "Coreboot"<coreboot(a)coreboot.org> Ogg: Re: [coreboot] INT 13, real mode, block write commands and coreboot 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 -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] [kernel-hardening] ME and PSP
by Shawn 07 Sep '17

07 Sep '17

Hi Ron, On Thu, Sep 7, 2017 at 12:30 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Wed, Sep 6, 2017 at 8:07 PM Shawn <citypw(a)gmail.com> wrote: >> >> >> IMOHO, RISC-V will be the long-term solution in the future;-) >> > > people need to stop saying that. It's not that simple. And, sadly, riscv may > be baking in an SMM-like mode that you can't turn off. > > RISCV is neat but it's nowhere near the total solution. You can build a very > closed system with RISCV very easily. RISCV doesn't magically take away ME- > and PSP-like problems. > RISC-V doesn't have NDA issues like x86 which the firmware freedom will get benefit of it. And yes, the vendor can build a closed system with RISC-V cu'z RISC-V is not GPL-like license. But it should be much easier to buy( It'd be much harder get the ThreadX/ARC-based stuff from Intel even if you are willing to pay?) the source code/solution from the vendor w/o any NDA restriction. RISC-V is not a magic to bring us the firmware freedom but provide more options. -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

Re: [coreboot] [kernel-hardening] ME and PSP
by Philipp Stanner 07 Sep '17

07 Sep '17

Am Donnerstag, den 07.09.2017, 04:30 +0000 schrieb ron minnich: > > very closed system with RISCV very easily. RISCV doesn't magically > take > away ME- and PSP-like problems. But it will magically take away microcode and maybe compatibility-modes – what will already be a progress. Both in slimming down the architecture and getting rid of security and privacy threats. The Usenix this year presented an interesting exploit [1]. P. [1] http://syssec.rub.de/media/emma/veroeffentlichungen/2017/08/16/usen ix17-microcode.pdf

1 0

Re: [coreboot] [kernel-hardening] ME and PSP
by ron minnich 07 Sep '17

07 Sep '17

On Wed, Sep 6, 2017 at 8:07 PM Shawn <citypw(a)gmail.com> wrote: > > IMOHO, RISC-V will be the long-term solution in the future;-) > > people need to stop saying that. It's not that simple. And, sadly, riscv may be baking in an SMM-like mode that you can't turn off. RISCV is neat but it's nowhere near the total solution. You can build a very closed system with RISCV very easily. RISCV doesn't magically take away ME- and PSP-like problems. ron >

1 0

← Newer
1
...
8
9
10
11
12
13
14
Older →

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