coreboot January 2018

coreboot@coreboot.org

60 participants
155 discussions

Disabling hyper-threading on Ivy Bridge
by Davíð Steinn Geirsson 13 Jan '18

13 Jan '18

Hi all, Can someone advise on how logical/physical processors are numbered for Ivy Bridge CPUs? I am hoping to build coreboot with hyper-threading (SMT) disabled. I guess this can be done by skipping over the right processor IDs in the for loop in intel_cores_init in src/cpu/intel/model_206ax/model_206ax_init.c:470 ? But do I skip over odd numbers? even numbers? Or are the extra threads at the end of the sequence? Best regards, Davíð

2 3

Re: [coreboot] HP Elitebook 8770w Suspend-to-RAM
by Robert Reeves 13 Jan '18

13 Jan '18

2 1

G505s gfx init (was Re: Microcode updates for slightly older intel CPU's re: meltdown/spectre)
by Nico Huber 12 Jan '18

12 Jan '18

On 12.01.2018 15:06, Mike Banon wrote: > Maybe I am very wrong here, but I just looked at this AtomBIOS disassembly > https://pastebin.com/raw/Q35JMU1b > and there are functions like "MemoryControllerInit / AdjustDisplayPll > / AdjustMemoryController ", as well as data blocks like LVDS_Info As I told you, I'm not interested in disassembly. > > Could you please tell if it at least appears to be somehow useful for > the OSS implementation? Yes, it is extremely useful. I can tell that without even looking at it. Reading another program is always helpful if you want to write your own code for something similar. The question is rather, is it 10% as helpful as proper documentation? maybe it is. 20%? 30%? *shrug* Please don't dig into disassembly. Please don't ask anybody to release their code. Ask for documentation. > > By the way, Damien Zammit wrote me that Alex (aka mrnuke) already did > 95% of open source VGA init for G505S hardware: > > https://www.coreboot.org/Board:hp/pavilion_m6_1035dx#Native_graphics_init > ( ARUBA is GPU family to which A10-5750M 's HD 8650G belongs) > > Wonder what are the remaining 5% ;-) Well, in about every software project the first 80% of an implementation take the first 20% of the time. I'd guess the remaining 5% are the har- dest part. And I'd only encourage somebody to look into it if it looks like the work is reusable on other systems. Nico

1 0

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
by Nico Huber 12 Jan '18

12 Jan '18

Hi, On 12.01.2018 10:51, Mike Banon wrote: > Hi Nico, > >> >> you seem to be misinformed about the G505s. There is no >> open-source gfx init for AMD (not in firmware, not in the OS), >> so within your requirements it's not usable as a laptop >> > > I've had a small discussion with bridgman from AMD (at Phoronix forums) > and he told me that VBIOS needed by G505S - aka "gfx init for AMD" - > - is "effectively open source" - a byte code which is possible to parse > with [AtomDis] open source interpreter well, the same holds for every program where an open-source emulator for its architecture exists. So thanks John Bridgman for open-sourcing the majority of programs in the world! lol... > > Only problem is that the last update of AtomDis was at 2011 - so, while it > should be able to parse 100% of G505S integrated / discrete GPUs AtomBIOSes > (because these GPUs were developed before 2011 if I am correct) > maybe AtomDis couldn't parse everything for the modern AMD GPUs I'm not interested in any disassembly. To my knowledge, there is no OSS implementation because it's not docu- mented what the AtomBIOS byte code does, i.e. how AMDs display engine works and is configured (I might be wrong, if so please tell me and I might start to write code for it soon). If that is true, it shows that there is no technically reason for keeping it under wraps but the de- cision not to document the hardware is pure political. Nico

2 1

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
by Peter Stuge 12 Jan '18

12 Jan '18

[799] via coreboot wrote: > Can't "we" build one or maybe two crowd founded secure Laptops (12", 15.x") The short answer to that is no, no we can't. The long answer is a discussion over beers or another prefered beverage. //Peter

3 2

Re: [coreboot] Recommended workflow with Chromebook support
by Julius Werner 12 Jan '18

12 Jan '18

We try to keep the Chromium tree very close to upstream these days (just a few days of delay at most). So usually you can just add the upstream repository as a remote and check it out in the coreboot directory of your Chromium OS SDK chroot, and then the Chromium OS ebuilds will happily build the upstream code for you. But working on Chromium and then rebasing onto upstream works too, since the trees are so close you usually get no conflicts. On Sun, Jan 7, 2018 at 5:29 AM, Matt DeVillier <matt.devillier(a)gmail.com> wrote: > > On Fri, Jan 5, 2018 at 6:19 PM, <tturne(a)codeaurora.org> wrote: > >> Folks, >> This question is directed at the Coreboot developers who target a >> Chromebook device. >> >> Do you tend to do bulk of development and testing within chromiumos >> coreboot tree or directly in coreboot.org tree? >> >> As we get going we are trying to decide if it makes more sense to work >> directly in chromium tree and then rebase our commits onto coreboot tree >> and test compile prior to submission upstream? >> Cheers, >> T.mike > > > > personally, I do all my work upstream, as I'm not building for ChromeOS. > If I were, I might use the device's Chromium branch instead, but it would > depend on the age of the device and how out of date its branch was. Older > devices were originally committed in the Chromium tree then upstreamed, but > it's the opposite for newer devices (APL/KBL and newer). > > I've also been working the past few years to upstream as many older > devices as possible, and to push my own fixes where appropriate. I think > all that's left now are Skylake/FSP 1.1 devices, at least on the Intel > side, and those are next on my list. > > -Matt > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
by Daniel Kulesz 11 Jan '18

11 Jan '18

Hi, afaik, Intel did not publish any info about the affectedness of the Core2Duo generation to date. I tried the Spectre-Demos for variant 1 on the X200 [1], and it seems unaffected while e.g. the Opterons on the KGPE-D16 are just as affected as all those Intel CPUs. Nevertheless, this should be fixable by OS updates only so nothing to worry about. It's only that ATM afaik only CentOS/RHEL ships updates for v1, as they have not been integrated into the Linux kernel yet. Regarding v3, there is not much to worry about either since it's also fixable by the KPTI-Kernel patch most distros should already have included by now (the one that is known to cause performance impact). The remaining and most important question is regarding v2, where the situation is unclear. And no, Qubes will not protect you from v2 because it allows the "isolated" stuff you run in your VM to escape this isolation and e.g. read the Host's memory - i.e. Dom0 in Qubes-speak. Regarding the 2nd and 3rd core-i-gen: Since Lenovo announced to release updates for the T530, and taking into account that some early "low-end" versions of the T530 had a 2nd-gen core-i CPU, there is (very) slight hope Intel will provide microcode updates for this generation. However, I haven't seen any other vendor than Lenovo making announcements about devices from these generations, so I have some doubt that Lenovo will provide updates at all. Regarding the impact: Not having fixes for v2 does not render the machine completely insecure, but you basically know for sure that you can't expect getting any secure isolation by running untrusted code in VMs. However, since the X200 has no IOMMU, I am not sure to which degree the level of isolation provided before was secure anyways. Cheers, Daniel [1] https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6

1 0

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre
by Ivan Ivanov 11 Jan '18

11 Jan '18

> If I compare the Lenovo X230 to Lenovo G505s this looks like a step back: the G505s is targeted at another audience that Lenovo ThinkPad Users. It looks to me like an entry level desktop, which is also very bulky (without the additional performance of a W540). > CPU comparison X230 CPU vs G505s > AMD_A6-Series_for_Notebooks_A6-5350M_vs_Intel_Core_i5_Mobile_i5-3360M_(BGA) > Also the G505s has less cores/no HT Sorry, but what are you comparing with? G505S is a laptop, not a desktop. and G505S laptop has been sold with different CPUs (which are removable), as well as at least three motherboard versions! ( only integrated GPU / integrated + HD 8570M discrete / integrated + R5 M230 discrete ) That A6-5350M cpu you have been comparing to - could be found at the very low end version of G505S, and this A6 is probably not even supported by coreboot Most (if not all) of G505S+coreboot owners here - have A10-5750M AMD CPU which is a powerful quad core CPU with functional virtualization, not 2 core weak A6-5350M So, this link should have been http://www.cpu-world.com/Compare/815/AMD_A10-Series_for_Notebooks_A10-5750M… Looks like the performance of A10-5750M (G505S cpu) and i5-3360M (X230 cpu) is almost the same, but now we should substract 5-30% or even more from i5-3360M benchmarks - because the Meltdown vulnerability, for which this horrible "5-30% or even more slowdown patch" is required ---> is Intel specific vulnerability ( cpu_insecure , as reported by Linux kernel ) And... "thanks" to Intel Meltdown, the results are suddenly very favorable for A10-5750M CPU, and for G505S in general Best regards, Ivan Ivanov 2018-01-11 8:34 GMT+03:00 [799] via coreboot <coreboot(a)coreboot.org>: > Hello, > > Off-topic: > Top-posted as Protonmail Android App is still unable to correctly use inline > answers without correct quote layout/line breaks. Bug has been reported > months ago :-/ > > Taiidan wrote: > > "(...) CPU's....without a fix there will > be only one coreboot compatible laptop with open source hardware > initiation that is remotely secure (...)" > > Currently I am using two laptops for my work setup: > A 12.5" Lenovo X230 and a 15.x" Lenovo W540 both machines are running with > Qubes OS 4rc3 and 16GB RAM. The W540 is a Dual-Boot system with Win10, the > x230 is running Coreboot. > > Honestly I am shocked and angry if there will be no Intel Updates for the > X230 and W540. > On the other hand, if I am running Qubes and Coreboot, wouldn't this reduce > the risk of Meltdown/Spectre attacks as Coreboot will protect me against > remote attacks (stripped down AMT/Intel ME) and Qubes might reduce the > attack surface as I am using several VMs and DVMs for browsing? > > If I compare the Lenovo X230 to Lenovo G505s this looks like a step back: > the G505s is targeted at another audience that Lenovo ThinkPad Users. It > looks to me like an entry level desktop, which is also very bulky (without > the additional performance of a W540). > > CPU comparison X230 CPU vs G505s > http://www.cpu-world.com/Compare/725/AMD_A6-Series_for_Notebooks_A6-5350M_v… > > Also the G505s has less cores/no HT > > Frustration. Can't "we" build one or maybe two crowd founded secure Laptops > (12", 15.x") with reasonable specs, good keyboard, hardware kill switches, > internal wan (kill-switchable)? > I can't think that choice is limited in 2018 to only 1 (in words "one") > laptop modell, which is no nearly 5 years old (08/2013). > > Brave new world. > > [799] > > > > > Gesendet von ProtonMail mobile > > > > -------- Original-Nachricht -------- > > An 11. Jan. 2018, 03:55, Taiidan(a)gmx.com schrieb: > > > I am curious of any intel insiders know if there will be microcode > updates released for older intel CPU's (ex: sandy/ivybridge) and failing > that, what can be done in regards to securing them from meltdown/spectre. > > I believe this is a relevant coreboot topic considering how many > coreboot boards have these and older CPU's....without a fix there will > be only one coreboot compatible laptop with open source hardware > initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD > CPU) and theoretically owner controllable (as the previous C2D/C2Q's > such as the X200 are now permanently insecure without intervention from > intel apparently) > > At this point even a massive performance loss is better than having to > throw out so much now-useless hardware. > > > -- > 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

Re: [coreboot] 16 GPUs on one board
by Aaron Durbin 11 Jan '18

11 Jan '18

On Sun, Jan 7, 2018 at 2:05 PM, Adam Talbot <ajtalbot1(a)gmail.com> wrote: > Lets take a slight differently tactic. What would happen if we removed the > ROM from a GPU/NIC? Would the GPU's still require 256MB~304MB of PCI_MMIO? > Yes, I would expect it to. Those cards have on-board memory that would need to be addressed. > > > > On Sat, Jan 6, 2018 at 3:00 PM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > >> I have had this issue in regards to SR-IOV, - at the moment coreboot only >> supports 32Bit MMIO unfortunately one can't have too many graphics devices >> or network interfaces apparently. >> >> Considering the success of the OpenBMC port fund it would be nice if we >> could get a fund going to fix this if it wouldn't cost too much as I would >> really like to be able to use SR-IOV and many more PCI-e devices on my >> board via a cyclone PCI-e expansion system eventually. >> >> I am not sure if there is a work-around in linux but post back if you >> find one. >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] HP Elitebook 8770w Suspend-to-RAM
by Iru Cai 11 Jan '18

11 Jan '18

Hi, Rob SeaBIOS 1.11.0 has some bug which can make S3 resume failed [1], you can try to use SeaBIOS 1.10.3: Payload Add a payload (SeaBIOS) ---> SeaBIOS version (git revision) ---> (rel-1.10.3) Insert a commit's SHA-1 or a branch name [1] https://mail.coreboot.org/pipermail/seabios/2017-December/011962.html Iru On Thu, Jan 11, 2018 at 8:57 PM, Robert Reeves <xiinc37(a)gmail.com> wrote: > Hi, > > I'm working on porting coreboot to the elitebook 8770w, with the goal > of submitting what I've come up with once I get it working the way it > should. Hardware wise it's very similar to the EB 8470p which I based > the port off of. Almost everything works right now, except for suspend > to RAM (and grub, but I'll figure that out later). It goes into > suspend fine, but on resume it simply restarts. I've never done this > before and I don't really know what I'm doing. I've attached a log > which includes serial output from both coreboot and debian over > several power/suspend/resume cycles with every debug option I could > think of turned on. I'm not sure what to look for, I see several error > messages, but I'm having a hard time telling which ones are serious > and which can be ignored. I would appreciate any help, and I would > like to gain enough experience to be a regular contributor to this > project. > > -Rob > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- My website: https://vimacs.lcpu.club Please do not send me Microsoft Office/Apple iWork documents. Send OpenDocument instead! http://fsf.org/campaigns/opendocument/

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
16
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 January 2018