[coreboot] Re: Custom Splash Screen

[R S]

Yeah the Purism post is written by the great Youness Alaoui who worked
pretty hard to get the LibreM BIOS working. I remember the time where he
was posting regularly on the coreboot list here. Amazing work and
documentation. I for one am thankful for Purism hiring him.

On Wed, Jul 26, 2023 at 3:17 AM Ahamed Husni 
wrote:

> Hi Michał Żygowski,
>
> Thank you for the quick response. The links you provided
> have important information which I could not have figured
> myself out. I will try it and let you know the results :)
>
> Thank you,
> Husni.
>
> On Tue, Jul 25, 2023 at 1:24 PM Michał Żygowski 
> wrote:
>
>> Hi Ahamed Husni,
>>
>> On 7/24/23 18:50, Ahamed Husni wrote:
>> > Hi all,
>> >
>> > I want to display a custom logo in the splash screen for a specified
>> > amount of time (SeaBIOS as payload). How do I configure the logo and
>> > give a timeout when building coreboot? Any pointers will be really
>> > helpful.
>>
>> Logo: https://www.seabios.org/Runtime_config#Bootsplash_images
>> (bootsplash.jpg)
>>
>> You may add the custom logo to the CBFS by specifying the path to logo
>> file during coreboot build in menuconfig General Setup -> Add a
>> bootsplash image
>> SeaBIOS is quite picky regarding the format of the JPEG and BMP. Be sure
>> to use some legacy screen resolution, the logo file must also exactly
>> match the screen resolution.
>> Here is a blog from Purism where some struggles with JPEG format and
>> SeaBIOS are discussed:
>> https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/
>>
>> Specified amount of time:
>> https://www.seabios.org/Runtime_config#Other_Configuration_items
>> (etc/boot-menu-wait)
>>
>> The timeout can be added using cbfstool after the build is finished:
>>
>> cbfstool coreboot.rom add-int -r COREBOOT -n etc/boot-menu-wait -i
>> 
>>
>> If you have vboot with multiple CBFSes then you would also need to run:
>>
>> cbfstool coreboot.rom add-int -r FW_MAIN_A -n etc/boot-menu-wait -i
>> 
>> cbfstool coreboot.rom add-int -r FW_MAIN_B -n etc/boot-menu-wait -i
>> 
>>
>>
>> >
>> > Regards,
>> > Husni.
>> >
>> > ___
>> > coreboot mailing list -- coreboot@coreboot.org
>> > To unsubscribe send an email to coreboot-le...@coreboot.org
>>
>> Best regards,
>> --
>> Michał Żygowski
>> Firmware Engineer
>> GPG: 6B5BA214D21FCEB2
>> https://3mdeb.com | @3mdeb_com
>>
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Cybersecurity Analyst
Technology Department


Buncombe County Schools
ComicSans Awareness Campaign 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs

[R S]

Glad this is being addressed in coreboot. According to
https://kb.cert.org/vuls/id/796611 Insyde's UEFI implementation currently
has 23 SMM vulnerabilities researched and disclosed by the company
binarly.io and there is no telling if and when the vendors downstream apply
the fixes and release BIOS updates to their customers.

On Tue, Apr 26, 2022 at 11:45 AM coreboot org 
wrote:

> The branches for 4.14, .15, and 4.16 are created and ready for patches
> to be pushed.
>
> After the patches are merged, I'll handle the releases.
>
> Martin
>
> On Mon, Apr 25, 2022 at 11:54 PM Shawn C 
> wrote:
> >
> > Nice hunt, Arthur! The attack surface in coreboot is lesser than UEFI
> but the misconfig during the setup will lead to serious issue. This one is
> neat and worth a CVE. Please use CVE-2022-29264 as record:
> >
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29264
> >
> > regards
> > Shawn
> >
> >
> > --- Original Message ---
> > On Thursday, April 7th, 2022 at 10:43 PM, Arthur Heymans <
> art...@aheymans.xyz> wrote:
> >
> >
> > > Hi
> > > When refactoring the coreboot SMM setup I noticed that there is a
> security vulnerability in our SMM setup code.
> > > It boils down to this: except on the BSP the smihandler code will
> execute code at a random location, but most likely at offset 0. With some
> carefully crafted code a bootloader or the OS could place some code at that
> offset, generate an SMI on an AP and get control over SMM. More recent
> silicon has hardware mechanisms to avoid executing code outside the
> designated SMM area (TSEG) so those would not be affected.
> > > The commit introducing this problem is
> https://review.coreboot.org/c/coreboot/+/43684.
> > > Roughly it affects most x86 builds from end 2020/ beginning 2021 till
> now.
> > >
> > > https://review.coreboot.org/c/coreboot/+/63478 fixes the problem.
> (Feel free to review the rest of that series as it makes the smm setup much
> more readable ;-))
> > > Kind regards
> > > Arthur
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Memtest86+ stuck

[R S]

On Thu, Apr 23, 2020 at 6:46 AM Paul Menzel  wrote:

> PS: By the way, Memtest86+ 5.31b was released [2].
>
> [1]: https://review.coreboot.org/c/coreboot/+/32613
> [2]: https://www.memtest.org/


That's huge! Thanks for picking up development.

-- 
LAN Engineer * NOC and IT Infrastructure Maintenance
BCS Technology Department * Network Group
ComicSans Awareness Campaign 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: OSFC videos

[R S]

youtube-dl probably can deal with this.
Install from https://ytdl-org.github.io/youtube-dl/download.html or
https://github.com/ytdl-org/youtube-dl/releases
Know your options:
https://github.com/ytdl-org/youtube-dl/blob/master/README.md

I'm assuming you are using invidio.us instead of youtube frontend.

Parameters to be used:
a) OSFC Channel: https://invidio.us/channel/UCUVk2lv2h2VbP3Dx4k2axyA
b) Date: seems like the videos from the September conference were all
uploaded December 2nd

Hence:
youtube-dl --date 20191202
https://invidio.us/channel/UCUVk2lv2h2VbP3Dx4k2axyA
If that doesn't catch all videos try --dateafter 20191130.


On Thu, Jan 2, 2020 at 7:46 PM Alexander 'lynxis' Couzens 
wrote:

> Hey,
>
> is there a way to get the OSFC videos more directly?
>
> E.g. I would like to download them as a bunch. youtube is quite
> limited here. I perfectly understand, why it's on youtube, however
> having them as simple download similiar to https:// with index or plain
> old ftp would be nice! *
>
> Best,
> lynxis
>
> * similiar to https://media.ccc.de/
>
> --
> Alexander Couzens
>
> mail: lyn...@fe80.eu
> jabber: lyn...@fe80.eu
> gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
LAN Engineer * NOC and IT Infrastructure Maintenance
BCS Technology Department * Network Group
ComicSans Awareness Campaign 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: MrChromebox 4.11 community release

[R S]

Thanks Matt. You're the man. COreboot 4.11 is out just a few days and we
can already enjoy on our freed chromebooks. Awesome.

On Mon, Nov 25, 2019 at 6:18 PM Matt DeVillier 
wrote:

> Hot off the heels of the previous hotfix is a fresh release based on
> the newly-tagged coreboot 4.11. In addition to being rebased on the
> latest version of coreboot, this release features a host of
> improvements and fixes:
>
> * fixed issue with NVRAM being corrupted by Windows
> * new/improved UEFI Boot Options/Settings screens
>* improved header layout
>* simplified menu options
>* more descriptive naming for SATA, NVMe, and USB drives in boot menu
>* easier to make changes to and save bootorder entries
> * open-source coreboot native graphics init (libgfxinit) now used for
> Haswell, Broadwell, and Skylake devices instead of closed-source GOP
> driver
> * better scaling of boot splash/menus for HiDPI displays
>
>
> This MrChromebox release offers coreboot/Tianocore images for close to
> 70 Chromebooks/Chromeboxes as well as all Purism Librem laptops, all
> easily flashed using my ChromeOS Firmware Utility Script [1]; a full
> list of supported devices can be found on my site [2].
>
> All other devices supported by the coreboot 4.11 release can easily
> take advantage of the improvements in my tree by cloning my coreboot
> repo and building as usual.
>
> All changes on the Tianocore side have already been merged and are
> available to anyone using the default coreboot repo.
>
> As usual, the full list of changes can be found on my github repos:
> https://github.com/MrChromebox/coreboot/commits/2019.11.28
> https://github.com/MrChromebox/edk2/commits/2019.11.28
> https://github.com/MrChromebox/chrome-ec/branches/all
>
> cheers,
> Matt
>
> [1] https://mrchromebox.tech/#fwscript
> [2] https://mrchromebox.tech/#devices
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
LAN Engineer * NOC and IT Infrastructure Maintenance
BCS Technology Department * Network Group
ComicSans Awareness Campaign 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Fwd: Re: Starting the coreboot 4.10 release process

[R S]

I saw somewhere on Mastodon that the foss collaborative piratepads will be
closed this week. Are you guys affected? Where are you moving?

On Mon, Jun 3, 2019 at 7:21 PM Matt B  wrote:

>
>
> -- Forwarded message -
> From: Matt B 
> Date: Mon, Jun 3, 2019 at 7:19 PM
> Subject: Re: [coreboot] Re: Starting the coreboot 4.10 release process
> To: Mike Banon 
>
>
> On a side note, when more than one option is possible, it's good to know
> which the tester used.
>
> Hypothetical example: did someone test the X230 with a vgabios blob or
> with libgfxinit?
> If unspecified, or if the default is the vgabiosblob (or nothing at all,
> as above) then who knows if libgfxinit works?
>
> -Matt
>
> On Mon, Jun 3, 2019 at 4:21 PM Mike Banon  wrote:
>
>> Okay, I returned your boards but added a note that "no board_status
>> report yet". Hopefully you could submit them in the near future, at
>> least for the archival purposes. And there's a similar question to
>> someone else who added "Asus P8H61-M Pro" despite that the latest
>> report for it is one year ago.
>> > The default config should always be a known good config, unless the
>> > board isn't well maintained. Needing a specific "good config" is a
>> > sign of unattended bugs.
>> Not necessarily: it could be that a default config is bootable for
>> some board but still somehow inferior. For example, it may boot but
>> without showing anything on a display, because no VGABIOS specified or
>> provided. Or i.e. it may be hard to convince the people to enable some
>> config by default despite it being useful, e.g. a coreinfo secondary
>> payload. So board_status report is a great way to promote your nice
>> config, and hopefully the people would share them more
>>
>> On Mon, Jun 3, 2019 at 5:28 PM Matt DeVillier 
>> wrote:
>> >
>> > I added those devices, all of which I have in my possession and were
>> tested over the weekend with TOT. I'd not yet had a chance to upload board
>> status for them, but figured knowing a good range of platforms/boards were
>> known working just prior to release was useful (and the purpose of the list)
>> >
>> > On Mon, Jun 3, 2019 at 9:14 AM Mike Banon  wrote:
>> >>
>> >> Just noticed that someone included i.e. some Purism Librem devices to
>> >> a " Recently tested mainboards: " section - but, when I check
>> >> https://review.coreboot.org/cgit/board-status.git/log/purism , the
>> >> latest board status for Purism happened even before 4.9 ! And without
>> >> a recent enough _public_ "board status" report - containing the
>> >> important info about your build and its' complete configuration - I
>> >> don't think we could include them to a "recently tested" list, since
>> >> the other users won't have a chance to reproduce your build by using
>> >> your configuration. Same question regarding some other of these
>> >> additions, so removing them from a " Recently tested mainboards: "
>> >> list, but of course they could be re-added if someone will submit a
>> >> board_status reports from them.
>> >>
>> >> We would like to encourage the board status reporting, and relying on
>> >> the word of users ( "I tested X board and it worked" ) would not help
>> >> us to collect the known good configs at our coreboot/board_status
>> >> repository.
>> >>
>> >> To submit a board status report for your board, please run a
>> >> ./coreboot/util/board_status/board_status.sh script on it.
>> >>
>> >> Removed:
>> >> * Purism Librem 13 v1
>> >> * Purism Librem 15 v2
>> >> * Purism Librem 13 v2/v3
>> >> * Purism Librem 15 v3
>> >> * Purism Librem 13 v4
>> >> * Purism Librem 15 v4
>> >> * Samsung Chromebook 3 (google/celes)
>> >> * Acer Chromebook R11 (google/cyan)
>> >> * Google Chromebook Pixel 2013 (google/link)
>> >> * Toshiba Chromebook 2 (2014) (google/swanky)
>> >> * Dell Chromebook 13 7310 (google/lulu)
>> >> * Dell Inspiron Chromebook 14 (google/nami)
>> >> * Acer Chromebook 14 (google/edgar)
>> >> * HP Chromebook 13 G1 (google/chell)
>> >> * Asus Chromebox CN60 (google/panther)
>> >> * Asus Chromebox CN62 (google/guado)
>> >> * Asus Chromebox CN65 (google/fizz)
>> ___
>> coreboot mailing list -- coreboot@coreboot.org
>> To unsubscribe send an email to coreboot-le...@coreboot.org
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: redleaf

[R S]

Thanks for sharing this.

On Fri, May 17, 2019 at 6:44 PM ron minnich  wrote:

> "RedLeaf is a new operating system being developed from scratch to
> utilize formal verification for implementing provably secure firmware.
> RedLeaf is developed in a safe language, Rust, and relies on automated
> reasoning using satisfiability modulo theories (SMT) solvers for
> formal verification. RedLeaf builds on two premises: (1) Rust's linear
> type system enables practical language safety even for systems with
> tightest performance and resource budgets (e.g., firmware), and (2) a
> combination of SMT-based reasoning and pointer discipline enforced by
> linear types provides a unique way to automate and simplify
> verification effort scaling it to the size of a small OS kernel."
>
> https://dl.acm.org/citation.cfm?id=3321449
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>


-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] How to get correct memory params for FSP

[R S]

Thanks for it after all those years.
// end being off-topic

On Tue, Nov 6, 2018 at 12:45 PM Alex Feinman 
wrote:

> Guilty as charged :)
>
> --
> *From:* R S 
> *Sent:* Tuesday, November 6, 2018 9:30 AM
> *To:* alexfein...@hotmail.com
> *Cc:* coreboot@coreboot.org; alexey_...@mail.ru
> *Subject:* Re: [coreboot] How to get correct memory params for FSP
>
> Faint memories... are you the ISO recorder author from 15 years ago?
>
> On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman 
> wrote:
>
> The two major issues with bringing up the memory subsystem on a new board
> are SPD parameters and DQ/DQS layout
> Specifically, if you look at the apollolake rvp subtree, you can see a
> whole bunch of parameters being set in romstage.c. Some of it is fairly
> straightforward. Swizzling tables are not and require you to be able to
> read schematic (and have access to it in the first place)
> Obviously, the problem could be elsewhere. I would start with enabling MRC
> debug and perhaps posting the MRC output
>
> --
> *From:* coreboot  on behalf of Alexey
> Borovikov via coreboot 
> *Sent:* Saturday, November 3, 2018 5:38 AM
> *To:* coreboot@coreboot.org
> *Subject:* [coreboot] How to get correct memory params for FSP
>
> Hi.
> I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP
> for the Baytrail family. The result - postcode is 0x2A. From the
> descriptions on the Internet, I understand that the problem is in the
> incorrect memory parameters.
> Question: are there any utilities or methods that will help to get the
> correct memory parameters when working a regular BIOS from Linux or Windows
> systems?
> Many thanks!
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> Tech III * AppControl * Endpoint Protection * Server Maintenance
> Buncombe County Schools Technology Department Network Group
> ComicSans Awareness Campaign <http://comicsanscriminal.com>
>


-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign <http://comicsanscriminal.com>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to get correct memory params for FSP

[R S]

Faint memories... are you the ISO recorder author from 15 years ago?

On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman 
wrote:

> The two major issues with bringing up the memory subsystem on a new board
> are SPD parameters and DQ/DQS layout
> Specifically, if you look at the apollolake rvp subtree, you can see a
> whole bunch of parameters being set in romstage.c. Some of it is fairly
> straightforward. Swizzling tables are not and require you to be able to
> read schematic (and have access to it in the first place)
> Obviously, the problem could be elsewhere. I would start with enabling MRC
> debug and perhaps posting the MRC output
>
> --
> *From:* coreboot  on behalf of Alexey
> Borovikov via coreboot 
> *Sent:* Saturday, November 3, 2018 5:38 AM
> *To:* coreboot@coreboot.org
> *Subject:* [coreboot] How to get correct memory params for FSP
>
> Hi.
> I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP
> for the Baytrail family. The result - postcode is 0x2A. From the
> descriptions on the Internet, I understand that the problem is in the
> incorrect memory parameters.
> Question: are there any utilities or methods that will help to get the
> correct memory parameters when working a regular BIOS from Linux or Windows
> systems?
> Many thanks!
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>


-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SPI controller and Lock bits

[R S]

Yes, thanks Youness for all the hard work and research. You provided an
exceptional service. I enjoyed your rants and explanations both on Purism's
blog and here. Hopefully Purism can fill that void you are leaving behind.

On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper  wrote:

> Hi Youness,
>
> On 15/10/2018, Youness Alaoui  wrote:
> > One thing to note is that this week will be my last week at Purism as
> > I'm going on sabbatical for a few months, and I may or may not (most
> > likely won't) come back to Purism in a few months.
>
> Thank you for your efforts to make Coreboot work on the Librems, and
> for the enthusiasm you displayed here in the mailing list and on the
> Purism blog.
>
> Although I might have sounded critical on occasion, this was never
> personal; it was always out of a concern to avoid missing
> opportunities to achieve the most secure and privacy-protecting
> machines available within the constraints of the hardware and the
> business model. I.e. my "criticisms" were always intended to be
> constructive. I hope that they did not form any part of your decision
> to take a break from Purism, and if they did, I apologise.
>
> I wish you a good sabbatical, in any case.
>
>
> > @Sam
> > for 90% of the users, they would either :
> > - never [flash the ROM]
> > - only do it when a new update is released and interests them, i.e:
> > once or twice a year.
> > So [...] it would be far
> > from annoying to users since most won't care or notice that all that
> > is needed, and if they do, they won't care to have to do it so rarely.
>
> I fear that even performed rarely, it might be beyond some users'
> abilities. But...
>
> > It will however, especially with cover-opening protections (either
> > using glitter/whatever methods on screws to notice if they'd been
> > opened, or with an EC handling a cover switch notification), that
> > could be very helpful to increase their security.
>
> ... I agree that making it tamper-evident is indeed potentially valuable.
>
>
> >> Your assumption fails against a BadHeads attack.
> > Yes indeed, I wrote a proof of concept which was a Heads that would
> > extend PCRs with the same values that coreboot did (and have a
> > coreboot with measured boot disabled) and it passed the TOTP
> > authentication.
>
> Many thanks for confirming this to the mailing list. I was hoping to
> write and somehow disseminate (e.g. to the Heads developers) a POC
> myself, but I'm glad to be spared that need.
>
> If you could send your POC to the Heads team for integration into the
> test suite, that would be great. This flaw in Heads needs to be fixed
> (if it hasn't already been). Having the POC in the test suite would
> also help to detect future regressions, once the issue is fixed (if it
> *can* be fixed).
>
> If it hasn't yet been fixed... Thinking aloud: as a community, we need
> to find a way (or else, determine that it really is impossible) to
> achieve robust mutual authentication between PC and user, with just an
> SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token.
> Some kind of formal verification might be in order.
>
>
> > That's something that other possible solutions would
> > try to mitigate (such as vboot I think).
>
> In the open world, vboot does seem to be the state of the art.
>
> Apple's T2 chip might also mitigate against this sort of thing,
> although it does not authenticate to the user via TOTP: the check is
> implicit rather than explicit. I may be wrong, though. Public
> documentation seems to be scarce.
>
>
> >> it would be great if Purism could be
> >> sure not only to spec, but also to list on the Librem specification
> >> pages on the website, a SPI flash ROM chip that *does* obey its
> >> write-protect pin regardless of firmware. Thanks :)
> > I didn't realize that "some chips don't obey the write-protect pin",
> > but rather my understanding is that the write protect pin is there to
> > say "the protected blocks are protected/not-protected according to
> > hardware.
> > The SPI flash (according to the datasheets I've read) can protect
> > regions either with "don't protect" or "protected by WP#" or
> > "protected until power-cycle".
> > The status register bits can be written to either as volatile or
> > non-volatile (for non volatile, you need another command iirc, and you
> > can't do it with hardware sequencing, same for the 'protect until
> > power cycle', which also needs to write to status-register-2 which
> > can't be done with hardware sequencing either).
> > So, really, a flash rom chip does obey its WP pin, it just depends on
> > how it's set.
>
> Thanks for this. I clearly need to spend more time reading data sheets
> and running tests on SPI flash ROM chips.
>
> All best,
>
> Sam
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>


-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group

Re: [coreboot] anybody know more about https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00160.html

[R S]

This advisory is one of the 10 released vulnerabilities published by Intel
June 10th[1][2]. One of them is called Spectre v1.1 (Paper:
https://people.csail.mit.edu/vlk/spectre11.pdf ). At least 2 of the 10
vulnerabilities seem to be part of Intel's Bug Bounty Program, one of them
worth $100k[3].

[1] https://www.intel.com/content/www/us/en/security-center/default.html
[2] https://01.org/security/advisories/intel-oss-10002
[3] https://hackerone.com/intel/hacktivity?sort_type=
latest_disclosable_activity_at=type%3Abounty-awarded%20to%3Aintel


On Wed, Jul 11, 2018 at 4:57 PM, ron minnich  wrote:

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



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot community meeting January 5th, 2017 report

[R S]

Thanks for providing this summary.

On Fri, Jan 5, 2018 at 8:34 AM, Arthur Heymans  wrote:

> Dear coreboot community
>
> This is the report of yesterdays community meeting:
>
> General coreboot news & Discussion
> ==
>
> There is patch [1] up for review that implements LinuxBoot as payload.
>   - Currently with u-root in the initrd, which is an userspace entirely
>   written in go;
>   - Currently only as a payload but in the future it could replace
>   ramstage on some targets;
>   - Currently its still WIP and doesn't work all that well with qemu
>   targets;
>   - It needs some Kconfig options for some simple example
> configurations;
>   - In the future we also want to integrate the HEADS[2] userspace
>   and possibly also an userspace featuring the petitboot kexec
>   gui[3];
>
> The 4.7 release is imminent and Martin will hopefully be able to finish
> up the releasenotes this weekend.
> The 4.6 release announced that after the 4.7 release platforms lacking
> the early cbmem feature will be removed from the master branch. Those
> platforms can then live in the 4.7 branch or be reintegrated when early
> cbmem support is implemented. The details about how and when this will
> happen have yet to be decided/discussed.
>
> Development
> ===
>
> There was some discussion about how to move forward to use the new ACPI
> ASL 2.0 syntax, which is considered more readable. There previously was
> a discussion on this topic on the mailing list [4].
> Currently it is possible with iasl to compile and decompile our ASL
> sources to the new syntax but this would lose all our comments, so
> ideally a new tool would need to be written to handle that
> transition. It was also suggested that given the fact that coreboot
> has reproducibel timeless builds, it would be able to tell if anything
> changed in the resulting binary, which it shouldn't since the resulting
> bytecode ought to be the same.
>
> In the mean time we still need to have a discussion about what do with
> for instance new asl source files: do we still want the old syntax or is
> the new syntax ok for new files? Mixing syntaxes in existing files
> seemed a bad idea.
>
> So what are your ideas and opinions on this?
>
> Infrastructure
> ==
>
> The pre-commit hook doesn't return failures on 'make lint-stable' but
> this seems to be fixed in [5].
>
> Documentation
> =
>
> Currently there is an effort going on to have the documentation
> accessible in one place on the web. The current idea was to use hugo for
> static webpage generation for this, see [6]. Some concerns were however
> raised that this particular theme works rather poorly without
> javascript, so it might be desirable to find a better lightweight
> theme.
> Related to this, is the ongoing effort to convert our current
> documentation to markdown and move those files to a different directory
> which starts with lowercase letter for consistency, with a separation of
> a content and a static folder.
> The idea to use netlify to push it to the production server was also
> suggested. (Philipp might be able to say something in more details about
> this)
>
> Flashrom 1.0 was released!
> This new release has some nice new features that make handling some
> blobs like the IFD/GBE/ME/... on Intel systems much easier. One can now
> with the --ifd flag fetch the flash layout from flash and use this to
> read/write/erase those regions. Also a --noverify-all or -N flag was
> introduced which skips verifying regions that were not touched at all,
> which can greatly speed up flashing if one is only writing to a small
> region on a large flash. Our guides however need to be adapted to use
> these features. One example where this has already been done is [7]
> which still has the old instructions for reference.
> In the future flashrom will support Linux MTD (memory technology
> device) which can remove the need to boot Linux without strict checking
> of MMIO memory regions (currently flashrom needs the iomem=relaxed boot
> parameter to use the internal programmer).
>
>
>
> I hope you can join us next time!
>
> Kind regards
>
> Arthur
>
>
> [1] https://review.coreboot.org/#/c/coreboot/+/23071/
> [2] https://trmm.net/Heads
> [3] https://github.com/ArthurHeymans/petitboot_for_coreboot
> [4]
> https://mail.coreboot.org/pipermail/coreboot/2016-September/082050.html
> [5] https://review.coreboot.org/#/c/coreboot/+/23130/
> [6] https://www.coreboot.org/Documentation/
> [7] https://www.coreboot.org/Board:lenovo/x200#Flashing_
> your_coreboot_ROM_image
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[R S]

Thanks for elaborating and shedding light on this for some of us
non-experts who are just lurking around.

On Thu, Dec 14, 2017 at 2:20 AM, Youness Alaoui <
kakar...@kakaroto.homelinux.net> wrote:

> Hi,
>
> From the PT article you linked to, after the stage 5 of BUP execution :
> "It is at this stage that we find HAP processing; in this mode, BUP
> hangs instead of executing InitScript. This means that the remaining
> sequence of actions in normal mode has nothing to do with HAP and will
> not be considered. The main thing we would like to note is that in HAP
> mode, BUP initializes the entire platform (ICC, Boot Guard) but does
> not start the main ME processes."
>
> As for the kernel, that's my mistake, I remembered that prior to ME
> 11.x, the KERNEL module was removed by me_cleaner, and BUP was the
> first process loaded. I hadn't realized that the execution order
> changed in ME 11.x, and that explains why the KERNEL module cannot be
> removed by me_cleaner in ME 11.x.
> On ME 10.x and lower, the BUP module was the first executed, and it
> would then load the KERNEL, so if BUP is halted before it did that,
> then the kernel doesn't run. In ME 11.x however, they changed the
> order, the KERNEL module is first to be loaded, but it only starts the
> BUP process :
> "The first process that the kernel creates is BUP, which runs in its
> own address space in ring-3. The kernel does not launch any other
> processes itself; this is done by BUP itself"
> So, you are right, on Skylake+ (ME 11.x), the kernel would be running
> but the BUP process is the one halted and no other processes get
> launched, but on ME 10.x and lower, the kernel wouldn't be running
> since BUP is loaded first (this is true for me_cleaned ME 10.x, and
> I'm not sure what exactly the MeAltDisable flag does, which is the
> equivalent of HAP on previous versions, but there wasn't any specific
> research done on that).
>
> I hadn't realized that until now when researching an error-free
> response to you, so thanks for helping me notice that mistake in my
> understanding.
>
> Youness.
>
>
>
> On Wed, Dec 13, 2017 at 12:54 PM, Timothy Pearson
>  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > According to Positive Technologies, on Skylake and higher (like the
> > Purism machines) the kernel loads the BUP, and the HAP bit only disables
> > the normal userspace processes [1].
> >
> > What proof do you have that the kernel itself is halted?
> >
> > [1] http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
> >
> > On 12/13/2017 11:34 AM, Youness Alaoui wrote:
> >>> I guess I still disagree with the use of the word "disabled".  If the
> ME
> >>> wasn't required for boot, and was actually disabled within a few cycles
> >>> of its CPU starting, the remaining attack surface simply wouldn't
> exist.
> >>>  This is not what happens though, and AFAIK even the ME kernel
> continues
> >>> to run since the ME needs to continue handling platform power events.
> >>> If this many holes are present in even the ROM code, then having the ME
> >>> kernel running remains a massive security problem.
> >>>
> >>
> >> I'm just going to answer the bit about the use of the term "disabled".
> >> I've explained it in my blog post before (here if you missed it :
> >> https://puri.sm/posts/deep-dive-into-intel-me-disablement/) but I do
> >> believe the ME is in this case Disabled. What you are thinking about
> >> is what I called "Removed". The reason it's called disabled is because
> >> the ME stops running, it's not actively doing anything, it doesn't
> >> respond to HECI, it doesn't even boot into the kernel. You said that
> >> "the ME kernel continues to run", but that's not the case. The entire
> >> ME core stops execution during the bring-up phase, so it's technically
> >> disabled because it stops itself at some point after boot.
> >> Having the ME *removed* would be interesting because that would mean
> >> that even the bring up phase wouldn't get executed and we could remove
> >> the entire ME firmware from the flash. But that still wouldn't mean
> >> that nothing runs on the ME core because there is still some small
> >> code embeded in the ROM.
> >> Anyways, that's my justification on why using the term "disabled" is
> >> valid in this case when HAP is enabled. You are free to disagree if
> >> that didn't convince you.
> >
> >
> > - --
> > Timothy Pearson
> > Raptor Engineering
> > +1 (415) 727-8645 (direct line)
> > +1 (512) 690-0200 (switchboard)
> > https://www.raptorengineering.com
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJaMWk6AAoJEK+E3vEXDOFbTnkH/30CN22Q0JG0bxxvG7NaRjUX
> > i4bsAVpdP+rbd9IlmMHDCPtYnmdoBWq81yXZx8iBAzTx5DJrU0lA0Kqr0RzIyNRx
> > pE4omRU2St342bQS5bf/UsFwT2WKR2vlE8u8NR4YiOXnJNySJ1gSQqzxB4uGwd7I
> > rcyMnScr4IKEgwiE3GA7HU4vHE2w66M6g0skhYQtquAm3ypajmwLUbFwsgiAp0l1
> > Azbt9pUFlp7McZTJusuRroWsDv1oOWQit3nH54i0yP6EajGWbZJ4+sAEQJSXVr9Q
> >