[coreboot] Re: Shubhendra - GSoC proposal Inquiry about "Port payloads to RISC-V"

[taii...@gmx.com]

On 03/10/2019 01:19 AM, Shubhendra Singhal wrote:
> Dear Sir/Ma'am,
>
> I am Shubhendra Pal Singhal, currently third year in Computer Science at
> NIT Trichy, India. I wish to apply for Google Summer of Code. I looked into
> the profile of coreboot 4.9 and found out the project idea "*Port payloads
> to ARM, AArch64, MIPS or RISC-V*" to be very interesting.
>
> I have worked in the similar field on *RISCV architecture at IIT Madras
> where I helped in porting real time OS eChronos*, on RISCV architecture. I
> will be undergoing a *project in Embedded systems offered by USC Los
> Angeles in solving the SAT Solvers using OS and Digital Logic*.
> Furthermore, I am currently  working on a *long term project with under
> Prof. N.Ramasubramanium on the AI chip* where we are trying to solve the
> processing speeds by efficiently reducing the number of writes in the cache
> for faster access. I am also *undergoing Microcontrollers and
> Microprocessors* as my core subject in my current semester and have
> already* undergone
> OS, Real time Systems* in my B.Tech IV semester.
> I have included my further details in my Linkedin  : *
> https://www.linkedin.com/in/
> shubhendra-singhal-7378a9131/*
>
> I want to contribute to the open source community in the field of Operating
> Systems and this can prove to be an excellent platform for gaining
> experience in field of systems. This opportunity can pave my career,
> towards applied research in the field of Systems.
>
> *While browsing through the link, I saw the mailing list assigned for the
> project. It would be very useful if you could guide me as to what is
> expected in the project proposal and how can I serve the open source
> community in the best possible way. *Any guidance would be very useful and
> I hope to receive a reply soon. Thanking you for your time and
> consideration.
>
> Regards
> Shubhendra Pal Singhal
> National Institute Of Technology, Trichy, India
> Phone number : +91 9787888015
> Email-id : shubhendrapalsing...@gmail.com
> Linkedin :  
> https://www.linkedin.com/in/shubhendra-singhal-7378a9131/

Hi! This is really cool that you are from india :D I love that there are
developers and power users from all over the world here.

Welcome and especially as you are a skilled developer I hope you stick
around :3

Yeah porting the main payloads to RISC-V (also consider OpenPOWER) is a
great plan,
GRUB2 and SeaBIOS are the main ones - SeaBIOS is the default and most
people use that as it "just works" as a traditional "BIOS" firmware "F12"
loader where the user is presented with a screen and can pick various
such as booting from hdds, dvd drives, Option ROM etc.

I personally suggest that while you are skilled before you dive in neck
deep and start porting you should purchase an affordable coreboot device
and install it such as the KCMA-D8 which is a great owner controlled
open source firmware example of coreboot.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: IME: Alternatives for large companies?

[taii...@gmx.com]

On 03/28/2019 04:04 PM, Philipp Stanner wrote:
> Recently I had an interesting discussion with a system administrator
> who is responsible for several hundred PCs, Routers etc.
>
> His argument was: Imagine it would take you 15 minutes to install a
> patch on a computer (all windows machines of course...). If your
> company has 1000 computers and you send one admin to install the
> patches, it will take him >31 work days, working 8h a day.
> That's why, he said, companies are interested in software allowing them
> to install stuff on the OS / hard drive remotely through the firmware

What happened to WSUS etc? powershell scripting? remote desktop? WMI?
PXE/iSCSI boot to use Windows deployment services?

That is a poor excuse since no one has ever needed ME/PSP to remotely
install patches and I personally have never seen it used only the things
above.

>
> I, not dealing with large networks, had never thought about it this
> way. But it does make a lot of sense to me, it's about real money (as
> usual).
>
> So I guess that's indeed a huge reason why Intel and AMD created
> Frankenstein, running below UEFI and Kernel.

No its not.

ME/PSP are DRM.

BMC chips are not and have been around for a long time for exactly the
use you desire.

A big company can buy RaptorCS OpenPOWER Blackbird or TALOS 2
workstation motherboards and use OpenBMC which is much better, more
secure and one can always make updates rather than being stuck with an
old and exploitable proprietary firmware when the support cycle ends.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Locking coreboot against internal flashing

[taii...@gmx.com]

On 02/16/2019 07:31 AM, Frank Beuth wrote:
> On Thu, Feb 14, 2019 at 12:21:36PM -0500, Matt B wrote:
>> For Coreboot afaik the only two methods available are to flash with a
>> programmer or to flash internally from linux with iomem=relaxed.
> 
> On another mailing list, someone commented "I would never use Coreboot,
> because it would let malware flash your bios from within Linux."
> (paraphrased)

Those people are silly then, since a propriatary BIOS doesn't prevent
that either. They also think that if something isn't absolutely perfect
that one should not bother which is absurd.

The ones that prompt for BIOS passwords or w/e are just doing it to be
polite they have no software-enforced firmware update signing mechanisms
- now of course ones that do enforce it (but via hardware) always
include external flashes too making them not owner controlled and thus evil.

> 
> I'm reasonably sure that this is not true and security-conscious users
> can disable internal flashing, but I haven't been able to find any
> mention of such a setting in the documentation.

Isn't it possible to set the flash chip write lock bit on the flash chip
so things can't be flashed internally the same way intel blocks one from
re-writing the ME region internally?
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot doesn't POST on ASUS KCMA-D8

[taii...@gmx.com]

On 01/12/2019 03:48 AM, espionage...@posteo.net wrote:

Welcome to coreboot fine sir :D

> I have a KCMA-D8 motherboard with two Opteron 4226s,

(I assume you want to play games as you have a RX580)

You probably won't get decent gaming performance with these I would swap
them out for 4284's or 4240s I assume you want bulldozer cpus so you can
use libreboot ie: not needing microcode updates although I advise them
for spectre.

With 4284 (or the slightly faster but microcode updates mandatory 4386)
or what not and a RX580 8GB you should be able to max out new games
while gaming in a VM - let me know if you need help with that.

There are only a few games that are capable of using more than 8 cores
but the advantage of a second CPU is that you can do other stuff at the
same time without noticing as long as you use cpu pinning/isolcpus for
your vm gaming.

Another performance tweak is to combine half the modules of two CPU's to
obtain Turbo 2 performance on your gaming VM so with dual 4284's for
example you would get 3.7ghz rather than 3.3ghz or 3.7ghz on the first 4
cores and 3.3ghz on the last 4 cores in case you wish to do something
else on the second CPU while you are gaming.

For power consumption you should have nohz=on setting on your kernel
command line otherwise the modules will never enter CC6, pcie_aspm=force
is also another good one to have so is tweaking your CMOS settings for
power saving like enabling sata alpm and disabling 1394.

I also suggest obtaining:
FLR supporting SAS card as they are quite cheap right now on fleabay
either a $30 PIKE2008 to fit in the weird slot on the bottom or a $20
LSI SAS 9285 for the third PCI-e slot (On the D8 you can use the PIKE
slot or the third PCI-e slot but not both)
ASMB4 or ASMB5 module as they are hard to find, there is some on fleabay
for around $30 atm.

Btw have you heard of OpenPOWER? The raptor blackbird/talos 2? It is the
future of freedom computing now that new x86 is no longer free...gaming
is the the only reason to get a D8/D16 now that the blackbird is price
equivilant with much better performance.

>and 6x4GB (24GB) Hynix HMT151R7BFR4C-H9 RAM sticks. 

Maybe try cleaning the contacts if they look dirty? I had a ram training
issue due to dirty RAM contacts that didn't appear all the time and only
on coreboot not the propriatary bios for some reason but after cleaning
is ok.

> All my attempts of getting Coreboot to POST with this board so far haven't 
> worked. I'm compiling Coreboot from Git >(master branch), and can build it 
> without issue. > A pre-built Libreboot ROM (20160907) POSTs and boots fine.
> 
> For Coreboot's config, I've tried including/excluding CPU microcode updates, 
> along with some less important-sounding options. For hardware, I've tried 
> unplugging > >everything external (KB/mouse), my GPU (RX 580), and only had a 
> single RAM stick in (slot A1). I've also tried a single CPU being powered 
> (kept the 2nd CPU in but >only had a single 4-pin CPU going to the 1st CPU).

There is your issue or at least one of them - you need dual 8pin EPS
cables - one per CPU - like I said in the wiki not 4pin cables and not
adapters.

Anyway what does the console logs say? If you don't have one get a null
modem serial cable and hook it up to another PC to find out.

> 
> Can anyone else confirm Git builds of Coreboot booting on this board, or 
> provide any tips as to anything I could be missing?

It should I tested it a few months back although I use v4.6 on mine due
to some power consumption regressions in master.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Testing modernizing patches on ASUS KGPE-D16. (was Re: Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?)

[taii...@gmx.com]

On 12/18/2018 01:56 PM, Daniel Kulesz via coreboot wrote:
> Hi folks,
> 
> is there a branch that has all the outstanding KGPE-D16 changes merged? I 
> will be happy to test, but I feat I won't find the time to test all those 
> fixes each in a separate branch. Also some specification of what tests need 
> to be conducted would help.
> 
> The outstanding KGPE-D16 bugs on my personal list are boot failures that 
> require to turn off/on AC

I have the same issue :[ there is no real cause in the serial logs that
I can find I wondered if it was because the chips on the bottom of my
g34 cpu are damaged somewhat. I would really like to find out why.

I suggest to use the reset button instead so your hard drives don't have
to start/stop so much that is if your case has one you can connect the
header.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dell R610 Support

[taii...@gmx.com]

On 12/17/2018 10:43 PM, Ed Hau wrote:
> Thanks for all the great info once again! 

Yah thanks! tech support is my job on the coreboot ML to free up time
for the devs let me know if you need any more information or help.

What you need:
* Flashing device like USB CH341A (less than $10 from fleabay) this
board uses a SPI DIP8 chip make sure it is oriented properly or you
could damage it (there is a little reference graphic on the CH341A to
show you also take a decent photo of the board in case you forget what
direction to put it back in)

Porting:
Start with the KCMA-D8 board codebase, the differences is that the D12
has another PCI-e slot, different amounts of lanes per PCI-e slot, less
PCI slots and more RAM slots so you will need to change the PCI-e
configuration to get the board to boot and then add the RAM slots in the
board code it should be a very easy job probably only a few hours.

You can also play video games on the board too in a VM via IOMMU-GFX and
an attached graphics card if you get bored xD - the 4280s you got are
not as good as the 4386 but you should be able to play new games at
decent settings moreso if you use my suggested virt setup with RAM on
node 0 and cores 0,1,6,7,8,9,14,15 with all but core 15 in the isolcpus
kernel command line list along with nohz=on thus getting you 8 cores at
the Turbo 2 speeds of 3.5ghz and if the VM is configured properly there
is no latency issue from inter-node traffic.

Info:
The 42xx bulldozer CPU's appear to not require microcode updates but I
suggest applying them so you receive the spectre fixes whereas the 43xx
or any piledriver cpu absolutely requires microcode updates due to a
critical security exploit.

> Just wanted to follow up and
> say I put
> the order in and it's on the way now. I was unable to find the ASMB4 or
> 5 though

I see a listing for the ASMB5-iKVM on fleabay right now from the UK
$31.58+shipping.

> so ended up getting an ASMB6 for now that I'll look into adding OpenBMC
> support
Oh no D:

Like I said you have to get the ASMB4 or ASMB5 - the ASMB6 is much
different and won't work.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rowhammer mitigation: RH activation probability

[taii...@gmx.com]

Upon doing more research I am noting in regards to my previous post
about vendors who claimed to solve the problem by doubling the RAM
refresh rate in their firmware that according to [1] it only postpones
the problem rather than eliminating it.

[1]
https://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

On 12/14/2018 03:20 AM, Nico Huber wrote:> On 07.12.18 22:46,
taii...@gmx.com wrote:
>> rowhammer is almost entirely a laptop problem or for that matter
>> anything that uses SODIMM's due to their high density.
>
> That doesn't seem right. Can you give any examples of chips commonly
> used on SO-DIMMs that can't be found on DIMMs?

Ahhh good point commodity parts.

> I had the feeling you find the same chips on both. SO-DIMMs often host
16 chips. If you'd
> want the same capacity on a DIMM with less chip density, you'd need
> 32 chips (or physically bigger chips). Never seen that (though didn't
> look for it either).

I had read it somewhere awhile back when the problem first appeared
stating that it didn't appear as much in desktops and servers due to
lower density RAM which made sense to me considering the size difference
I also tested my various home computers and only my laptops had a
problem not the desktops/servers (all have ecc but it didn't show any
errors) so I figured that it was an accurate statement. This shows the
value of going back to quickly research something before providing the
statement (and having others who aren't me to review!)


On 12/14/2018 12:21 PM, ron minnich wrote:

> So, at first we have a non-specific ad-hominem attack:

I want people to get the best advice possible (hence my list of
alternative sources) and while I can cite examples I am prohibited from
potentially starting arguments about them so I do not want to.

To me providing good advice is important since someone reading it could
be facing a life or death situation such as a journalist in a hostile
country and why I always apologize and note a correction if I give wrong
advice. I am also a better sysadmin than I am a programmer so I
concentrate on my strong points.

> 
> On Fri, Dec 7, 2018 at 1:53 PM taii...@gmx.com  wrote:
>> I would like to note that company has provided poor security advice on a
>> variety of occasions
> 
> followed by poor security advice:
> 
>> rowhammer is almost entirely a laptop problem or for that matter
>> anything that uses SODIMM's due to their high density.
> 
> which is immediately disproven with a 3 term search on google:
> https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext
> 
> "The Google Project Zero team led the way in discovering practical
> Rowhammer attacks against client platforms. Google production machines
> use double refresh rate to reduce errors, and ECC RAM that detects and
> corrects Rowhammer-induced errors."
> 
> so, please all, no ad-hominem attacks, and if you're going to make a
> technical claim, please be ready to provide justification.

I had read it in a whitepaper somewhere and I am attempting to find out
where.

That is a good idea to have a citation on hand for claims like this and
I will do so from now on as if I were editing the wiki.

> 
> thanks
> 
> ron

If a post of mine is not acceptable then I encourage you or others to
exorcise your right to deny it as sometimes I do not realize what is and
what isn't considered okay.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16/KCMA-D8 Tip: Force sensor module load order to avoid the improper changing of hwmon paths which breaks fancontrol

[taii...@gmx.com]

On 12/11/2018 05:34 PM, Timothy Pearson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 12/10/2018 07:48 PM, taii...@gmx.com wrote:
>> Applicable to:
>> SP5100 AMD C32/G34 systems such as the KCMA-D8 and KGPE-D16.
>>
>> Situation: If you don't have OpenBMC installed you need to run
>> pwmconfig/fancontrol to manage fan speeds.
>>
>> Problem:
>> Normally the hwmon paths will change almost every boot resulting in the
>> need to run pwmconfig repeatedly or fix them manually in /etc/fancontrol
>> - this was driving me nuts so I searched for and found a solution.
>>
>> Solution:
>> Create a .conf file in /etc/modprobe.d/ to set sensor module load order
>> with these contents then reboot and fix the hwmon paths in your
>> /etc/fancontrol, reboot again and all should be well :D
>>
>> softdep fam15h_power pre: k10temp
>> softdep k10temp pre: jc42
>> softdep jc42 pre: w83795g
>> softdep w83795g pre: radeon
>>
> 
> We should probably create a board documentation tips/tricks section in
> GIT since the Wiki is no longer available.

Or create a website with a copy of the wiki.

> 
> Side note: I still wish there was an easier way to do this; I never
> bothered transferring documentation to GIT because of the added time /
> complexity vs. the Wiki WYSIWYG editor.

Ditto

I edited and made a variety of very helpful wiki pages but even after
the community voted to keep the wiki the powers that be got rid of it
just the same.

When I have some extra cash I am going to create my own coreboot wiki
website with a copy of the previous one since whomever is in charge no
longer wishes to host it and I am not willing to transfer everything
especially without an easy editor and ability to add images/charts
etc...the latest mediawiki version has a top notch WYSIWYG editor!

I feel as though not many people really care about nurturing the
non-developer power-user part of the coreboot community, it is choices
like getting rid of the easy to edit wiki that discourage potential
users by making things seem more difficult and out of principal I simply
refuse to give my "real" name (like there is any way for them to check)
to obtain a git account.

Despite what people say it was quite easy for me to obtain a wiki
account I just followed the instructions and got one a week later
(although you might have had something to do with that :3]

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dell R610 Support

[taii...@gmx.com]

On 12/12/2018 09:59 PM, Ed Hau wrote:
> Thanks for all the help so far after digging for the past day I was
> thinking about picking up the KCMR-D12 as you had recommended and a set of
> AMD OPTERON 4280 to go with it. This has the AST-2050 for the openBMC port
> that I am also interested in. Just wanted one more round of sanity checks
> before putting in the order.
> 

Yah go for it! it is almost identical to the KCMA-D8 it just has more
RAM slots and a different PCI-e configuration. Should be an easy first
port and one can gain experience :D Let us know if you need help!

Note OpenBMC needs an ASMB4 or ASMB5 firmware module (you use flashrom
to over-write the crappy exploit ridden OEM firmware) if the board
doesn't come with one they go for around $30 on fleabay.

After that if you wish to continue porting stuff I suggest a TYAN board
such as the dual northbridge/sas S8225, the quad socket/sas S8812 or the
affordable sas S8010 (just not the crappy SR5650 northbridge versions
that lack the proper amount of PCI-e slots)

best c32 cpu - 4386 or if you don't want to have to use microcode
updates the 4284 (4280 slightly slower/cheaper) I max out new new video
games in a VM via IOMMU-GFX of an RX580 8GB with my 4386 equivilant 6328
so you can use this as a libre gaming pc as well - there are a variety
of great AAA DRM free linux games on gog (email for reccs)

Something else that might interest you and what is a high priority
firmware wise is a FOSS Broadcom NIC firmware replacement for the nic
chipset that is on the blackbird/talos if you have what it takes the
first person to make one gets a free talos 2 workstation valued at five
thousand bucks. You can get PCI-e nics with the chipset so you don't
actually need one of the boards to develop for it. It would be great to
have a non-intel blob free nic since then one doesn't have to support a
competitor and further ME development by getting intel nics (thats why
they chose the broadcom one as it is the most promising due to a litany
of documentation) and it is the only thing in the way to getting RYF for
the OpenPOWER stuff afaik.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dell R610 Support

[taii...@gmx.com]

On 12/11/2018 04:29 AM, Nico Huber wrote:
> Hello Ed,
> 
>> I just started looking into adding support for the dell r610.
> 
> I really don't want to discourage you, but if I'm looking at the correct
> datasheet, this machine is using Nehalem/Westmere EP processors (e.g.
> Xeon X5550 etc.). If that is the case, this is no project suited for a
> coreboot beginner: It's unlikely that Intel would give out any useful
> documentation about these processors and there is no platform alike
> (i.e. with QPI) in coreboot. Reverse engineering is possible, but as a
> spare-time project this could take years.
> 
> Maybe you can find another system that fits your workloads and already
> has some coreboot chipset support. Though, on the Intel server front
> it's not looking very good. Intel fought hard to keep these platforms
> coreboot free.

Agreed - It is also an old platform without SLAT (hence no qubes) and it
has intels bad first gen IOMMU that doesn't have interrupt support.

IMO buy a KGPE-D16/KCMA-D8 if you want something to use as a daily
driver that doesn't cost too much money or effort and is a good example
of coreboot.

If you wish to port a board I would suggest to obtain another AMD fam15h
system of which I have some suggestions for - the easiest port is the
KCMR-D12 which is the KCMA-D8's E-ATX bigger brother. Otherwise I would
choose something still obtainable and well designed (ie: dual
northbridge so more pci-e slots and lanes) such as the TYAN socket C32
boards or the supermicro C32 LN4F/SAS boards which have onboard i350
quad port nic and a LSI SAS 2008 controller preferably a board with an
AST-2050 so that it could theoretically have OpenBMC ported to it.

x86 is a dead platform when it comes to freedom firmware though since
AMD stopped releasing everything along with taking AGESA closed source
and intel now only releases the fsp binary blob which performs all the
hardware initiation making coreboot not much more than a wrapper layer
for FSP.
OpenPOWER (from RaptorCS) and RISC-V (from SiFive) are the future since
open source firmware comes standard from the factory and they are the
only owner controlled archs now.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Removing a RAM slot retention lever on my KGPE-D16

[taii...@gmx.com]

My issue is that my dual slot graphics card obstructs one of the PCI-e
slots as it is too long to place in the first slot without colliding
with one of the RAM slot retention tabs and I was wondering if there is
a way to easily and without damaging anything remove the RAM lever tab
and thus make it possible to fit the card in the first slot.

I do not need RAM in those slots as I only have one CPU but at the same
time I don't want to damage them.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16/KCMA-D8 Tip: Force sensor module load order to avoid the improper changing of hwmon paths which breaks fancontrol

[taii...@gmx.com]

Applicable to:
SP5100 AMD C32/G34 systems such as the KCMA-D8 and KGPE-D16.

Situation: If you don't have OpenBMC installed you need to run
pwmconfig/fancontrol to manage fan speeds.

Problem:
Normally the hwmon paths will change almost every boot resulting in the
need to run pwmconfig repeatedly or fix them manually in /etc/fancontrol
- this was driving me nuts so I searched for and found a solution.

Solution:
Create a .conf file in /etc/modprobe.d/ to set sensor module load order
with these contents then reboot and fix the hwmon paths in your
/etc/fancontrol, reboot again and all should be well :D

softdep fam15h_power pre: k10temp
softdep k10temp pre: jc42
softdep jc42 pre: w83795g
softdep w83795g pre: radeon

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 non-working S3 suspend with Qubes 4

[taii...@gmx.com]

S3 - it does work but you just have to wait a long time I would guess
that maybe there is some ram re-training going on and that is why
resuming from S3 takes over a minute.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

On 12/07/2018 02:14 PM, petecb via coreboot wrote:
> 
> Hi Taiidan,
> 
> Thanks for your message.
> 
> 
>> I am using v4.6 on my system FYI (no reason for me to update) and the
>> only options I have changed are the ones I told you about before...all I
>> can figure is perhaps I have a different version of the SP5100 that
>> doesn't have the erratum or something to that effect.
> 
> Is it possible for me to build v4.6 in case something has changed since then 
> that causes my issues? When I look at the branches available on git there is 
> no 4.6 available.

Get it from the coreboot website + check signature.

> 
>>
>> FYI I saw you select build nvramcui as a secondary payload so you can
>> mess with cmos options without recompiling as long as next time you shut
>> off "Load default configuration values into CMOS on each boot"
>>
>> Since your menuconfig options look fine...shot in the dark but try using
>> grub instead of SeaBIOS as I use grub.
>>
> 
> I will try building it with Grub. There is an option to include a GRUB2 
> runtime config file into ROM image. Should I select this? If so, what options 
> should be in this file?

I would set it to load your disk .cfg file otherwise you would have to
do so via configfile (ahci0,msdos1)/grub2/grub.cfg or what not when it
boots to the rescue shell.

> 
> Kind regards,
> 
> Pete
> 
> 


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rowhammer mitigation: RH activation probability

[taii...@gmx.com]

On 12/07/2018 03:28 PM, emanuele wrote:
> Hello everyone,
> I know some system has support for a particular feature against
> Rowhammer attack.
> The "RH activation probability" settings allows to refresh a row with a
> tunable probability.
> 
> For example some AMI BIOS version include this option:
> https://forums.puri.sm/t/row-hammer/793/7

I would like to note that company has provided poor security advice on a
variety of occasions - if you want good advice I would ask people here
or on the gentoo ML since both seem to have a large amount of
experts...I also provide free advice for expert level technical
questions so you can email me as well.

> 
> I have found a trace in coreboot code here:
> https://github.com/siro20/coreboot/blob/master/src/vendorcode/intel/fsp/fsp2_0/cannonlake/FspmUpd.h

Do you mean this and its related options?

/** Offset 0x04AB - Enable RH Prevention
  Enables/Disable RH Prevention
  $EN_DIS
**/

/** Offset 0x04F7 - Row Hammer Solution
  Type of method used to prevent Row Hammer. Default is Hardware RHP
  0:Hardware RHP, 1:2x Refresh
**/

It appears the same as in the screenshot since AMI BIOS like coreboot
uses Intel FSP for hardware init (all new intel hardware uses fsp blobs
for hw init)

AFAIK there aren't any non development boards that use cannonlake and
since the hardware initiation is blobbed it would be hard to find out
how it works or test it to see if really does what it says unless we can
get someone from intel to comment here.

In my experience proprietary firmware frequently has options that aren't
actually implemented or don't do what they say they do.

> 
> Anyone know if this option is currently available on coreboot?


rowhammer is almost entirely a laptop problem or for that matter
anything that uses SODIMM's due to their high density.

The ivy/sandybridge hw init code like for x220/t420/w520 laptops etc had
its ram refresh rates doubled a few years back to fix the rowhammer
problem similarly to the second option in the bios screenshot you linked.

No idea about any other coreboot laptops and I am interested to know
about the AGESA series like the g505s (which have open cpu/ram hw init)

The expensive laptops with ECC are not really worth it since ECC doesn't
fix the issue...although one might be alerted from errors in the log and
could set the system to halt if any pop up preventing whatever the evil
program wants to do.

> Thank you all!

Yea hello and welcome :D

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

Maybe try installing a SATA drive to test things?

Worse case maybe disabling the SATA controller would fix it? as you say
you don't need it.

I hope timothy pearson sees this and replies as he would know what to do
to fix it.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

Please keep replies on the list - I will notice them - and like I said I
won't give up until it works :D

I wish you had OpenBMC installed so that I could access your system
remotely and try stuff myself (via VPN and a router IP whitelist for
security ofc)

Did your D16 come with an ASMB4 or ASMB5 module? if so I recommend
installing OpenBMC and its coreboot patches - note that coreboot needs
patching for them to play nice together since for some stupid reason the
required patches have not been upstreamed so you would need to cherry-pick.

I am using v4.6 on my system FYI (no reason for me to update) and the
only options I have changed are the ones I told you about before...all I
can figure is perhaps I have a different version of the SP5100 that
doesn't have the erratum or something to that effect.

FYI I saw you select build nvramcui as a secondary payload so you can
mess with cmos options without recompiling as long as next time you shut
off "Load default configuration values into CMOS on each boot"

Since your menuconfig options look fine...shot in the dark but try using
grub instead of SeaBIOS as I use grub.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

On 12/02/2018 05:30 PM, Nico Huber wrote:
> Hi Pete,
> 
> On 02.12.18 23:13, petecb via coreboot wrote:
>> As the default SATA setting already appeared correct, I modified the 3
>> additional settings that Taiidan had already indicated worked
>> (memory_speed_boost, 1394 controller and SATA ALPM) so in my mind I was
>> only adjusting one additional setting, the memory voltage. I thought
>> this was fairly sensible as my RAM is definitely 1.35V.
> 
> did you have CONFIG_USE_OPTION_TABLE before? If not you potentially have
> changed all settings. The defaults in the cmos.default file don't have
> to be the same defaults that are hardcoded in the code and the file only
> takes effect if CONFIG_USE_OPTION_TABLE is set. As I looked at the SATA
> code, I know the AHCI setting is one that definitely differs.

I would also use nvramcui to verify that settings have actually been
changed anyways.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

On 12/02/2018 10:43 AM, Angel Pons wrote:
> Hello,
> 
> On Sun, Dec 2, 2018 at 4:07 PM petecb via coreboot
>  wrote:
>> Thank you for all those details. I've now compiled a version with the 
>> default CMOS settings apart from the following changes
>>
>> Minimum memory voltage = 1.35v
>> experimental_memory_speed_boost enabled
>> 1394 controller disabled
>> SATA ALPM enabled.
> 

But what about the other one that you need? SATA AHCI mode? Of course I
also wouldn't start modding stuff before you get things working to start
though.

> Okay.
> 
>> Unfortunately, this results in the Qubes installation on the SSD crashing 
>> before it gets to the password prompt and the Qubes installer crashing 
>> shortly after booting. They both produce a similar error message that has 
>> been too quick to catch so far but mentions "PCI" and "IRQ".
> 
> One of the options you selected has the word "experimental" on its
> name. I would suspect it may cause issues.

Ah well the good thing is that it is easy to remedy if you have added
the nvramcui to your selected payload (it is a cmdline cmos settings
utility)

My money is on the memory voltage though since the experimental option
works for me (it is an optimization related to 63xx CPUs not actually
RAM itself)

> 
> Regards,
> 
> Angel Pons
> 


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

On 12/01/2018 11:56 AM, Nico Huber wrote:
> Hi Pete,
> 
> On 01.12.18 17:21, petecb via coreboot wrote:
>> I'm wondering if my problem is related to not having any SATA drives
>> installed? (I just have a PCI-E SSD). It may be the case that the logic
>> to disable combined mode is not getting triggered in my scenario, yet it
>> would do if there was a SATA drive present.
> 
> it's a configuration issue. If you have nvram settings enabled (CONFIG_
> USE_OPTION_TABLE), you can enable `sata_ahci_mode` with nvramtool.
> 

Ah so that is why it works for me but not for him, since I always
customize my CMOS options :D

> No idea why combined mode is the default, it's only useful for OSes from
> the '90s. It's not about the type of drives (SATA vs PATA) connected but
> how the SATA controller identifies itself to the OS.
AHCI is faster and better as it supports NCQ, TRIM etc.

Conga-rats petey now you can fix it easy! just enable cmos settings in
menuconfig then go to the kgpe-d16 coreboot board directory and change
cmos.default, recompile/flash then reset your CMOS - OR if you already
have use cmos enabled you can simply change it via the cmos tool with
the required iomem=relaxed in the kernel command line.

I would also lower the log/debug level via menuconfig to speed boot
times and maybe change some other things in cmos.default like me

I have
experimental_memory_speed_boost enabled, my 1394 controller set to
disabled and SATA ALPM to enabled.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16/KCMA-D8 "PIKE" LSI SAS 2308 addon cards are going for $22 on fleabay

[taii...@gmx.com]

Thought y'all should know.

This is what installs in the weird reversed pci-e x4 slot at the bottom
of the motherboard.

Notes:
* It will obstruct the usage of the PCI slot and the use of a dual slot
card in the bottom most PCI-e slot (the white one not the blue
"graphics" slots)

* KCMA-D8 has a SR5670 instead of the better with more PCI-e lanes
SR5690 on the D16 according to the manual using a PIKE will shut off one
of your PCI-e slots (lame!) although this is still a better deal than
buying a more expensive regular LSI card.

* They have working FLR so they can be assigned to VM's easily.

If anyone knows how to get SR-IOV working on LSI controllers me know -
the 2008/2308 controllers were the first ones that according to the
advertising literature were meant to have the ability to assign drives
to virtual functions and then those virtual functions to VM's meaning
you could have some drives attached to one VM and some to another and so
on - with the ability to have a SAS expander one could have native pass
through physical drives for every VM this way.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

Oops sorry forgot I also need "sudo xl dmesg" from dom0!

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

On 11/29/2018 12:33 PM, petecb wrote:

> 
> I followed these instructions and found that "ucode=scan" was already present.

But was it actually present in the grub.cfg you are using?
> I also noticed that it had "iommu=no-igfx" 

That is an intel thing
> so I changed this to "iommu=on" and rebooted. Unfortunately this did not 
> appear to have an effect and when I ran the "qubes-hcl-report" it still 
> indicated IOMMU was > not active :-(

Can you provide me dmesg and # lspci -vvv from your system either in
qubes or xen (does not matter what version)


>>> Have you successfully got a 6386 on this board running with Qubes and all 
>>> the microcode updates?
>>
>> Yeah I have with various 63xx CPU's.
>>
> 
> To clarify, have you been successful with Qubes 4?

Yes I have and I know other people who have done it as well.

> The rest of my systems are running this so I need to figure out a way to get 
> version 4 running securely on this system.
> 
> Do you have any other suggestions?
> If this is a Xen issue do you expect it to be a while before it is fixed and 
> merged in to Qubes?

Note you can always use new versions of xen with qubes by installing
yourself but I doubt that would do anything.

> If a 62xx CPU definitely works and doesn't have these problems, it may be 
> better for me to procure one of those so I can be up and running quicker.

IMO Keep what you have and find out what is wrong the 63xx CPU's are
much faster than 62xx.

> 
>>> I have attached a copy of my serial output booting the system with 2 sticks 
>>> of 16Gb ECC RAM (32Gb total) in case this is of any help.
>>
>> Put your RAM back in that would not effect anything :]
>>
> 
> I noticed it tended to take longer to boot with more RAM, so I took some out 
> whilst I was troubleshooting :-)

Yeah more RAM takes longer to train.

> Do you know if this system is likely to be more stable with a single CPU and 
> 128Gb RAM in all its slots or whether it would be better to have 2 CPUs and 
> split the 128Gb RAM between them (ie. all Orange slots populated)

Nah it doesn't matter you just can't have more than 192GB total without
potentially running in to issues.

Anyway don't worry I won't stop replying till all is well :D

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] GSOC submission

[taii...@gmx.com]

On 11/29/2018 09:02 AM, Arthur Heymans wrote:
> Hi
> 
> It has been a few years since coreboot (or flashrom) applied for Google
> Summer Of Code. In 2019 the applications for organizations open on
> january 2019 and student applications on March 25.
> 
> I think it would be great if the coreboot project could apply in 2019,
> as doing so has been very valuable for the project in the past.
> 
> I don't really know the full set of requirements and procedures, but I
> think it could be worthwhile to start thinking about project ideas.
> 
> A few ideas were already suggested on IRC on freenode #coreboot:
> - 64bit x86 ramstage (hard)
> - documented microcode update methods and write a tool that generates a
> webpage which microcodes are included in coreboot (easy)
> - nvidea optimus support (medium)
> - QEMU power9 support / initial openpower support (hard I guess?)

IMO not worth it since TALOS 2/Blackbird already have owner controlled
open source firmware directly from the factory so do various other
OpenPOWER machines.

> - Rework device resource allocation to support 64bit BAR (relatively
> hard)

Agreed this would be super great. I get plenty of failed to assign BAR
errors on my coreboot machines and my system doesn't work properly due
to not enough BAR space unless the PCI-e cards are inserted in a
specific order.

> 
> Any ideas or suggestions?

* SR-IOV/ARI support on the SR56xx AMD chipset code fam15h native init
coreboot so boards KGPE-D16/KCMA-D8.

According to the chipset documentation the chipsets support it and
various other advanced PCI-e features that aren't activated so it should
be easy but I can't figure out how to do it.

* Activating the IOMMU in coreboot on boards that support it.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

On 11/27/2018 12:12 PM, petecb via coreboot wrote:
> Hi,
> 
> Thanks for your reply.
> 
> I have built a version of coreboot with the “use binary only repo” and 
> “generate microcode updates from tree”. I presume by selecting “from tree” I 
> do not need to fill in the “Mircrocode binary path and filename”.

Yeah you don't since it is done automatically with both of those options
selected.

> The output of the make command to build the rom provides the following at the 
> end:
> 
> FMAP REGION: COREBOOT
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> fallback/romstage  0x80   stage  171020 none
> config 0x29d00raw   281 none
> revision   0x29e80raw   576 none
> cmos_layout.bin0x2a100cmos_layout  3524 none
> fallback/dsdt.aml  0x2af00raw  9895 none
> payload_config 0x2d600raw  1682 none
> payload_revision   0x2dd00raw   236 none
> microcode_amd_fam15h.bin   0x2de40microcode7876 none
> (empty)0x2fd80null   24 none
> s3nv   0x2fdc0raw 65536 none
> fallback/ramstage  0x3fe00stage   88643 none
> vgaroms/seavgabios.bin 0x55880raw 28160 none
> img/coreinfo   0x5c700simple elf  50606 none
> fallback/payload   0x68d00simple elf  68119 none
> img/memtest0x79780simple elf  47555 none
> microcode_amd.bin  0x85180microcode   12684 none

Looks to be there now.

Here from your serial log:

CBFS: 'Master Header Locator' located CBFS at [200:20)
CBFS: Locating 'microcode_amd.bin'
CBFS: Found @ offset 85180 size 318c
CBFS: 'Master Header Locator' located CBFS at [200:20)
CBFS: Locating 'microcode_amd_fam15h.bin'
CBFS: Found @ offset 2de40 size 1ec4
[microcode] patch id to apply = 0x06000852
[microcode] updated to patch id = 0x06000852 success

*852 is the latest version AFAIK so you are good.

> (empty)0x88380null  1537368 none
> bootblock  0x1ff900   bootblock1184 none
> 
> 
> From this it looks as though it is being built with the microcode. If I boot 
> into a Fedora Live CD dmesg does show me that the AMD microcode is being 
> applied.   > However I presume this is Fedora doing this because when I 
> boot into Qubes it does not detect IOMMU.

It looks like a xen issue.

> 
> Does this indicate an issue with how I have built coreboot?

No now it is fine.

It should be working hmm but next try the below solution.

> Is there a way to get Qubes to apply microcode updates in the same way Fedora 
> does?

Xen yes.
Edit /etc/default/grub (ex: sudo nano /etc/default/grub)
Add ucode=scan to GRUB_CMDLINE_XEN_DEFAULT inside the quotes
Then run
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

> 
> Have you successfully got a 6386 on this board running with Qubes and all the 
> microcode updates?

Yeah I have with various 63xx CPU's.

> 
> I have attached a copy of my serial output booting the system with 2 sticks 
> of 16Gb ECC RAM (32Gb total) in case this is of any help.

Put your RAM back in that would not effect anything :]

> 
> Many thanks for your help, it is much appreciated.

Hell yeah bro I love helping fellow freedom lovers.
I like to do the free tech support stuff the coreboot devs don't have
time for.

Did you check out the sexy new raptor blackbird btw? OpenPOWER is the
future of high performance computing freedom.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?

[taii...@gmx.com]

On 11/26/2018 09:15 AM, petecb via coreboot wrote:
> Hi,
> 
> I have an Asus KGPE-D16 motherboard I am trying to get working with Coreboot 
> and use with Qubes 4. It has a single AMD 6386 CPU and 128Gb DDR3 ECC RAM.
> 
> I have successfully cloned the git repository and built the coreboot.rom. 
> However when I flash it on to the board and then run the Qubes installer it 
> complains that there is an “Unsupported Hardware Error” and I get the text 
> "This hardware lack features requred by Qubes OS. Missing features: 
> IOMMU/VT-d/AMD-Vi , Interrupt Remapping”
> 
> If I install Fedora and run dmesg, AMD-Vi and the IOMMU all appear to be fine.

As it applies microcode updates.

> 
> I have tried flashing the board with an older version of Libreboot and can 
> confim this proceeds through the Qubes 4 installation without issue. However, 
> I wish to use a recent version of Coreboot for support of a Pci-E SSD and to 
> ensure I am running the latest microcode updates.
> 
> Can anyone offer me some guidance please?
> Is it possible I am not selecting the right options when I do “make nconfig” 
> before building the rom?
> 

63xx CPU's need a microcode update for working IOMMU and to fix a
critical security error thus you can't use libreboot.

I noted this on the wiki which is sadly now gone.

In the coreboot config enable "use binary only repo" and "generate
microcode update from tree" and then use the cbfstool and a livecd
(check dmesg) to verify it has been updated to the latest version that
includes the spectre protections as well as the IOMMU/NMI fixes.

Congrats on your libre purchase and let us know if you need help :D
I also suggest checking out the OpenPOWER9 Raptor Blackbird if you want
another owner controlled computer that is newer and faster.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Kontron 986LCD-M support

[taii...@gmx.com]

I run a RX580 without UEFI - note that only some vendors are silly and
fail to implement a dual VBIOS what is your cards OEM/model?


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Supported Motherboards

[taii...@gmx.com]

On 11/23/2018 10:28 AM, Felix Held wrote:
> I get the impressions that a few people are quite vocal on the mailing
> list about keeping stuff in the master branch that fell into disrepair
> and hinders the project in moving forward and improving things.
I can agree yes some stuff that clearly no longer works should be
removed from master but people were talking about for instance removing
the native fam15h boards KGPE-D16 and KCMA-D8 (last and best owner
controlled libre firmware x86 boards and arguably the best examples of
coreboot ports and hw init code) because they thought they didn't have a
working S3 mode without soliciting someone to test it until I reported
back that it still works (I use it all the time and tested it in master).

I feel as though at the current rate of people being too eager to remove
still functional boards for arbitrary reasons there won't be any easily
obtainable non development boards on master - another side issue is that
coreboot repos don't contain the libs required to compile the older
versions which are becoming increasingly unavailable with some only
downloadable from a single site hence I suggest the direct hosting of
them rather than requiring people to download from third party websites
that may or may not work in the future.

There needs to be some type of solution to this issue or in so many
years coreboot master will no longer be an open source firmware project
since it will only be able to initiate new x86 systems that happen to
require binary blobs.

I have never met a comp-sci/comp-engineering graduate or anyone in a
computer field who has heard of coreboot and that needs to change -
there needs to be some type of advertising so that there can be more
than a few wizards capable of the dark arts of firmware editing and who
have the time and resources to deal with arbitrary continued maintenance.

> but those few people seem to mostly complain, but don't either contribute
> patches to be merged in upstream master or hire people to fix things.

I have provided technical support to over 100 coreboot users and have
enticed many more to procure a supported board and start using it, I
also donate to projects and provide hardware to developers when I
can...the ways you say are not the only ways to contribute :D

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Schematics and PCB design for ASMB4 (Was: There are ASMB5's on fleabay right now for $30/ea (firmware storage module required for OpenBMC on the KGPE-D16/KCMA-D8))

[taii...@gmx.com]

On 11/03/2018 12:32 AM, Daniel Gröber wrote:
> Hi,
> 
> On Sat, Nov 03, 2018 at 12:10:25AM +0100, Angel Pons wrote:
>> Is it me, or is that thing a SPI flash chip on a PCB plus a few
>> transistors? It seems like copying the PCB design is rather doable, or am I
>> missing something?
> 
> Indeed, very doable, but tedious work ;)
> 
> Here you go:
> 
> https://github.com/DanielG/asmb4
> https://oshpark.com/shared_projects/jZLoDQ3Y
> 
> I had the schematics lying around on paper for a while now but I was
> too lazy to digitize them until now. The design is completely
> untested, I just ordered some boards though so we'll see.
> 
> FWIW if anyone is interrested in getting some assembled boards I might
> do a small production run.
> 

Holy crap awesome you are the best dude!

I asked about this awhile ago and I wish you had replied :D

I have boards without it so I would love to buy some if they are priced
lower than the official one - Do you have an estimate?

Might be a way for you to make a bit of extra cash as you could peddle
them to the various core/libreboot D8/D16 sellers plus leah/minifree,
the fsf, raptor (for integricloud x86) etc.

It is still quite important to have these boards as
propriatary-equivilant-functional for applications that don't yet run on
POWER (talos 2/blackbird) and this is a great step considering the D8
and many D16's even new don't come with that chip and they sell for IMO
too much on ebay. (my linky is $30 plus a silly $30 shipping for tiny
chip - so $60)

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Will a KCMA-D8 boot without the 8pin EPSV12 cable if you are using a 35W CPU?

[taii...@gmx.com]

On 10/19/2018 05:15 AM, Nico Huber wrote:
> On 10/18/18 3:16 PM, Angel Pons wrote:

Thanks for replying all!

>> I believe the power traces are different, so the CPU VRM feeds only through
>> the EPS12V connector. However, if your PicoPSU is large enough, I guess a
>> EPS12V cable can be attached to it.
> 
> Probably not for a 35W CPU

In comparison I have various other boards with higher wattage CPU's that
lack EPS connectors such as an AM1 for a 40W CPU...what is different? I
mean the 8pin one not the 4pin cpu cable.

> but generally: Using adapters for the
> EPS12V connector is dangerous. 

I know - I am the one who added that on the wiki :D but it is always
good to repeat it :D

> They have more than two pins for a
> simple reason: The electrical current through each pin/connection must
> not get too high. There are adapters that route the whole current
> through a single pin on the other end (e.g. a single old-school PATA
> drive connector).

Oh man that is bad

I wanted to either not connect a 8pin cable at all since a very similar
platform on the AM1 series doesn't need or come with one or use one of
my adapters that combines a 4PIN CPU cable and a molex cable which has
worked fine on my H8SCM with the same CPU before I got a new PSU for it
(H8SCM only $40 - I don't want to risk this $300 brand new KCMA-D8
although they are going for only $90 china used on fleabay atm)

> Never use these unless you know they can take the
> current you expect! (e.g. not much more than 3A for a 35W TDP, that
> might be ok for a single pin, but you should read each connectors
> specs)
> 
> Same applies to the tiny connectors for (hard)-drives on the PicoPSU,
> if the current goes through less pins on the PicoPSU side, don't do it
> (unless you know what you are doing).

I always check the ratings.

> 
> There are PicoPSUs that have a 4-pin EPS12V connector btw. 

I know I have one :D

But dont I still need 8 pins total?

> So I'm not
> sure what the original question was; would it work w/o full 8 pins? 

I just want to make it work with a normal CPU 4pin cable

> or
> would it work w/o any? The former likely yes, the latter likely no.
> 
> Nico
>

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Status Update of F2A85M

[taii...@gmx.com]

On 11/02/2018 12:06 PM, kinky_nekoboi wrote:
> Hi Mike, i hope i can help u i am just a User of coreboot and noo skilled 
> coreboot hacker yet lol.
> The A10-6800K should work as its the same CPU core/ gen.
> do not include microcode it makes the rom a brick mode.

FYI you NEED microcode if this is a piledriver CPU to fix the NMI>root
exploit and it is recommended if it is a bulldozer due to the spectre fixes.

Do updates work via the os or no?


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Supported Motherboards

[taii...@gmx.com]

If you want an owner controlled coreboot-libre firmware (coreboot isn't
always foss) available board get a kcma-d8, kgpe-d16, etc. or one of the
raptor computing systems OpenPOWER boards which have foss firmware (not
coreboot) from the factory, documentation and are owner controlled.

You can score a D16 new on fleabay for $150 ATM plus a 6328 cpu for $30
resulting in (with ram and a good amd gfx card) being able to play games
in a vm at max settings - there are a lot of good native linux and or
drm free games right now. It seems those new D16's sold there also have
the ASMB4 chip you need for OpenBMC.

the G34/C32 opterons are much faster than the G41's C2Q's and the
OpenPOWER9 stuff is much faster than intel/amd's proprietary blobbed x86
offerings of comparable price

I have wrote longer posts about that in the past so look 'em up :D and
welcome to the community.

I concur the g505s is a superior choice to a me'ed device as me can't be
disabled...unlike with workstations you can't have perfect with a laptop
right now here's hoping for a openpower laptop.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] There are ASMB5's on fleabay right now for $30/ea (firmware storage module required for OpenBMC on the KGPE-D16/KCMA-D8)

[taii...@gmx.com]

(This is the firmware storage module required to use OpenBMC on the
KGPE-D16/KCMA-D8 boards - with it at last one can have feature
equivalency with a proprietary system)

Great opportunity if you need but don't have one - they appear to be
brand new.

Raptor says either the ASMB4 or the ASMB5 will work.

While the facebook version of OpenBMC is stripped down (they used that
one for smaller firmware size afaik) and not as nice as the IBM OpenBMC
found on the various OpenPOWER machines it is still secure and much
nicer than the exploit filled default BMC firmware from ASUS.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Will a KCMA-D8 boot without the 8pin EPSV12 cable if you are using a 35W CPU?

[taii...@gmx.com]

I wish to use a picopsu with one which is why I am wondering.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] What determines PCI-e capabilities per chipset in coreboot? (ie: pcie register space)

[taii...@gmx.com]

What I want to do is fix the SR5690/SR56xx capabilities list to reflect
what is actually documented rather than what currently functions.

It is lacking ARI, ATS and a few other things although it has ACS I am
not sure exactly what enables it at the moment either coreboot or
quirked in linux.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 8GB graphics cards work on coreboot - in case anyone is wondering

[taii...@gmx.com]

On 09/30/2018 11:14 AM, Matt B wrote:
> Hi,
> 
> One thing I just noticed about the page:
> https://www.coreboot.org/Board:asus/kgpe-d16
> 

> Here "Crossfire XDMA" is listed as needing testing. 

I added that table.

> If nobody has been able
> to test this, and you (or someone else) has the opportunity this might be
> an interesting thing to test.

It is simply PCI-e P2P DMA nothing special so I see no reason why it
shouldn't work.

I don't have the money/need for a second RX580 so I can't test it.

If you want to play games the G34 6328 is what you want, or if you get a
KCMA-D8 the C32 4386 - the piledriver cpus are faster than the bulldozer
ones.


> After learning that this board can take a more modern CPU (family 15h) I'm
> now considering it more strongly for a future computer. My K10 box is
> *currently* mitigated against Spectre V2 (IBP disabled under CentOS via a
> chicken bit) but I don't think it's wise to expect further mitigations to
> be forthcoming from AMD should more bugs rear their ugly head. Moving up to
> a family 15h CPU means getting updated Spectre V2-mitigating microcode and
> a much more realistic expectation of support in the immediate future. I'll
> probably even move up to piledriver (like the G505s I'm currently working
> on), since a microcode patch will also fix the NMI issue (and I'll be
> applying one to the stock microcode anyway).
> 
> I'd be really interested to learn if Crossfire and other features of modern
> cards work on these older boards under coreboot, since they may come in
> REALLY handy when running any machine learning loads on these boards.

Like I said it works fine - you can have a total of 2 dual width cards
or 4 single width PCI-e cards plus the PIKE HBA/RAID slot which is
actually just a PCI-e x4 reversed slot on the data side (the longer side
is the ports fan-out)

Of course I would suggest you instead purchase a TALOS 2 as it would be
faster, less expensive and give you much more options. Obviously you
can't play x86 games on one but folks have already ported a few foss
indie games to POWER and unreal engine has a demo.

Note the lite version has only two pci-e slots and the recc'ed regular
talos 2 must have dual cpus for all the slots to be used so dual 4 core
is better than one 8 core.

Arguably the most impressive TALOS 2 home setup yet :D

https://wiki.raptorcs.com/wiki/User:JSharp#T2.2Fx86_FSC_Heterogeneous_Cluster_.28veritates.40kraftwerk.29

As always if you require more PCI-e slots on a single board for whatever
reason you can purchase a PCI-e expansion system from cyclone
microsystems, of course one should consider their uplink requirements
(and get at least pci-e 2.0 x16 uplink) although for P2P and VM
assignment the onboard PCI-e switch supports ACS so there is no issue
there. They appear on fleabay now and again and seem to be made in usa
just like the talos 2!

> On another note, does anyone have a favorite PSU for these boards?

I recommend something from seasonic they seem to make the best stuff
these days.

> Preferably something that will last a bit longer than crappy consumer gear?
> This thing already requires two 8-pin connectors for a dual CPU setup, and
> graphics cards demand them now too.

The PCI-e power connector is different and not compatible be careful
when you hook up your stuff!


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Downloading an archive of the coreboot wiki

[taii...@gmx.com]

On 09/15/2018 10:11 AM, Patrick Georgi wrote:
> Am Sa., 15. Sep. 2018 um 16:10 Uhr schrieb taii...@gmx.com > :
> 
>> Would this be the best way to do it? [...]
> 
> wget -r -k -np -p -l 0 http://coreboot.com/wiki
> 
> Maybe not. See https://www.coreboot.org/wikidump/ for more suitable formats.
> 
> 
> Patrick
> 

Thanks, but are those new? The date says june 2018.

And are they are all identical?


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KCMA-D8 /D16 and xen+bsd

[taii...@gmx.com]

I have a coreboot-libre D16 and it works fine with xen - no errors and I
haven't even embedded microcode in coreboot (req for my 43xx/63xx) I
instead do an early update from initramfs.

I suggest obtaining a null modem serial cable and a real serial pci-e
card or expresscard device (nothing involving usb) asap and set both
coreboot and linux to output their logs then you can post them here or
send them to me.

Of course since you have more than one d8/d16 I guess you just need the
cable? and can view the output of one on the other yes?

On 09/18/2018 12:24 PM, Jo wrote:
> 
> Cheers Guys,
> 
> im currently trying to migrate kmca-d8 servers from libreboot+ debian to
> coreboot+xen (ideally arch/centos/alpine as host, with openbsd /windows
> vms).
> 
> however, i do have a weird bug, resulting in an immediate shutdown /
> reboot into the payload after decrypting the main partition.
> 
> There are no error-outputs whatsoever, and i dont have a serial-to usb
> cable (yet), so i cant get any output from serial console.
> 
> Has anyone ever tried this setup/ get it to work?
> 
> Hardware:
> 
> Mobo: kcma-D8 , CPU: dual Opteron 4284, Ram: 16 or 32 gb KVR16E11/8 .
> 
> The problem is persistent/reproducible with different kcma-d8 and
> kgpe-d16, with any os+xen setup we tried so far, also with qubes os.
> 
> Since im using Qubes on various coreboot devices, it has to be something
> specific with those 2 boards.
> 
> Any hints would be greatly appreciated.
> 
> 
> Jo
> 
> 
> 
> 
> 


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Downloading an archive of the coreboot wiki

[taii...@gmx.com]

Would this be the best way to do it? I want to do it in a way that I can
host my own mediawiki server for me and my associates who consider it
better than the new documentation method (which AFAIK the community
voted against)

wget -r -k -np -p -l 0 http://coreboot.com/wiki

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[taii...@gmx.com]

On 09/11/2018 08:16 AM, Rudolf Marek wrote:
> Hi,
> 
> Sifive did great job [1] [2] and everything is now opensource including mask 
> rom loader.

Nice!

Truly a win for freedom hardware

Lets hope they next add an IOMMU.

> 
> "Today we’re finally able to rectify this issue by releasing the FU540-C000’s 
> ZSBL and FSBL as an open source project, which can be found on GitHub like 
> all of SiFive’s other open source projects."
> 
> And I guess someone could be interested in:
> 
> "A Challenge
> 
> Now that the bootloader code has been released it’s time for a little 
> challenge. Since the ZSBL lives in a mask ROM on the FU540-C000 there is no 
> way to replace it, but you can at least re-generate the contents of the ROM 
> and then verify that it matches the contents of a real HiFive Unleashed. 
> We’ve posted a copy of the contents of the mask ROM at 
> https://github.com/sifive/freedom-u540-c000-bootloader, the first person to 
> submit a pull request that can exactly reproduce that ROM will get a HiFive 
> Unleashed board!"

Sweet :D

I am trying that for sure!

https://github.com/sifive/freedom-u540-c000-bootloader/tree/challenge/u540-c000-release

Here is a linky to the actual mask rom for lazy people.
> 
> Thanks
> Rudolf
> 
> 
> [1] 
> https://www.sifive.com/blog/2018/09/06/an-open-source-release-of-the-freedom-u540-c000s-bootloader/
> [2] https://github.com/sifive/freedom-u540-c000-bootloader
> 
> 
> 



0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[taii...@gmx.com]

It looks like someone already pulled it off :[

https://github.com/sifive/freedom-u540-c000-bootloader/pull/6


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Microcode Updates PSA (New users please read)

[taii...@gmx.com]

I am making this due to seeing many mis-informed users that are engaging
in dangerous practices.

Microcode updates should ALWAYS be installed unless you are an expert
user and have repeatedly verified that your CPU doesn't require them and
you are prepared for the risks which include for instance on the
piledriver CPU's (opteron 63xx/43xx and the G505S's laptop cpus) a
userland to root exploit, a broken IOMMU and a timer issue that means
games and certain applications don't work properly.


Unfortunately x86 is stuck with non owner controlled undocumented
proprietary microcode updates and in the case of intel they are
encrypted for some reason - AFAIK only POWER has owner controlled microcode.

Despite this it is still a good idea to install them - I do on my
coreboot computers and thus I don't ruin my security for no good reason.


NOTE:
For microcode embedding in coreboot to work you must check both the
"generate microcode update from tree" option and the "use non-free blob
repo" option - doing the first but not the second will result in a
silent fail.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] 8GB graphics cards work on coreboot - in case anyone is wondering

[taii...@gmx.com]

I was worried that it wouldn't work for some reason like due to lack of
64bit MMIO in coreboot but I just installed an AMD Raden RX580 8GB on my
KGPE-D16 and it works great.

I am playing the latest games on max settings in a VM with a GPU
bottleneck at 1080p with my single 6328 CPU...it is nice to finally have
good smooth gameplay with high fps.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] T450S + Coreboot

[taii...@gmx.com]

On 08/30/2018 11:47 AM, Nico Huber wrote:

>> Actually it might be a good idea for Purism to at least consider the
>> switch to AMD Ryzen CPUs.

Absolutely not.

If anything they should leave x86 not simply waste money going to
another blobbed never-owner-controlled platform with a now unfriendly
vendor (such a shame AMD used to be really cool with coreboot) and
having to spend even more to create hardware initiation code etc.

Creating a POWER laptop is technically possible thanks to the low power
consumption of POWER9 - and tim said raptor will make one if sales of
the TALOS 2 are good.

The bottom line is that "jailbreaking" is rolling a boulder up a hill
that gets steeper at every rise you get to - you are supporting the
development of further anti-features if you buy new intel/amd hardware
no matter if you manage to make a hack to "free" it or not.

x86 is dead freedomwise - bottom line.

On 08/28/2018 01:50 PM, Th3Fanbus . wrote:
> Taiidan,
> 
>> I doubt those guys have the skill to do so but for those who do - you'd
>> spend tens of thousands in order to have a port for an old machine that
>> still is stuck with ME and hardware init done entirely by binary blobs.
> 
> It is not about the skill or money involved in the process, it is about the
> *possibility* of even running coreboot on said machine, which is most
> likely zer>>
>> I would save your money and instead buy an ivy/sandybridge thinkpad (can
>> nerf the ME - but not disable which is impossible)
> 
> AFAIK, you can still run me_cleaner on a Broadwell laptop. I don't think the
> ME is the main reason to get a XX20/XX30 Thinkpad over newer models.

Ivy/sandy = can nerf to BUP
post ivy/sandy = kernel still runs

I would argue there is a big difference there

> Mike,
> 
>> microcode - is optional
> 
> I assume you refer to microcode *updates*, not the microcode that is
> hard-coded inside the CPU. Still, I fail to understand why there is so much
> worry about microcode updates, as if they were going to open a backdoor
> of some sorts. To me, the only gain of not updating the microcode is in the
> number of bugs.

Mike as I said before too with piledriver cpus you need microcode
updates or you are very easily rooted via the NMI>root exploit.

> I do understand temporarily delaying the updates of known unstable
> microcode versions while awaiting for a fix, though.
> 
>> as far as I know its impossible to completely replace ME, only to trim
>> its' firmware as much as possible and hope for the best that it
>> doesn't have some undocumented "backdoor restore" mechanism that could
>> restore the original uncut blob under some conditions. Undoubtedly,
>> Intel ME is a backdoor, e.g. because it contains some antitheft
>> features which could be used to control your computer remotely: shut
>> it down, wipe or retrieve data from it, etc
> 
> This makes me feel I should recall what Nico told you earlier:
> "please don't spread FUD on this list."

It isn't exactly "FUD" to believe that there are undocumented ME
functions - lots of hardware has undocumented functions or problems that
were later patched out such as the many cisco router rooting functions
"accidently" left in again and again or the recent VIA C3 issue.

I agree that ME isn't really a "backdoor" since being a remote access is
its primary use but in this case a backdoor would be an undocumented
function that persists after one has set remote access to off or used me
cleaner.

I can't understand why some people here think it a conspiracy theory of
the fringe that there just might be an undocumented backdoor in every
computer something I imagine many organizations around the globe are
currently working on if they don't already have one.

After all ME/PSP was something that no one really asked for, IBM has a
supervisor processor with equivilant power (hehe power) however it is
open source and owner controlled no reason they couldn't have done that
here and have the hollywood DRM junk as an addon module so in a way
satisfying everyone.



0xDF372A17.asc
Description: application/pgp-keys


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] T450S + Coreboot

[taii...@gmx.com]

I agree that the G505S is a superior choice vs the ivy/sandy thinkpads
as it has no ME/PSP thus making it the newest and last owner controlled
x86 laptop but everyone be aware that it NEEDS a microcode update or you
are very easily rooted due to the piledriver+ NMI CPU exploit
additionally without the microcode the IOMMU won't work (and thus no qubes)

Most CPU's require microcode updates as there are critical errors in
manufacturing microcode.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] T450S + Coreboot

[taii...@gmx.com]

Pointless IMO.

I doubt those guys have the skill to do so but for those who do - you'd
spend tens of thousands in order to have a port for an old machine that
still is stuck with ME and hardware init done entirely by binary blobs.

I would save your money and instead buy an ivy/sandybridge thinkpad (can
nerf the ME - but not disable which is impossible) or a G505S (owner
controlled, no ME/PSP) and maybe also buy a KCMA-D8 (libre firmware, no
ME/PSP thus owner controlled and can play the latest games at max
settings in a VM with a good AMD graphics card) or TALOS 2 (open source
firmware, it is a brand new high performance OpenPOWER system, it is a
true special rarity) etc.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Reducing the boot time

[taii...@gmx.com]

On 08/11/2018 03:44 AM, Matt DeVillier wrote:
> or outputting the boot console to a non-existent serial port (which can slow 
> everything down).

Yeah ditto, and it could also be a high log level or other debug
features enabled that you don't need like the EHCI debug
console...probably a combination of things.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] POWER9 / Talos II coreboot support?

[taii...@gmx.com]

Tim you should post the latest power figures!

Many people think it uses lots of power when it doesn't.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] They're selling used KCMA-D8's for $100 on fleabay

[taii...@gmx.com]

On 07/21/2018 04:17 PM, Timothy Pearson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 07/19/2018 10:35 PM, taii...@gmx.com wrote:
>> (not affiliated with shady chinese seller, no idea how legit but if they
>> don't deliver a working board just complain to ebay)
>>
>> Great chance to get the last and best owner controlled x86 board for
>> your legacy applications - they appear to be selling them for cheap as
>> they don't know how easy it is to flash a BIOS that can run the
>> 42xx/43xx CPU's.
>>
> 
> Be careful here.  There is a hardware design flaw on older KCMA-D8
> boards that won't allow the 42xx/43xx CPUs to run; the only way to tell
> is by looking at the board serial and comparing against the tables in an
> ASUS errata document.

Oh damn :[ do the older d16 boards have the same issue? and do you know
where can I obtain this document?

Thanks for the headsup tim :D - you always got the info!

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Sun Ultra 40 M2 Board - Obscured coreboot status

[taii...@gmx.com]

Not to rain on your parade but currently I see this system going for
$400 on ebay or $130 for the board and am curious...what is compelling
for you and this? I did not know when I first started coreboot but you
can buy faster and newer open source firmware boards for less money -
stuff that you can do real work on.


I would definitely get a KCMA-D8 or KGPE-D16[1] if you want something
newer with open source firmware that works straight away but that's me.
If you are a programmer and want to tinker/port coreboot there are other
similar boards of the same class and era that would be a better fit too
such as the TYAN systems.

[1]The D8/D16 are fast enough to compile modern software and can play
modern games in a VM (via IOMMU-GFX) so you can use it for more than
just tinkering - they also support the facebook version of OpenBMC
(AFAIK there are two OpenBMC's versions the facebook and the IBM the
second has more features and comes on the TALOS system but both are
secure owner controlled remote access) via replacing the crappy vendor
firmware on the ASMB4/5 module (D16 comes with module D8 doesn't)
Both have working coreboot with no fiddling just compile and go same
features as the factory BIOS...and the D8 can be had used for less than
your U40.

I would also check out the TALOS 2; POWER is the future of high
performance freedom computing as there will probably never be another
owner controlled x86 system due to ME/PSP etc. It has open source
firmware out of the box (not coreboot) but again you should start with a
D8 or D16 and a decent compatible CPU.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] They're selling used KCMA-D8's for $100 on fleabay

[taii...@gmx.com]

(not affiliated with shady chinese seller, no idea how legit but if they
don't deliver a working board just complain to ebay)

Great chance to get the last and best owner controlled x86 board for
your legacy applications - they appear to be selling them for cheap as
they don't know how easy it is to flash a BIOS that can run the
42xx/43xx CPU's.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

Another regression I have noticed is that my 4th SATA hard drive doesn't
appear in linux for some reason, although it does appear in grub...ideas?

Also kyosti what logs and tests would you like? For now I have
re-flashed my old 4.6 coreboot but I will flash master again soon for you.

Tim - Yes I have CC6 enabled in my CMOS and my CMOS.default

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

Hi guys!

I have just tested my KGPE-D16's suspend a few times with the latest
master and it works fine - takes around a minute to get back to my linux
terminal.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

I will provide logs soon! what do you want exactly?

One apparent regression I have noticed is that "sensors" reports CPU
power usage at idle is now steady at 101W vs the usual 50W (which used
to be 40 before a kernel update) while I am not sure if it is accurate
as the cpu temp doesn't reach high levels expected for such wattage it
does have one bad effect in that Turbo 2 no longer works...and even
before this update with my v4.6 to get Turbo 1 on all cores as AMD
advertises I must use "tpc -psmax 1"[1] which brings up the sensors
reported TDP to 125W whereas normally it wouldn't work due to maxing out
at 115W and 3.35ghz rather than T1 3.5ghz the TDP determining when the
CPU enters full turbo 1.

I use Turbo 2 to obtain better performance on non-multithreaded games so
this is disappointing but I will investigate further.

[1] turionpowercontrol, an overclocking software

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/27/2018 05:17 PM, Timothy Pearson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 06/20/2018 03:39 PM, taii...@gmx.com wrote:
>> On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
>>> On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com  wrote:
>>>
>>>> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
>>>>> On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
>>>>> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
>>>>> within the latter period, I do not quite see how S3 support could have
>>>>> worked with that commit on kgpe-d16.  Or maybe this feature was never
>>>>> retested once it was rebased and upstreamed. Nor can I see how it
>>>>> could have worked for any commit in 4.6
>>>>
>>>> I just tested S3 again and it worked fine on my v4.6 D16.
>>>>
>>>
>>> Please state the commit hash of the source tree you built and booted from,
>>> we don't literally have such tag as "v4.6".
>>
>> I was using the coreboot-4.6.tar.xz from the coreboot download page
>> which is why I didn't include the hash.
>>
>> [0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS
>> 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
>>
>>>
>>> Repeat tests with current master.
>>
>> Thanks, I will have info for you by the end of the this weekend and I
>> will also investigate things myself if S3 doesn't work...
>>
> 
> 
> Just wanted to follow up on the bisect offer for thisI'm back in the
> D16 code for a different reason and if there's a general commit range
> where the issue started, I'm happy to investigate.

I got the flu so I had to put this off for a little while, I will start
next week.

Sorry! and thanks!

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[taii...@gmx.com]

On 06/24/2018 02:59 PM, ron minnich wrote:
> On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer 
> wrote:
> 
>>
>>
>> "While we’d love to provide you with this information, we believe we
>> cannot. However, we can’t prevent anyone from disassembling the fsbl and
>> copying the values sent to the blackbox DDR register map."
>>
>>
> 
> and ... there ends my interest in the hifive. A shame.
> 

I can't understand what their target audience is? who would buy such a
thing? who do they intend to sell these to? I mean the open source
people can buy the now very affordable Talos 2L and the cheap-soc people
can buy one of the many of ARM boards that litter the marketplace...I
don't get it.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RV: Error booting with TPM enabled.

[taii...@gmx.com]

On 06/23/2018 01:58 AM, Jorge Fernandez Monteagudo wrote:
> Hi Nico, thanks for the feedback!
> 
> 
>> I guess it's used, but you need an acpi name for all devices along the
>> path. "LIBR" is the name for the LPC device, there should also be one
>> for the PCI bus/domain. I would try `src/northbridge/amd/pi/00660F01/
>> northbridge.c`.
> 
> 
> Could you point me to an example to know what I have to look for, p.e, to a 
> good supported board or something related. I'm still introducing me in the 
> coreboot world :)

The KGPE-D16 and KCMA-D8 are I would say the best examples of coreboot
boards, they have the most features such as IOMMU-GFX and OpenBMC and
their code base is 100% open source/libre. They also of course support
TPM via a removable TPM header module.

The various sandybridge and ivybridge thinkpad T/X/W series laptops are
the most widely used coreboot devices that support TPM and can be
obtained for not much money if you want to have a working example.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] What happened to the Option ROM options?

[taii...@gmx.com]

On 06/21/2018 04:51 AM, Nico Huber wrote:
> On 21.06.2018 03:47, taii...@gmx.com wrote:
>> Ah oops overlooked this.
>> https://review.coreboot.org/#/c/coreboot/+/2531/
>>
>> Paging ron minnich! It seems at the end of the comments various people
>> note the mistake however it never got fixed.
> 
> There is no mistake here. The change was only a little ahead of its
> time. There was limited support for non-VGA option ROMs but that was
> not working well and SeaBIOS has better support for it. Since [1],
> coreboot only executes the option ROMs of VGA devices. The later
> changes you noticed only fix the Kconfig options to reflect that.
Ah thanks for the info.

But what about initializing non-integrated PCI-e graphics devices on a
board that has native graphics init (where the option doesn't appear)
and being able to choose the various YABEL options?

> 
> So if you need non-VGA option ROMs, consider using SeaBIOS.
> 
>> If this is a mistake I will require someone else to fix it as I am not
>> allowed to contribute on gerrit.
> 
> You are free to contribute. And if you had listened in the last discus-
> sion about our sign-off procedure, you would know that even you can do
> so without sacrifice.

Could you please provide a link for that? I always read all the replies
but I hadn't noticed anything about being able to sidestep the
requirement to use your "real" name.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] What happened to the Option ROM options?

[taii...@gmx.com]

Ah oops overlooked this.
https://review.coreboot.org/#/c/coreboot/+/2531/

Paging ron minnich! It seems at the end of the comments various people
note the mistake however it never got fixed.

If this is a mistake I will require someone else to fix it as I am not
allowed to contribute on gerrit.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[taii...@gmx.com]

https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1021175-risc-v-sifive-freedom-unleahsed-540-soc-hifive-unleashed-board-added-to-coreboot

The board costs almost as much as a significantly faster and with much
more features (IOMMU!) TALOS 2 Lite so I think it is not really worth
buying right now for someone like me but I am still very curious about it.

- Unlike the usual crappy SOC products like this there is an available
sexy expansion board which contains not one but two PCI-e slots and
various other expansion options including SATA...which all really should
have came standard. But unfortunately once you buy all the extras that
make it usable you could have bought a very nice T2 setup so this is
only for the die-hard hero developers and early adopters. (But I wish I
had the cash for both!)


My questions:

Is it possible to do normal stuff like browse the internet and watch a
film via video acceleration if you pop in a decent graphics card?

Are there absolutely no binary blobs? Not even for the NIC? It is
difficult to find NIC ASIC's that don't have blobs and with RISCV's
unfortunate lack of an IOMMU this is a very big security issue for
RISCV. At least with the TALOS 2 there is POWER-IOMMU to isolate it from
doing anything evil and various people are working on a libre
replacement which will benefit the entire libre community and anyone
that likes cheap+good nics.

Whats the deal with SMM? What a shame they thought to add it.


I really hope this succeeds and that they eventually add an IOMMU.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] What happened to the Option ROM options?

[taii...@gmx.com]

Using KGPE-D16 with master.

The choices for them have been messed around with in kconfig sometime ago:

In /src/device/kconfig
ON_DEVICE_ROM_LOAD has for some reason been changed to require VGA_ROM_RUN
which makes no sense to me (maybe someone could need option ROM's
without VGA option ROM's?)
and VGA_ROM_RUN is not available on boards with native (coreboot) init
irregardless so people don't see it even if they require Option ROM's
for whatever reason without SeaBIOS.

Does anyone know where the changelog for this is? and maybe can explain
what the reasoning is behind it? (if it is not a mistake)

Before...I believe last in v4.5 they were shown all the time.

I attempted to find the change in gerrit etc but I was unable to locate it.

Thanks!

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Thinkpad SD card controller DMA

[taii...@gmx.com]

On 06/20/2018 04:08 AM, Thomasheidler via coreboot wrote:
> Hello,
> 
> I noticed that all Lenovo Thinkpads supported by coreboot have a SD card 
> controller that is connected as a PCI device. I assume that the controller 
> runs non-free firmware from its own ROM and because it is a PCI device it 
> should have DMA, which seems like a security risk, right?
> 
> If so, is there a way to prevent the SD card controller from turning on when 
> the computer is booted, by changing some code in the source (maybe in 
> devicetree.cb) or at least to stop the controller from having DMA?


If you are using linux IOMMU will protect you after it is initialized (a
few seconds after main kernel init) even if you don't add the device to
a VM but before then you are SOL in terms of protection from a really
slick hardware rootkit like one found in a cheap PCI-e card...but I have
no idea if that thinkpad SD card PCI-e device has its own firmware.

I asked a question like this quite a long time ago and there was a
discussion on how to prevent this issue by not providing DMA access in
the coreboot phase which is much more simple vs having coreboot init the
IOMMU itself pre-linux.

Look at my thread:
[coreboot] DMA protection? [AMD-Vi]

AFAIK nothing has changed since then in terms of security improvements
but I would appreciate it if one of the coreboot expert squad can
respond to this.
Timothy Pearson from Raptor engineering was also willing to add DMA
protection to coreboot under contract.

I also suggest:
Disabling Option ROM execution or executing them with YABEL.
Looking in to the a libre EC replacement such as origami-ec and
replacing your EC firmware with a "clean" fresh one from a lenovo update
directly without using their update tool (which does a variety of things
to it such as adding your serial number) which can be done on various
models internally so you don't have to connect an external cable.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
> On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com  wrote:
> 
>> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
>>> On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
>>> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
>>> within the latter period, I do not quite see how S3 support could have
>>> worked with that commit on kgpe-d16.  Or maybe this feature was never
>>> retested once it was rebased and upstreamed. Nor can I see how it
>>> could have worked for any commit in 4.6
>>
>> I just tested S3 again and it worked fine on my v4.6 D16.
>>
> 
> Please state the commit hash of the source tree you built and booted from,
> we don't literally have such tag as "v4.6".

I was using the coreboot-4.6.tar.xz from the coreboot download page
which is why I didn't include the hash.

[0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS
4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017

> 
> Repeat tests with current master.

Thanks, I will have info for you by the end of the this weekend and I
will also investigate things myself if S3 doesn't work...

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
> On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
> Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
> within the latter period, I do not quite see how S3 support could have
> worked with that commit on kgpe-d16.  Or maybe this feature was never
> retested once it was rebased and upstreamed. Nor can I see how it
> could have worked for any commit in 4.6

I just tested S3 again and it worked fine on my v4.6 D16.

My Win10 guest with IOMMU-GFX also resumes properly as long as it is
suspended first before the host which places the assigned devices in S3.

It takes a LONG time (around a minute) to resume so it isn't quick but
it does work.

> so I must be missing something here. So I will need some logs.

Ah tell me what you want and I will provide it ASAP :D

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/14/2018 02:45 AM, Kyösti Mälkki wrote:
> On Thu, Jun 14, 2018 at 7:23 AM, taii...@gmx.com  wrote:
>> On 06/13/2018 04:12 PM, Kyösti Mälkki wrote:
>>> Hi
>>>
>>> Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards.
>> What exactly do you mean by wiped out?
>>
>>>
>>> Couple questions for board owners:
>>>
>>> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3
>>> support? I remember rumours they originally worked at some point, but
>>> regressed during the rebase / upstream process. Anyone willing to
>>> bisect/fix it if necessary?
>>>
>>
>> I have a D16 with v4.6 that I regularly use suspend with and it works
>> absolutely fine - I can also suspend a host featuring a guest with IOMMU
>> graphics and then resume that host later on and continue playing video
>> games on the guest.
> 
> So you are committed to bisect this and make it work on current
> master, thank you.

Yes I am, like I said this worked quite recently so I doubt it will be
that difficult to fix although I will have to have someone else publish
whatever I find. I own both of these and value them quite a bit so I
will be putting efforts in to this - In reference to my previous offer
to support the H8SCM I abandoned that effort as it went from $30 used to
over $200 and I didn't see the point after that (as one should just get
a KCMA-D8 or KGPE-D16 at that point)

The D8 and D16 are the last and best owner controlled x86 boards the
only coreboot boards left with 100% open source hardware initiation.

Like I have said before at this rate there will be no boards in master
besides *brand new* purism laptops and un-obtainable development boards
where half the features don't work anyway - I fail to see how that makes
for a healthy project if no one (again remember I have said you do quite
a bit already) is willing to support the two boards that I would argue
are the best examples of coreboot and modern computing freedom efforts.

>>
>> I again state my for-some-reason controversial opinion that at this rate
>> there will soon be no non-development boards in coreboot due to the
>> choices of the current leadership in determining standards.
> 
> I hear you and weigh your opinion according to the number of commits I
> can recognize you have authored on the repo.

I didn't mean it like that man - you have done quite a bit for computing
freedom and I have recognized that on various occasions.

As I am unwilling to provide my "real" name I am not allowed to
contribute code so I help in other ways - I have spent countless hours
assisting many many people with recommending boards to purchase and then
getting coreboot running on them.

Contributing code isn't the only measure of worth, every project needs
people to provide tech support and documentation and I do just that.

I do feel as though lately there has been a turn for elitism where
anyone who doesn't contribute code is discounted and made to feel
unwelcome as if our opinion doesn't really matter and I do not like
this...but again I say you are one of my favorites.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] wiki backup

[taii...@gmx.com]

On 06/14/2018 08:41 PM, Martin Roth wrote:
> On Thu, Jun 14, 2018 at 12:35 PM Leah Rowe  wrote:
>> On 14/06/18 19:01, Martin Roth wrote:
> 
>>> * The wiki requires a separate login from everything else, which
>>> has to be created manually.
>> Not only that, but it wasn't clear how to get an account in the first
>> place>
> I guess I didn't realize that it was a problem.  If you clicked 'log
> in' in the top of the wiki, it told you who to email along with their
> addresses.

Yeah it was quite clear to me how to get an account when I first wanted
to contribute and it only took a few days to get approved despite the
fact that I am certainly not a member of the coreboot elite xD

> "If you don't have an account and wish to contribute contact Stefan
> Reinauer or Patrick Georgi and tell them what exactly you want to
> contribute."
> https://web.archive.org/web/2015103952/http://www.coreboot.org:80/index.php?title=Special:UserLogin=Welcome+to+coreboot

I must say that Mr. georgi was quite welcoming in granting me an account
as a new user - and I have repaid that with a many helpful edits and
created pages.

>> By the way, what do you think of the idea I floated in a previous
>> message? My idea is to have some kind of web interface where a
>> non-technical user who doesn't know how to use git can browse the
>> documentation on the website and click "edit", which will take them to
>> the appropriate markdown file in the repository. When they're done,
>> they give their edit a title and description, which becomes the commit
>> message, and their contribution gets sent to code review (Gerrit).
>>
>> How feasible do you think this would be?
>> It would give some of the ease of use of MediaWiki as before, while
>> still having all of the advantages that you listed.
> 
> I have no issue with that if someone wanted to work on it.  It might
> still cause some difficulties because those people probably wouldn't
> be able to respond to requests for updates in gerrit

An email could be automatically sent to them for that, and then replying
to it could automatically create a reply on gerrit.

> and they
> wouldn't necessarily follow the rest of the rules we have for
> submitting to coreboot, but maybe those issues could be worked out.
> Maybe a documentation administrator could shepherd the patches the
> rest of the way through the process.>
> As far as feasibility, I'm sure it could be done, it would just take
> someone committed to making it happen.

This would be quite nice in terms of usability and I very much hope
someone makes it.

Also can someone answer: I presume that editing the wiki it requires my
"real" name as it is on git?

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] wiki backup

[taii...@gmx.com]

I do not like this...

I update the wiki on a regular basis for the boards I use and I can't
understand why another critical choice was made without input from the
community?

The new system has less features, doesn't look as good and does not
feature the current articles.

Policies like this make it very unfriendly to a new user and help ensure
that either only expert firmware developers will be able to install
coreboot themselves the average person will simply be forced to buy from
a company that sells coreboot systems (of course none of them sell
systems with real "free firmware")

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Native AMD fam10-15 support

[taii...@gmx.com]

On 06/13/2018 04:12 PM, Kyösti Mälkki wrote:
> Hi
> 
> Now that we wiped out K8, I'd like to put my eyes on fam10-15 boards.
What exactly do you mean by wiped out?

> 
> Couple questions for board owners:
> 
> First, about asus/kcma-d8 and asus/kgpe-d16: Do these have working S3
> support? I remember rumours they originally worked at some point, but
> regressed during the rebase / upstream process. Anyone willing to
> bisect/fix it if necessary?
> 

I have a D16 with v4.6 that I regularly use suspend with and it works
absolutely fine - I can also suspend a host featuring a guest with IOMMU
graphics and then resume that host later on and continue playing video
games on the guest.

> I am asking, because these are the last two remaining boards with
> combination of HAVE_ACPI_RESUME=y and RELOCATABLE_RAMSTAGE=n, and we
> have to drag along some back-and-forth memory copy code to keep OS
> memory intact for these two.
> 
> Second, I would like to move forwards with AMD fam10 to have
> RELOCATABE_RAMSTAGE=y, that would also solve above-mentioned issue and
> open up doors for some new features.
> 
> If it was my decision, RELOCATABLE_RAMSTAGE for x86 would be one
> criteria to survive the next (October 2018?) release. POSTCAR_STAGE
> for May 2019. I am probably too late to make such wishes, but I hope
> these will happen in the next two years nevertheless.

I again state my for-some-reason controversial opinion that at this rate
there will soon be no non-development boards in coreboot due to the
choices of the current leadership in determining standards.

Removing something from master is in fact removal from coreboot - one of
the reasons is as over time the older versions of software required to
compile older versions of coreboot will become un-obtainable already to
compile master critical old GPL code is only obtainable from one obscure
non-US site.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[taii...@gmx.com]

Forgot to say - a theory is that the issue may be that you lack enough
lanes in the slot you are using.
As ASUS was cheap they didn't add a second northbridge to obtain more
PCI-e lanes as was done with the TYAN boards so while the slots are x16
physical you can't run all of them at that all the time - I would
consult the manual to see which is which I believe the configurations
are either x16 x8 x8 x4 or x16 x16 x4 (both also can use the PIKE slot
which part of it is a reversed PCI-e slot connected to the southbridge
rather than the northbridge)

Using an x8 slot with bifurcation and 4 x4 M2 cards could mean that you
lack enough lanes to bifurcate all 4 - as an experiment I suggest
hooking up the card to an x16 configured slot and putting your GPU in
the x8 slot instead (you won't notice a difference)

As you are able to hook up two M2 cards it appears that bifurcation is
working as I don't see any information that indicates you having a
switched card.

I suggest emailing my directly via your other email account as I am
moderated on the coreboot ML so replies take a long time - also I don't
like emailing gmail addresses.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[taii...@gmx.com]

Did you get my email? can you provide a:
dmesg
# lspci -t -v
# lspci -vv

Thanks

Most quad adapters use PCI-e bifurcation not a PCI-e switch and AFAIK
not many boards support bifurcation so you would need a switched model
which you might have (I am not sure) if you do have a switched card I
would also contact the OEM as there shouldn't be any reason as to why it
doesn't work.

Not having PCI-e 3.0 wouldn't make a difference at all in terms of the
card working with all 4 cards and if the cards uplink is PCI-e 2.0 x8 or
x16 you won't notice a difference in speed.

VROC is an optional wintel gimmick addon that shouldn't be required for
it to work - if you could link a .pdf manual I will find out if it is
switched or bifurcated.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[taii...@gmx.com]

AMD has at long last coughed up the stuff to the linux-firmware people

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/diff/amd-ucode/microcode_amd_fam15h.bin?id=77101513943ef198e2050667c87abf19e6cbb1d8

The fam15h microcode update adds IBPB

  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES
    * CPU indicates IBPB capability:  YES  (IBPB_SUPPORT feature bit)

The question is what about the other stuff? IBRS, STIBP? This is
confusing due to zero documentation on these updates from amd...Why
don't they have those in this update? Would it be possible to easily add
the support flags without microcode for those who use libreboot?

Would it still be a good idea to add the lfence msr as rmarek mentioned?

As this is all above my pay-grade I would very much appreciate one of
the experts to chime in.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[taii...@gmx.com]

My lord yet another one.
https://www.phoronix.com/scan.php?page=news_item=Spectre-V3-V4-Vulnerabilities
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b78ce4a34b761c7fe13520de822984019ff1a8f
Now we also seem to need something called SSBD (Speculative Store Bypass
Disable) of which I can't find much information on, does anyone know if
fam15h will receive it? and if the microcode update 0x06000852 I have
posted is the latest one currently in the wild? It only has one of
mitigations whilst AMD's
"Architecture_Guidelines_Update_Indirect_Branch_Control.pdf" seems to
indicate that there are microcode with all three (and now 4) mitigations.

Where can one obtain the microcode with all 4 for fam15h?


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ThinkPad W530 support

[taii...@gmx.com]

I would also suggest testing IOMMU/HVM and if you can IOMMU for graphics.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SPI TPM question

[taii...@gmx.com]

On 05/15/2018 01:53 PM, Jorge Fernandez Monteagudo wrote:
> Hi all!
>
>
> This is my first message to the list.
Welcome sir! we are always pleased to see new users and companies using
coreboot - please feel free to ask any and all questions.

Coreboot will be a secure and affordable choice for what I presume is
your application.
if you wish to use coreboot in a production environment it might be a
good idea to inquire with your board vendor as to if you can save money
by purchasing "raw" boards without the usual AMI/Phoenix firmware/licenses.
> I would like to know if the TPM1.2 is supported through SPI?
>
> Enabling SPI_TPM and TPM in my board configuration throw an error. From 
> src/drivers/spi/tpm/Kconfig
If your company permits I would suggest posting the board model, .config
file, etc whenever you have an issue as the wiki advises - remember sure
to remove identifiers such as MAC address and serials.
> Any options to get TPM1.2 SPI support?
I would suggest emailing the people behind the HEADS project such as
Trammel Hudson - AFAIK they are the only ones currently doing major
coreboot related TPM work and would probably be willing to provide some
assistance...

https://trmm.net/About
and
https://github.com/osresearch/heads
https://github.com/osresearch/heads/issues/287 - interesting thread


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Why do we have FSP-S

[taii...@gmx.com]

Like I have said I believe the gradual encroachment of blobs and
corporate control will end up leaving coreboot dead in the water and
eventually even code not related to platform initiation will be blobbed,
coreboot will be an open source project only in theory not in reality -
the only boards that work with coreboot v8 or w/e will be unobtainable
development boards requiring not just blobs but an NDA and special
connections to obtain.

Lets say 10 years from now, will there be a coreboot? I doubt it - you
can't sustain a project like this without passion and people who believe
in freedom not fake "freedom" (ie: a certain company who entertains the
idea that x86 can still be free with some kind of magic)

Then again in a decade you probably won't even be able to run the
programs you want on a computer without approval and submission of a
scanned passport and CS masters degree let alone firmware - look on the
list today and you will see people who entertain the concept that
computing freedom is simply not "safe" for those not blessed and tell me
that isn't the future?

On 04/30/2018 11:11 PM, Zoran Stojsavljevic wrote:> >> OpenPOWER's
actually shipping open POWER9 systems right now >> with source code. Why
not go down that route?
Here here! - freedom today not tomorrow!

> > The only obstacle to this one is the price. If the price goes 2x
down, > it would be the perfect technical solution. :-) >If you assemble
your own TALOS 2 it costs less than a proprietary intel/AMD platform
with equivilant performance and features, and I consider this a miracle
- it isn't meant to compete price wise with a bargain basement x86 dell
"server" or what not.

The idea too is that you will have it for quite longer than a normal PC,
as it is very fast, high quality (assembled in usa!), and you will
continue receiving security updates for much longer than with most boards.
If someone is very broke they can always get one of the cheaper
coreboot-libre boards which still function and are easily available.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[taii...@gmx.com]

On 04/17/2018 03:30 AM, Rudolf Marek wrote:

> Hi,
>
> I found new microcode here [1], I used 
> cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin as a microcode for my Trinity 
> family15h CPU.
> I hacked together a new microcode header which contains the equivalence table 
> etc to be able to load this microcode into the CPU from Linux.
>
> dd if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin bs=1 count=84 
> of=header.bin
> cat header.bin cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin > 
> microcode_amd_fam15h.bin
>
> copy the file to same location and trigger update:
>
> echo 1 >  /sys/devices/system/cpu/microcode/reload
>
> [ 6032.948243] microcode: CPU0: new patch_level=0x0600111f
> [ 6032.964913] microcode: CPU2: new patch_level=0x0600111f
>
> Please note that the header.bin does contain a size of the microcode blob, 
> but it happens to be the same, so it works. Normally the container
> may contain more microcode blobs. But in my case I use just "right" one for 
> my CPU.
>
> The new microcode seems to be adding the IBPB feature.
>
> Thanks
> Rudolf
>
>
> [1] https://github.com/platomav/CPUMicrocodes
This didn't work on my piledriver CPU's :[

When I try to "reload" nothing happens not even an error in dmesgthe
reload command has never worked for me no matter what system I use intel
or amd.

Thanks for helping.
I can't believe everyone else is so nonchalant about all this
considering how important it is I still haven't figured out how to
update the microcode on any of my computers - no guides I have found
actually work and no distros have the new microcode for intel or amd
despite it having been months.

For the best security one should have both the new microcode and the
lfence msr?

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] asrock-B75-pro3-m

[taii...@gmx.com]

On 04/17/2018 06:11 PM, Nico Huber wrote:

> even if the board wasn't supported yet: Thanks to the complete open-
> source code for Sandy/Ivy Bridge and best coreboot code quality, it
> usually takes about 1 day for a lucky expert to port one of these
> boards. 1 or 2 weeks for an unlucky one.
Do you mean an expert as in someone who is a decent programmer without
coreboot experience (ex: type of person that asks if board X is
supported) or an expert as in someone like timothy pearson or kyosti
malkki firmware extraordinaires?
> It might not be your intention, but you are spreading a lot of FUD
> against coreboot.
It is what I was told by a few people, and what I saw here.
https://www.coreboot.org/Developer_Manual#How_to_support_a_new_board
"This can take from an hour of time to a few months based upon your
coding skills and hardware issues."
Maybe you should update that page?


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] asrock-B75-pro3-m

[taii...@gmx.com]

On 04/14/2018 06:45 PM, CarlosGonzalez via coreboot wrote:

> Hello: coreboot team
> I am look for help on coreboot install, I have issues to get work coreboot on 
> my side, so I have many questions to understand this field.
> 1) I have asrockB75Pro3m with !7 k serie. this will wok with coreboot?
The board no - I have no idea what chipset that is so you would have to
check yourself if it is supported.
If you want more information from me you need to do what the wiki
suggests and include dmesg, lspci -vv etc.
> 2) will coreboot work without ME intel?
Yeah you can use me cleaner to nerf (but not disable which is
impossible) ME.
> 3) When i use -E from flashrom this erase regions including ME intel?
The ME region is locked and must be modified with an external flash.
>  If yes can I put ME intel back using flashrom?
Yeah.
> 4) what command to use on flash coreboot in asrockB75Pro3m?
> 5) Is nesesary do layout to get coreboot work? if yes how I do a correct 
> layout?
The info is on the wiki, the layout is extracted from the OEM firmware.

You would be better off time and money wise by just buying a board that
already supports what you want - porting takes months for an expert
firmware programmer or tens of thousands to pay someone else to do it.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[taii...@gmx.com]

On 04/12/2018 11:43 AM, Peter Stuge wrote:
> taii...@gmx.com wrote:
>>> 3.  Support for Secure Boot - would one approach be simpler than another?
>> SB was invented by MS for DRM, it serves no real security purpose IMO
> I'd like to ask you to reconsider that opinion.
>
It is a fact not an opinion.

SB was invented for DRM - to prevent people from using linux or god
forbid doing something that hollywood doesn't like.
"embrace, extend, extinguish"

Good things don't have to be forced on people, but the SB 2.0 specs have
quietly left out the owner control mandate after the attention has died
down.
> Secure Boot is mandated by Microsoft to provide Microsoft and
> Microsoft's customers (OEMs) security, and I think it's pretty
> effective.
>
> But Secure Boot is also related to the security of individual computers
> and computer users, because it enables Microsoft and OEMs to establish
> a controllable, reliable and thus trustable chain of software from reset
> to desktop.
So microsoft should control the whole computing ecosystem? They are an
obsolete relic that should not be permitted to strangle the competition
in the crib.
> Most people who buy computers are happy, because controlling the computer
> isn't as important as using the desktop
Why can't they simply provide people a choice? (ie: flip this switch to
disable code signing enforcement)

Freedom is too dangerous? Hackers could turn their computer in to a bomb
without secure boot?
> which I think is fine.
>
I am surprised someone here would think that, moreso you of all people.

There will not be another future steve jobs or bill gates game changer
decades from now just more mark zuckerberg's only allowed to make
useless web apps.

Even wealthy families won't think to purchase their children a developer
computer by default and when a kid sees a "you are not allowed to
install this" message he/she will simply give up and go on to something
else like be a lawyer instead of a computer engineer; although even that
developer model won't allow someone true access they will only be
allowed to create surface level programs not low level programs,
kernels, or firmware.

I believe one day even you the expert will not be allowed to run the
code you please at least not without buying a very expensive "developer
edition" laptop.

People think that phones were always a walled garden but I am old enough
to remember when programs were installed on a palm treo similarly to the
win32 model where you download a file from a website and double click
without requiring permission to install something on *your phone*.

Let us hope the leaders of the future do not share your complacency or
we are truly done for.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[taii...@gmx.com]

On 04/12/2018 09:06 AM, Mike Banon wrote:

>> AMD kept their promise.
> Are you sure? I cannot find any download links except for the Windows 10.
> Yes, theoretically it should be possible to unpack those monstrous .cab files
> aimed for Win10 and extract a microcode hidden somewhere, but this is stupid.
> Do you have the download links for the standalone microcode updates?
Yeah its absolutely retarded but this is par for the course these days,
I unfortunately have no idea where to obtain them but they apparently do
exist.

The so called experts in charge these days think letting us peons own
and control our computer, and run and have access to whatever code we
please is simply too dangerous.
In this absurdly risk adverse society they don't want to have any tech
support requests because they released it to everyone and "help it
doesn't work".


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[taii...@gmx.com]

AMD kept their promise.
https://www.bleepingcomputer.com/news/hardware/amd-releases-spectre-v2-microcode-updates-for-cpus-going-back-to-2011/


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[taii...@gmx.com]

On 04/11/2018 09:54 PM, Raymond Yeung wrote:

> Thanks David for the detailed response.
>
>
> My main motivation to go down Coreboot/UBOOT route is to attempt to simplify 
> the remaining boot-up to Linux.  Instead of using PXE-BOOT, we could use tftp 
> only.  Am I correct to say that?
If you want to boot over the network you should look in to petietboot I
heard it is much better.
> If we're to use whatever that is available today, instead of waiting for 
> Philipp's work to complete, does coreboot/UBOOT provide secure boot support?  
> I'd tend to think so, but want to confirm.  UEFI seems to already have this 
> aspect covered.
Like I said I don't believe it is useful but if you want kernel code
signing enforcement you can use the grub payload that supports signing
for kernel/initramfs.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BIOS/CoreBoot/UBOOT

[taii...@gmx.com]

On 04/11/2018 06:39 PM, Raymond Yeung wrote:

> I currently have a board that uses Intel Xeon D (previously codenamed 
> Broadwell DE).  It boots up with BIOS/UEFI. I 'm exploring other oot-up 
> options here.
Let us know what you are attempting to accomplish.
> I'm not familiar with this early stage of system initialization.  It seems 
> BIOS/UEFI to Linux needs to use PXE
Hm? do you want to boot over the network? why would you need PXE just to
boot linux on your local machine?
I believe there is a neat petietboot coreboot payload with some network
booting features that is better than PXEthere is also iSCSI as an
option of course either a coreboot payload or part of a networking card.
>  with the need to configure DHCP (and possibly Proxy DHCP), TFTP server 
> PXELINUX, Linux initial RAM disk (initrd) configuration file, and then Linux. 
>  Previously, I'd been using Coreboot/UBOOT environment (as a user, not 
> developer).  Prerequisite seemed much simpler.
I am sorry I do not understand what you wish to do?
> A few questions -
>
>
>   1.  Is there even a coreboot support for this CPU already available and 
> stable that I could download and reflash?  Or are we talking about some 
> serious re-development?
The issue isn't support for the CPU it is support for your board, there
are a few broadwell boards in coreboot but they are only development
boards with no board status so I have no idea if the platform port even
works.

FYI the hardware initiation for the newer intel stuff is done entirely
by intels FSP binary blob in case you are wondering so there isn't
really much to change or poke around with.
>   2.  Is it possible to go from BIOS/UEFI to UBOOT (on-board)?  How?
Without coreboot no it isn't.
>   3.  Support for Secure Boot - would one approach be simpler than another?
SB was invented by MS for DRM, it serves no real security purpose IMO
and such a thing is better served by for example a grub payload with
kernel code signing enabled where you sign your own kernels.
"pointless? why?" Any hypothetical rootkit could simply infect some
other key system component that is always loaded and used every time the
computer is running.
"DRM?" SB 2.0 has removed the owner control mandate from MS leaving
OEM's free to not offer it, eventually only "developer" computers that
cost much more will let you install linux leaving the next generation of
computer programmer kids out in the cold and only able to create
programs for windows in a walled gardeneven wealthy families
probably wouldn't know to get their kid a special computer and most
would just give up when faced with a "you cant do that" error.
>   4.  Am I even on the right track thinking this way?
Ports for coreboot cost a lot of money (think 50K+) or if you have the
necessary firmware development skills 6months+ of time and effort
honestly I would just buy a board that already has what you want if you
want to play around with firmware programming - the entirely open source
being the very fast TALOS 2 (factory libre firmware but not coreboot)
and the not as fast KGPE-D16 (libre coreboot and OpenBMC ports are
available) unfortunately "coreboot" in general no longer means open
source firmware for most boards so be aware if you want to buy something
else.

Anyways welcome to the community :]


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs

[taii...@gmx.com]

But it would be possible to have two CPU's with the same core count but
differing frequencies?

Thanks


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot is going to make kcma-d8 obsolete

[taii...@gmx.com]

Thanks for everyone who has submitted status reports and now proved that
they work.

BTW the boards devices support ASPM so you can remove the pcie_aspm=off
in your kernel command line - I like to force it on myself with
pcie_aspm=force.

On 04/06/2018 09:54 PM, David Hendricks wrote:
> On Fri, Apr 6, 2018 at 3:40 PM, taii...@gmx.com <taii...@gmx.com> wrote:
>> Like I have said before these types of policies are eventually going to
>> result in coreboot only having unobtainable development boards in the
>> tree (that are of course not owner controlled)
>>
>> It simply isn't right.
> Indeed, this isn't right (as in correct) so don't spread this FUD. The
> boards are still in the tree, you just need to check out whatever coreboot
> version is known to actually work with the board. For example if a board
> was last reported working in coreboot-4.6, then `git checkout 4.6` or
> checkout a specific hash reported on the board_status repo.
I swear I heard "removed from the tree" somewhere - irregardless only
unobtainable closed-source development boards will benefit from new
coreboot features.

Eventually the old versions of coreboot will become non-functional for
whatever reason so it won't be that simple (ie: don't checkout master)
if one doesn't require the new features - already for example there are
various old libs that coreboot requires which are only available
*unsigned* from a single site.
> It does no good for users to have hundreds of boards in master that fail to
> boot, and no good for developers who need to maintain and refactor code for
> boards that nobody tests and have been abandoned.
I am not complaining because some random boards from 2005 that no one
uses are being removed - this is because the last owner controlled
x86_64 boards will eventually be functionally removed (and would have
been if no one had submitted status for the D8).

This isn't hundreds of boards that fail to boot - it is a few boards
that do boot - and people know that they do (as everyone can see now
that status have been submitted :D)

As an example I don't mind the removal of the H8SCM because AGESA
doesn't support IOMMU and the boards are now quite expensive (and not
worth it for the money).
> There's obviously a few people on this list using the Asus boards mentioned
> which is great. The issue we need to solve is getting more people to submit
> test results so that this isn't a problem in the future.
Even if I didn't use mine for something important I am unable to submit
results because I refuse to provide my "real" name and am too honest to
use a fake name.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot is going to make kcma-d8 obsolete

[taii...@gmx.com]

On 04/06/2018 09:06 PM, ron minnich wrote:

> On Fri, Apr 6, 2018 at 5:45 PM Thierry Laurion  
> wrote:
>
>> I agree. This is wrong.
>> Kgpe-d16 and alike are the last resorts for x86 blob free hardware.
>>
>> This NEEDS to be kept maintained and upstreamed.
> I like the board too. I have one. I have no time to keep it going. I have
> not even turned it on in months.
>
> Now that I think about it, my board has an EM100. I can try to automate the
> mess if I can remember where the directions are. I also need to work out
> remote reset :-) -- any hints on what to buy to make that go?
>
> Realistically, though, if you want blob free, I think you need power9 or
> riscv.
Of course, but the D16/D8 are fine for legacy x86 applications that some
people need to run and they are both blob free, the last x86 boards that
are.
> I've written x86 off for blob free. I'm sad about that, given where
> we were in 2000 and where we are today, but there's not much to be done for
> it. AMD and Intel just don't see this as a priority :-(
Yeah x86 is dead freedomwise but that doesn't mean boards that people
know are functional should be removed from coreboot just because.

I highly doubt these policies happen in a vacuum.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot is going to make kcma-d8 obsolete

[taii...@gmx.com]

Like I have said before these types of policies are eventually going to
result in coreboot only having unobtainable development boards in the
tree (that are of course not owner controlled)

It simply isn't right.

How can one learn firmware programming when all the available boards
have hardware initiated via binary blobs? This is what the standards create.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Looking for a volunteer to add Fam15h spectre MSR to coreboot

[taii...@gmx.com]

As I am not a programmer I do not know how to do this (thanks for the
heads-up rmarek) nor am I permitted to add to the repos.

MITIGATION G-2                                       
Description: Set an MSR in the processor so that LFENCE is a dispatch
serializing instruction and then
use LFENCE in code streams to serialize dispatch (LFENCE is faster than
RDTSCP which is also dispatch
serializing).

This mode of LFENCE may be enabled by setting MSR C001_1029[1]=1.

This is important and covers a variety of boards such as the KGPE-D16,
KCMA-D8 and G505s (all the last and best owner controlled x86_64 systems)



0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] [URGENT] - The KCMA-D8 is going to be removed from coreboot unless people cough up a board status update

[taii...@gmx.com]

This is a great board that many use and it DOES work - it needs a status
update ASAP to prevent it from being removed in the next release.

I am unable to do this myself as I use mine for an important router.

At the rate things are going soon there will be no non-development
boards that are still in the repos due to the arbitrary increasing of
standards.



0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[taii...@gmx.com]

On 02/18/2018 07:03 AM, Rudolf Marek wrote:
> Hi,
Thanks for the detailed reply :]
> What do you want to protect?
I just looked at the AMD page saw they said they would be releasing
updates and I figured I should have them even though there is no
description of as to what they actually will do.
>  If you want to protect the kernel, retpolines are OK on AMD.
> And you don't need any microcode update. Your CPU needs to have SMEP, 
> otherwise
> you would need to clear RSB on CPL change (the paper on mentined page says 
> that you need to do that
> always, but at least on Ryzen, the attack using RSB is not working (we tried 
> that out, maybe it works
> only on some circumstances).
>
> If you want to protect userspace, the RSB will be clear by IBPB (which you 
> would need if you don't have userspace compiled
> with retpolines). I don't know if intel clears RSB on IBPB... probably not
>
> To sum it up on AMD:
>
> kernel:
> retpolines, RSB clear on CPL change on CPU without SMEP (see above)
>
> userspace:
> retpolines, RSB clear on context switch necessary or IBPB (needs microcode 
> update).
>
> Plus make sure you enable "LFENCE is dispatch serializing" - perhaps coreboot 
> can do that :) it is simple
> MSR write on fam 10h 12h+ the fam 11h and 0fh dont have this MSR but LFENCE 
> is dispatch serilizing.
Hmm do you have more info links about this?
> Besides that, you don't need any microcode update.
>
> Plus of course there is a spectre variant 1, which is more difficult to 
> mitigate, basically you need to check all the software
> and look for any pattern like array_x[array_z[untrusted_index] * any 
> transformation].
>
> The first access would leak just address (ASLR defated), second will leak 
> data.
> The variant 1 works on user/user attack and as well as user/kernel.
>
> As far I know there are no automated tools to check for this.


0xDF372A17.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Server systems shipped with coreboot

[taii...@gmx.com]

On 03/24/2018 09:21 AM, Alberto Bursi wrote:

> I was writing within context of this mail thread.
>
> This mail "thread" is about Coreboot on server systems, and no major 
> manufacturer I know of, apart from IBM and the board from Raptor 
> Engineering ever used Coreboot on server systems, so yeah, on server 
> boards it is nearly always retrofitted by the end user or some third 
> party that resells it.
They haven't sold boards with it and I am not entirely sure if it was an
official effort but people from Supermicro and AMD worked on the
coreboot ports for the H8SCM and maybe a couple other devices.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Server systems shipped with coreboot

[taii...@gmx.com]

On 03/25/2018 11:12 AM, thierry.laur...@gmail.com wrote:

> For the KGPE-D16, an integration effort was made in Heads to support
> such board.
>
> https://github.com/osresearch/heads/issues/134
>
>   * OpenBMC support merged into coreboot so the server can boot
>   * Flashrom support to flash OpenBMC directly from within Heads
>   * Flashrom support to reflash Heads internally
>   * Multiboot support, QubesOS support
>
> Thanks Timothy for all the great work that was accomplished on that
> board in the past years.
>
>
> TPM2 integration is still missing though. Don't hesitate to collaborate
> onto  heads to integrate VBOOT changes. 16Mb of SPI flash is more then
> enough to support it.
>
> Talos II cannot actually fulfill most of the threat models that the
> KGPE-D16 can with Heads + QubesOS combined.
The TALOS 2 has libre firmware, POWER-KVM, POWER-IOMMU and *it isn't a
dead platform* - it is definitely worth a purchase.
There isn't a POWER-qubes or a POWER-heads because no one has POWER
computers and because there aren't those and "you can just get a *some
x86 machine*" then not many will buy one and it will be the end of
freedom computing...

The facts are that x86_64 is a dead platform and there will never again
be another owner controlled x86_64 device. - people need to understand
that and realize that things like qubes for POWER is a catch-22
situation that will never be solved unless people have POWER machines
and use them for their other virtualization needs until then.

Btw whats better about TPM2 vs TPM1? (Is there anything useful? AFAIK
the only difference is the addition of more microsoft sponsored
non-owner controlled features that could be potentially used for DRM)
I always thought a useful TPM feature to prevent it from being used for
DRM is to have a fuse one can set to enable a "secure" mode otherwise
one is able to freely read back anything on the chip.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Server systems shipped with coreboot

[taii...@gmx.com]

On 03/23/2018 06:33 PM, Alberto Bursi wrote:

> Yeah, getting an RMA isn't hard if you just lie. Won't work for non-RMA 
> support requests though.
It isn't lying if OEM never stated pre-purchase that you aren't allowed
to flash your own firmware.
It is the same as how many laptop OEM's want you to have windows
installed when you RMA a laptop.

This type of issue was actually debated quite a bit back in the 70's
(and now recently again) when car manufacturers tried to prevent people
from using after-market parts or tuning their vehicle.
https://en.wikipedia.org/wiki/Magnuson%E2%80%93Moss_Warranty_Act
https://www.sema.org/sema-enews/2011/01/ftc-validates-right-to-install-aftermarket-parts
http://www.dummies.com/home-garden/car-repair/keeping-your-mods-warranty-intact/
"Further, under the act, aftermarket equipment that improves performance
does not automatically void a vehicle manufacturer’s original warranty,
unless the warranty clearly states the addition of aftermarket equipment
automatically voids your vehicle’s warranty, or if it can be proven that
the aftermarket device is the direct cause of the failure."

It is more relevant than ever considering how computerized a modern
vehicle is and that making basic repairs these days requires firmware
modifications on some vehicles (ex: the john deere tractor problem) and
I am sure it will eventually end up in the supreme court.
It is a damn shame now even cars have been made very complex and
computerized for no real reason.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Server systems shipped with coreboot

[taii...@gmx.com]

On 03/23/2018 05:37 PM, Alberto Bursi wrote:

> I wanted to say what I said. Dell, HP, Supermicro, Tyan, and whatever other 
> OEM making commercial servers I know of is highly unlikely to accept a RMA or 
> provide any support on their hardware if you install Coreboot.
> Therefore any seller of such devices would have to provide such support  and 
> warranty on their own.
>
> If you just tampered the UEFI firmware is much less of an issue for RMA and 
> support (in my experience), depending on how bad you tampered with it, anyway.
Which is why you re-flash the original factory firmware before you RMA
it >:D

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Server systems shipped with coreboot

[taii...@gmx.com]

Please also keep in mind that it is impossible to disable ME.

*I am not a lawyer*
In america the first sale law means you are allowed to do as you please
with a device you purchased as long as you are not violating any EULA
but if you somehow did the impossible and figured out how to execute
code on the ME core you would be breaking the law as it is also a DRM
mechanism (PAVP, HDCP, intel insider etc) which is illegal to bypass.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[taii...@gmx.com]

On 03/20/2018 06:14 PM, Nico Huber wrote:

>> These patches need to be added stat
> You obviously have no idea what you are talking about.
What makes you say that?
> AFAIK, nobody who has the right to submit to the blobs repository has 
> commented yet on
> newer microcode updates or was asked personally if this is acceptable.
> You might have noticed that microcode updates are not public domain but
> licensed.
Almost every linux distro redistributes them without issue and intel is
suppository a coreboot contributor (to which I have been reminded of
multiple times)

I don't see as to how that is something that can't be worked around by
asking people to download it themselves from a browser or making a shell
script that imports intel's EULA and asks the user to agree to it before
downloading it when they compile coreboot.

Other microcode updates are included coreboot so are a variety of ME
images and other binary blobs from intel so I fail to see the
distinction here.
>> - the stakes are too high for this to take months.
> You still didn't get what Spectre is about, did you? 
I do.
> It's just one of many side-channel attacks that are possible when you run 
> untrusted code on your machine.
The whole point of a VM is that you are able to run untrusted code with
some decent level of isolation and spectre ruins this.
What other exploits exist which can easily read data from a VM's host?
If there is a fixable problem why not fix it?

The idea that the only way to go about things is to trust all the code
that runs on your computer is backwards and unrealistic as even if you
only ran foss programs on a modern linux you still have millions of
lines of un-audited code loaded with exploits.
> These updates just help with one instance of a much bigger problem and won't 
> magically make your computer (and the software you run) secure.
Yes obviously but this is saying that because you can't be fully secure
you shouldn't bother with anything at all.
> Have a look at [1] or uMatrix. These are much better mitigations, IMHO.
> But if you are really security concerned you already know that anyway.
That wasn't the question and I don't appreciate replies like this.
Should firmware programmers be the only ones using coreboot? I have
patched my kernel and various other programs before but I have no reason
to use git and I couldn't figure this out myself.

If you were a sysadmin for a large company would you tell them to not
bother applying the spectre mitigations? should their users use umatrix
instead and that anyone who accidentally enables a site with encryption
key/password stealing malicious javascript gets fired? Enabling
javascript on a per site basis is like playing minesweeper - eventually
you will step on a mine no matter how careful you are.

I have to use javascript for many websites I need which is why I have a
browser in a VM just for them but I don't want them to be able to be
able to read host memory or the memory of other VM's.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[taii...@gmx.com]

Yeah I tried that but it didn't work.

git fetch https://review.coreboot.org/blobs refs/changes/15/23315/6 &&
git cherry-pick FETCH_HEAD

warning: no common commits
remote: Counting objects: 555, done
remote: Finding sources: 100% (30/30)
remote: Total 1426 (delta 1), reused 1418 (delta 1)
Receiving objects: 100% (1426/1426), 13.30 MiB | 4.21 MiB/s, done.
Resolving deltas: 100% (396/396), done.
From https://review.coreboot.org/blobs
 * branch  refs/changes/15/23315/6 -> FETCH_HEAD
error: could not apply 4f04985590... cpu: intel: microcode update for
currently tracked models to 20180312
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit

What do I do now? I have never used git before.

These patches need to be added stat - the stakes are too high for this
to take months.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[taii...@gmx.com]

On 03/20/2018 04:17 AM, Martin Kepplinger wrote:


Yes, they even updated sandybridge and ivybridge. (For those, you
only need the first of those 4 patches)
There are some of the last released high end xeon/core 771/775 CPU's 
getting updates in the future too.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[taii...@gmx.com]

So you are saying that sandy and ivybridge have spectre microcode updates?

I hate how unclear intel is about this.

How do I patch my coreboot?

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Gigabyte MB to Test

[taii...@gmx.com]

Like nico said it would be quite difficult to do this yourself and not 
really worth the time, and for the price of contracting someone else or 
even spending the time yourself (vs working overtime hours) you could 
buy lots of boards with already done open source firmware that works 
perfectly. Literally for the price of a coreboot port for this board you 
could buy 20+ fully loaded TALOS 2 systems and 50+ KCMA-D8's.


What exactly are you looking for in a board? I assume embedded? you can 
pick up a coreboot compatible AM1 (check the list) for quite cheap right 
now - if you require more expansion options and/or a BMC I would go with 
the KCMA-D8 which supports dual fanless capable 4 or 8 core 35W TDP 
CPU's and 128GB RAM - if you can find some they are a super great owner 
controlled libre firmware embedded/router platform and they support 
OpenBMC via a ASMB4 or ASMB5 module.
Both systems have lots of AMD provided documentation as they are from 
right before when AMD stopped supporting the open source firmware 
community and of course the high performance TALOS 2 is also well 
documented (and has libre firmware) if you want something fast/not an 
embedded platform.


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot