coreboot September 2017

coreboot@coreboot.org

57 participants
132 discussions

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

08 Sep '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1380991: Code maintainability issues (UNUSED_VALUE) /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 1114 in vb2_recovery_menu() ________________________________________________________________________________________________________ *** CID 1380991: Code maintainability issues (UNUSED_VALUE) /3rdparty/vboot/firmware/lib/vboot_ui_menu.c: 1114 in vb2_recovery_menu() 1108 break; 1109 case VB_BUTTON_VOL_UP: 1110 case VB_BUTTON_VOL_DOWN: 1111 case VB_KEY_UP: 1112 case VB_KEY_DOWN: 1113 if (current_menu == VB_MENU_RECOVERY_INSERT) { >>> CID 1380991: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "vb2_update_menu(ctx)" to "ret" here, but that stored value is overwritten before it can be used. 1114 ret = vb2_update_menu(ctx); 1115 vb2_set_disabled_idx_mask(shared->flags); 1116 } else { 1117 vb2_update_selection(cparams, key); 1118 } 1119 vb2_draw_current_screen(ctx, cparams); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Updated Invitation: Crazy Review Sunday @ Monthly on the second Sunday (CEST) (coreboot@coreboot.org)
by zaolin.daisuki＠gmail.com 08 Sep '17

08 Sep '17

This event has been changed. Title: Crazy Review Sunday One time in the month we are doing review a whole day long in order to get changes merged into the tree. When: Monthly on the second Sunday Where: IRC Channel Calendar: coreboot(a)coreboot.org Who: * zaolin.daisuki(a)gmail.com - creator * coreboot(a)coreboot.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=aGpzZDhhaHI3amYycWs1d… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account coreboot(a)coreboot.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

Re: [coreboot] INT 13, real mode, block write commands and coreboot
by Taiidan＠gmx.com 08 Sep '17

08 Sep '17

AFAIK the more higher performance beagleboards such as the X15 have native pci-e devices for sata, esata, ethernet etc. I would suggest a more free device such as a BeagleBoard, the RPI foundation only likes open source when it is convenient with them (side question - how come so many laymen think it is an open source hardware?) If you get a RPI for a long term project you're eventually going to run in to issues when support ends and the blobs no longer work with new distros/kernels.

3 2

Re: [coreboot] KGPE-D16 PCI passthrough
by Taiidan＠gmx.com 08 Sep '17

08 Sep '17

On 09/08/2017 12:44 AM, Iru Cai wrote: > On Fri, Sep 8, 2017 at 11:42 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > >> On 09/07/2017 11:21 PM, Iru Cai wrote: >> >> Hi, >>> I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI to >>> USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed >>> video card and the LSI 1394a controller. I try to pass them all to a VM, >>> but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10. >>> >>> Does anyone with KGPE-D16 have this problem? >>> >>> Iru >>> >> You are attempting to pass the primary video device to a VM which hardly >> ever works, I tried the same thing and it didn't work (I wanted my PCI >> sound card in the VM, and as PCI doesn't support ACS and all the PCI >> devices on the D16 are behind the same bridge they are in the same IOMMU >> group so I had to do that - I ended up buying a USB sound adapter) >> > Now I'm using GTX 650 as my primary video device and not using the on board > ASpeed video card. > > Also I tried to pass the onboard USB controller to the VM, and also crashed > the kernel. Damn :[ FYI you forgot to reply all - please re post this to the list :] Hmm can I have dmesg logs and your libvirt or w/e VM config files? for the new config you are trying. I am playing games right now with my pass thru usb ports.

2 1

Re: [coreboot] KGPE-D16 PCI passthrough
by Taiidan＠gmx.com 08 Sep '17

08 Sep '17

On 09/07/2017 11:21 PM, Iru Cai wrote: > Hi, > > I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI to > USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed > video card and the LSI 1394a controller. I try to pass them all to a VM, > but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10. > > Does anyone with KGPE-D16 have this problem? > > Iru You are attempting to pass the primary video device to a VM which hardly ever works, I tried the same thing and it didn't work (I wanted my PCI sound card in the VM, and as PCI doesn't support ACS and all the PCI devices on the D16 are behind the same bridge they are in the same IOMMU group so I had to do that - I ended up buying a USB sound adapter) I would advise buying PCI-e cards for your needs (they will all be in separate IOMMU groups - the boards SR56xx chipset is great for passthru), the Aspeed video isn't worth using anyways as it is terribly slow and only supports low resolutions. I play games in a VM using one of the boards USB controllers (there are two, plus an extra one for the internal flash drive "Type A Female" usb port) you just have to get a USB header to attach to them and figure out which ports get assigned to what controller and as there are many headers you will have plenty of ports.

1 0

KGPE-D16 PCI passthrough
by Iru Cai 08 Sep '17

08 Sep '17

Hi, I have a problem about PCI passthrough on KGPE-D16. I plugged in a PCI to USB adapter to the PCI slot, and it's in IOMMU group 7 with the ASpeed video card and the LSI 1394a controller. I try to pass them all to a VM, but then kernel crashes. I tried in Linux 4.9.47 and Linux 4.12.10. Does anyone with KGPE-D16 have this problem? Iru -- Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/

1 0

Re: [coreboot] [kernel-hardening] ME and PSP
by Timothy Pearson 08 Sep '17

08 Sep '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/07/2017 01:24 PM, ron minnich wrote: > > > On Thu, Sep 7, 2017 at 11:03 AM Timothy Pearson > <tpearson(a)raptorengineering.com <mailto:tpearson@raptorengineering.com>> > wrote: > > could anyone shed some light on these decision making > processes? An open ISA and core design does not guarantee open silicon, > and in fact one could argue that it will mean any performance > improvements end up highly locked under NDA and similar to avoid > competitors coming online and ruining tens of millions of dollars of > investment for even one SoC improvement. > > > Exactly. The open ISA can go both ways: pushing toward "value adds" that > lock up a platform, instead of going the way we might hope, so vendors > have competitive advantage. Look at page 47 of "Volume II: RISC-V > Privileged Architectures V1.10" -- it basically allows a vendor to > recreate SMM as it exists today, creating regions of memory irrevocably > hidden from kernel. And there are certain things you can't access on > riscv without an M-mode trap, which means that you can't escape the need > for code in M mode. > > RISCV vendors can create SMM. We need to encourage creation of a world > in which they do not. But just claiming that "riscv is open so there > won't be anything proprietary" is being a bit unrealistic in my view. > > So what about Power? The problem I keep hearing is that power competes > in the server space with x86, and not well enough. It's one of too slow, > too power hungry, or too expensive right now to compete well. I am > hoping that Raptor is going to show us power done right :-) Appreciate the vote of confidence! :-) I don't think we have to worry about POWER's speed or TDP as of POWER9. The low-end 4-core chips (16 threads, comparable with low end AMD server chips) only have a 90W TDP which is significantly less than their AMD counterpart, and speeds at isoclock are projected to increase by 1.5x-2x per-core versus POWER8. Cost remains an issue but if we see more adoption overall costs will obviously come down. It really comes down to getting people to look at POWER as something other than the power-hungry beast POWER8 was, and that's proving somewhat challenging. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJZsZOVAAoJEK+E3vEXDOFbC9kH/iMNliilLPZxkYZOvPFmnrML Qa/Fqo4PO0m54pYTJqADqMtzzL3/udW55d+5SZG0+zL7Tol+75y77jXrtZDd7Nx0 f176QNNFb+eKHQXLQT1n55Hsp8LZ+vijBpUh5ZWZG525AGuRRLfYCtyMsupw8tD8 QZ3LvhL+XHeCOnXBvPs1YVX6odUEGotnZ+wlACcVWc5cJAj8k31zte/ZCjw0eOce TSaa1n4uWF+GgSGWAaI2qTFpnjv54QR9CDHwN1DRTSN3T92TJAB4+gjkLg2iwBJA d55senlGKGLj6A3ojfqiNkbNrX2lktm5JXpp5lspUtWPGf/k6/HCUs8JD6Mwzio= =UpiV -----END PGP SIGNATURE-----

3 2

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

2 1

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

07 Sep '17

ron minnich wrote: > I don't think we can assume that an open, unlicensed instruction set > guarantees open, unlicensed, blob-free CPUs and platforms. This is of course absolutely accurate. But a freely licensed ISA and implementation(s) thereof are *one step* in the right direction, and a significant one. RISC-V is not so much a guarantee of anything as it is a potential enabler of something. The fabulous thing about RISC-V is what makes ARM successful; there can and will be multiple different silicon vendors, offering products with many different features and tradeoffs. Some can be top performance but proprietary. Some can be transparent/open but slower. There is market for both. //Peter

4 3

Re: [coreboot] Moving the command line for Linux kernel payloads
by ron minnich 07 Sep '17

07 Sep '17

It's a great idea. On Thu, Sep 7, 2017 at 6:29 AM Patrick Georgi via coreboot < coreboot(a)coreboot.org> wrote: > 2017-09-07 0:09 GMT+02:00 Trammell Hudson <hudson(a)trmm.net>: > > Is there a current or historical reason for the ordering? > The reason for this order is that there had to be _some_ order. > So go ahead and push the change for review, it looks reasonable. > > > Thanks, > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
7
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