It seems that flashrom is able to flash the bios chip internally. This is frightening. This means that malware or anything that gets sudo rights or anyone who gets physical access to computer is able to rewrite the flash.
Dont say "if there is physical access to your computer, its game over" this is now true. I have a way to tamper detect if the case was opened.
My question is. How can I make it where coreboot can only be flashed and updated using the external SOIC clip on the bios chip? Without having to worry about permanently locking it down. I want to be able to reflash coreboot and seabios but only using an external flasher when needed. I want to block internal flashing.
How can this be done? I have not found any documentation anywhere on how to do this. The laptop is X220
Sent with [ProtonMail](https://protonmail.com) Secure Email.
Hi Frans and Felix,
On 2019-07-09 11:56 AM, Felix Held wrote:
> Hi Frans!
>> Proposal is creating a COM directory ‘src/com’ where the module
>> manufacturer and module name are used. (Similar to mainboard).
>> In this src/com directory common module support is placed.
>> mainboard will use this COM module and contains the ‘variant’ code.
> Sounds like a good idea to me; I wouldn't call the directory src/com
> though since my first association with that name would be some sort of
> communication device support. Maybe src/som (system on module)?
Technically a SOM/COM wont work at all without a carrier board.
The configuration (devicetree.cb) heavily depends on the carrier board,
but on the
other hand the GPIO configuration is likely SOM specific.
I guess it's a good idea to put *non mainboard-specific* code in src/som
On the other hand as already said the variant scheme works quite well.
> I think I talked with Nico and siro on that some months ago on IRC, so
> it would be good if they could also comment on this.
> I think the other option we talked about was having the module as a
> base and the official carrier board as mainboard variant and then use
> the module code in a mainboard with the vendor being the vendor of the
> carrier module which is a variant of the other mainboard code.
> Putting this into a separate directory is probably the cleaner option
> If the variants approach works well for that, I'd like to keep using
> that and not introducing some new infrastructure; if that causes some
> major pain, it might also be worth investigating how to improve things
If we decide to go either way the documentation should be updated to
explain this decision.
maybe some of you have already seen it in common Linux online media.
We are currently looking for Coreboot developers.
You should bring along:
- Knowledge of C and C++
- Already experience with the development of kernel modules
- Enjoy testing new hardware
- Experience in driver development
- Knowledge of LVFS and fwupd advantageous
- Ideally already busy with Coreboot, EFI or similar.
More about this also at:
So if someone is interested or knows someone here, please contact us!
If you have any questions, please contact me directly!
Mit freundlichen Grüßen / Kind regards
TUXEDO Computers GmbH
Zeppelinstr. 3 ~ D-86343 Königsbrunn
Tel: +49 (0) 8231 / 99 19 000
Fax: +49 (0) 8231 / 99 19 009
www.TuxedoComputers.com ~ www.Linux-Onlineshop.de
Amtsgericht Augsburg: HRB 27755 ~ USt-IdNr.: DE815420876
Geschäftsführer: Herbert Feiler
Coreboot build today. Opteron 6300. Latestest Microcode.
Debian Buster (10) dont send me emails that state i should install any
Linux 4.9 (AS 4.19 is still buggy and does not boot :(( quite frustrated
with this board now ... starved 2 month to buy a fucking libre server
on VM startup following kernelmessages appear:
63.305854] general protection fault: 0000 [#1] SMP
RIP: 0010:[<ffffffffc0c53959>] [<ffffffffc0c53959>]
/var/log/kern.log.1:Jul 14 10:46:48 lain kernel: [ 63.652881] RIP
[<ffffffffc0c53959>] svm_vcpu_load+0xf9/0x130 [kvm_amd]
I'm looking for https://review.coreboot.org/18381 which corresponds to
While the commit is in master I cannot access the change on gerrit.
Was the database corrupted?
Was the change made private after it has been merged?
Was it deleted?
A couple of years ago I saw Ron's talk on NERF. An acquaintance who
maintains a fleet of machines expressed some interest in NERF. He wants to
boot linux instead of windows, which isn't supported by his (extremely
recent) build of UEFI. (no legacy support whatsoever)
The closest thing I could find to instructions for using it or otherwise
replicating what's been done is the explanation for the Dell R630 here: 
Many sections are still TODO and it overall seems fairly half-baked (with
things like USB and networking not working).
I surmise the basic steps are:
-Dump the BIOS flash
-Extract key boot blobs from flash
-Configure and build NERF
-Flash resulting image
Has any progress been made (public) since 2017? Does a generalized install
process exist (like that provided by me_cleaner, for example) or is this
something that requires a large amount of rework for each platform?
I imagine it is totally impossible to produce anything that would be
accepted by stock UEFI as an update for internal flashing.