August 2017 - coreboot - mail.coreboot.org

Re: [coreboot] Disabling Intel ME 11 via undocumented mode
by Rene Shuster Aug. 29, 2017

Aug. 29, 2017

Wow. On Mon, Aug 28, 2017 at 12:08 PM, Matthias Gliwka <mg(a)cerebuild.com> wrote: > Some new development on disabling Intel ME 11: http://blog.ptsecurity. > com/2017/08/disabling-intel-me.html > > Kind regards, > Matthias Gliwka > > -- > coreboot mailing list: coreboot(a)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>

1 0

REPLY: INT 13H
by Zoran Stojsavljevic Aug. 28, 2017

Aug. 28, 2017

Hello Vincenzo, Since you replied only to me, I would like to write my reply also to the whole list, in order to draw some more experienced people with INT 13H knowledge. Explicitly, I do not know with 100% certainty if OSes direct via INT 13H some data to be written to the USB and/or SATA. It is entirely possible, either by maliciously created part of the OS (especially Closed Source, such as WIN), either by malicious virus somehow inserted. Since I know more about INT10H and INT 15H, I googled to find some data about INT 13H, to get familiar And I found the following link: https://en/wikipedia.org/wiki/INT_13H The immediate what I thought about is, since I know that these INT are, after all, part of Lecacy BIOSes, to see if UEFI BIOS can somehow resolve this situation (since UEFI BIOSes suppose NOT to use these INT, since these are legacy mechanisms after all). But I found the following reading the pointer: *Modern computers come with both BIOS int 0x13 and UEFI <https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface> functionality that provides the same services and more. Typically, UEFI drivers generally use LBA <https://en.wikipedia.org/wiki/Logical_block_addressing>-addressing instead of CHS.* *LBA -> Logical Block Addressing* Now, in the conjunction with this explanation, you can read the following: https://en.wikipedia.org/wiki/Logical_block_addressing pointer. For me, to avoid legacy INTs I'll use 64b UEFI BIOS (all 64b BIOSes are UEFI BIOSes, but vice versa is NOT true - there are 32b UEFI BIOSes also), with the modern INTEL/AMD/x86 CPUs and SoCs, which somehow guarantees that such mechanisms are NOT present in the FW anymore. > If i'm not wronging it seems to me that the INTEL architecture (x86 based) is not a good choise to solve this question. BIOSes are primary and ONLY created to serve x86 and x86_64/AMD64 architectures (there are beasts on their own, with UEFI ones more than 2 million lines of code). I guess, there are NO such things as BIOSes for ARM, PPC, MIPS and similar architectures. There are boot loaders serving as minimal BIOSes, such as Coreboot and U-Boot. They usually do NOT have HDD/SDD drivers included. For the further info, maybe Black Hat members, as well as GOOGLE designers, usual members of this Coreboot list can help you (and also extend my knowledge) to understand more about your questions. > And excellent is also the YOKTO project you are devoting your time. Embedded linux is a very big opportunity. I am not going to deepen YOCTO story. But whoever would like to understand YOCTO, I warmly suggest this pointer for the beginners: www.aosabook.org/en/yocto.html NOT the official YOCTO Project web pointer, since it is really lot of stuff in not a systematized manner (usually top engineers are writing horrible documents, and this always repeats as pattern recognition during decades) and tough stuff for immediate understanding. It will introduce more confusion and dead brain spirals... ;-) Zoran _______ Dear Zoran, thanks very much for your reply. Excellent. And excellent is also the YOKTO project you are devoting your time. Embedded linux is a very big opportunity. Sorry if I take advantage of it to pose a question that is not easy to solve. I've just posed this question to coreboot list, but probably the solution is in a linux embedded distribution that avoid the INTEL architecture and the related problems about real/protected/long .... modes. Briefly the question: I' intersting into know if BIOS/UEFI can implicitly (that is without an explicit command from a user) write to a suspect drive attached to a computer (in particular USB stick and SATA hard disk). It seems that there are edge cases for which this happens. If i have well understood, it seems that there are cases for which the O.S. can call BIOS'es interrupts, like the INT 13 H and execute writing operations to a USB/SATA drive. If this is true, is the possibility to deactivate this action at boot level and avoid writing operations, without an explicit command from a user, to a USB/SATA drive attached to a computer ? If i'm not wronging it seems to me that the INTEL architecture (x86 based) is not a good choise to solve this question. Thanks very much. Best Regards. Vincenzo

1 0

Re: [coreboot] About Paging, Realmode and what is going on
by Julius Werner Aug. 28, 2017

Aug. 28, 2017

> > Unfortunately, this picture represents ONLY 32bit transitions, there are > two more modes for 64 bit, not shown here. If I find the representative, > I'll post it on the forum (@ list). > The box labeled "IA-32e Mode" is 64-bit mode (in their infinite wisdom, Intel chose a name containing the number 32 for their copy of amd64 mode). I think the other mode you're referring to (32-bit compatibility mode for 64-bit systems) is technically considered a "sub-mode" of that, so that's probably why they only have one box to represent both. Compatibility mode is controlled by a bit in the CS descriptor if I recall correctly.

1 0

Disabling Intel ME 11 via undocumented mode
by Matthias Gliwka Aug. 28, 2017

Aug. 28, 2017

Some new development on disabling Intel ME 11: http://blog.ptsecurity.com/2017/08/disabling-intel-me.html Kind regards, Matthias Gliwka

1 0

Re: [coreboot] About Paging, Realmode and what is going on
by Zoran Stojsavljevic Aug. 27, 2017

Aug. 27, 2017

Hello Vincenzo, The part of the picture you see is a part of some document, which is of restricted nature. But not to disappoint you, I found the same representative (even better picture) on the Open Source/Open Net. https://www.researchgate.net/profile/Nikola_Zlatanov3/publication/295010710… Unfortunately, this picture represents ONLY 32bit transitions, there are two more modes for 64 bit, not shown here. If I find the representative, I'll post it on the forum (@ list). [image: Inline image 1] Please, do note that you could download (free of charge) the document called: INTEL 64 and IA32 Architecture SW Development Manual (Three Volumes, it is around 20MB of size, > 3000 pages): https://software.intel.com/en-us/articles/intel-sdm Here, I need to correct some remarks in my original text. CR0 is the register: https://en.wikipedia.org/wiki/Control_register CR0[edit <https://en.wikipedia.org/w/index.php?title=Control_register&action=edit&sec…> ] The CR0 register is 32 bits long on the 386 <https://en.wikipedia.org/wiki/Intel_80386> and higher processors. On x86-64 <https://en.wikipedia.org/wiki/X86-64> processors in long mode <https://en.wikipedia.org/wiki/Long_mode>, it (and the other control registers) is 64 bits long. CR0 has various control flags that modify the basic operation of the processor. BitNameFull NameDescription 0 PE Protected Mode Enable If 1, system is in protected mode <https://en.wikipedia.org/wiki/Protected_mode>, else system is in real mode <https://en.wikipedia.org/wiki/Real_mode> 1 MP Monitor co-processor Controls interaction of WAIT/FWAIT instructions with TS flag in CR0 2 EM Emulation If set, no x87 floating point unit <https://en.wikipedia.org/wiki/Floating_point_unit> present, if clear, x87 FPU present 3 TS Task switched Allows saving x87 task context upon a task switch only after x87 instruction used 4 ET Extension type On the 386, it allowed to specify whether the external math coprocessor was an 80287 <https://en.wikipedia.org/wiki/80287> or 80387 <https://en.wikipedia.org/wiki/80387> 5 NE Numeric error Enable internal x87 <https://en.wikipedia.org/wiki/X87> floating point error reporting when set, else enables PC style x87 error detection 16 WP Write protect When set, the CPU can't write to read-only pages when privilege level is 0 18 AM Alignment mask Alignment check enabled if AM set, AC flag (in EFLAGS <https://en.wikipedia.org/wiki/FLAGS_register_(computing)> register) set, and privilege level is 3 29 NW Not-write through Globally enables/disable write-through caching 30 CD Cache <https://en.wikipedia.org/wiki/CPU_cache> disable Globally enables/disable the memory cache 31 PG Paging If 1, enable paging and use the CR3 register, else disable paging I'm a bit behind on this forum, since I completely (at this point in time) devoted my time to YOCTO and ARM i.MX6 (I have interesting projects with it, and YOCTO is the special beast of its own kind). ;-) I hope this helps, Zoran On Mon, Aug 28, 2017 at 12:13 AM, ingegneriaforense(a)alice.it < ingegneriaforense(a)alice.it> wrote: > Dear Zoran, > > can you tell me please where you found the picture (attached) you have > provided in this email that show how x86 operates ? Could be interesting > for me take a look at the full image, probably more exaustive and usefull > to better understand your excellent comment regarding the Real mode. > In particular i'm studying the coreboot code to better understand in which > cases backward transitions are possible, as the picture shows. > > Thanks in advance. > > Best Regards. > > vincenzo > > Forensic Consultant > Tribunale di Lecce > > Studio: Strada di Garibaldi - Contrada Paradisi > 73010 Lequile (LE) > > cell: 339.7968555 <(339)%20796-8555> > skype: vincenzo.di_salvo > > > ----Messaggio originale---- > Da: zoran.stojsavljevic(a)gmail.com > Data: 2-ago-2017 18.20 > A: "Philipp Stanner"<stanner(a)posteo.de> > Cc: "coreboot"<coreboot(a)coreboot.org> > Ogg: Re: [coreboot] About Paging, Realmode and what is going on > > Hello Philipp, > > There are lot of confusion you have created with your naming convention... > So we need here to "Divide and Concur", since this thread really remains me > of Spaghetti Bologneze. > > Here is the partial picture how x86 operates: > > [image: Inline image 1] > > So you see here three modes, you are talking about. Every INTEL CPU starts > in Real Mode, and then switches to the protected mode. > > So, you have some legacy you MUST maintain for the backward HW > compatibility. > > As Patrick Georgi very correctly mentioned, let me recap what he said, > with my additions, to be much clearer with the picture I have provided. > > [1] Every x86 CPU starts in Real Mode, for the legacy reasons. the Lecacy > mode must be maintained (Real Mode replicates with the VERY first PC XT far > back to 1980, with some first 1MB memory mapping improvements). The > BackWard HW compatibility was maintained for years, and it went too far > that it can be changed over the nite. I am not going to explain why: too > long it takes. > > [2] CB operates in Protected Mode, WITHOUT Paging/Virtual Mode switched > on, since this mode is ONLY used with MMU (which is HUGE HW extention to > create Virtual use of the Memory), which is managed by true OS (like Linux, > WIN, QNX, MAC OS, VMS, you name it). CoreBoot, U-Boot, BIOS boot-loaders: > they all operate from the flat/Protected Mode, and Patrick explained this > very well/excellent. In addition, I must say that this first 4GB MUST be > assigned to the benefit of the underlying HW (PCIe, GFX, SMM mode, Flash > region, ACPI tables, and so on). This assignment is done strictly > Physically, with the CPU HW helping for some regions for remapping them > (since CPU does see what CB does for it as Physical memory assignment, but > MMU [when OS runs] sees it quite differently)! > > [3] As for payloads (also working in Protected Mode), there are some which > will make their own definitions of the memory, some/most which will work > deeper (as SeaBIOS, for example) on the CB Physical memory definition. As > well as these payloads (depending upon what the usage is) will add more > drivers for the certain devices, CB did not add in the first place. For > example, SeaBIOS adds IDE (maybe even AHCI, not sure) driver to this set. > Some people can define their own payloads with the set of specific drivers, > depending upon what the HW platform is intended for. > > [4] Once the OS boot loader takes over (Like GRUB), it'll start OS, which > will switch from the Protected to the Virtual Mode (using MMU), Then paging > will take places, and each process will have its own set of tables, and its > own initial value for CR3 (when process context switches). I warmly suggest > to you to inspect (bit by bit) CR1 register, since this one is > crucial/essential for introducing these modes. > > I really hope this helps (I've tried to develop some systematic approach > to the topic). The booting process will go to stages, and once CPU abandons > Real Mode, it'll (generally) not return to it (only in some special cases > such as SMM Mode). Once It abandons Protected Mode, it'll stay in Virtual > Mode, and so on. But backward transitions are possible, as you see from the > picture. > > Zoran > > On Mon, Jul 31, 2017 at 10:52 AM, Philipp Stanner <stanner(a)posteo.de> > wrote: > >> Dear folks and techpriests, >> >> the more I want to contribute and learn about low-level-code the less I >> understand, it seems. >> >> >> 1. cb switches the CPU immediately to Protected Mode, yet Payloads >> like seaBIOS work in Real Mode. Does coreboot switch the CPU always back to >> RM before jumping to the payload? >> 2. When CB switches to PM - who generates and administrates the Page >> Tables and where? >> 3. Gustavo Duarte writes >> <http://duartes.org/gustavo/blog/post/how-computers-boot-up/> that >> GRUB switches from protected mode to real mode and vice versa all the time >> to address >1MiB of RAM and also use the BIOS-calls. If this is true using >> GRUB as payload would not work, as GRUB needs to call the non-existent >> BIOS, right? >> 4. Once CB is in PM it can't access physical addresses anymore? It >> doesn't need to, too? >> 5. PM means RAM-access is only possible through virtual addresses >> which are translated by the MMU using the Page Tables. This question is >> similar to [2.]: If coreboot generates the Page Tables and the payload >> would start in PM as well (is this even possible? At least the Linux-Kernel >> has entry points for RM and PM) this would mean the payload needs to use >> the Page Tables generated by CB. That wouldn't be a problem as they're >> linked in the register CR3 anyways? >> >> And an unimportant bonus question: >> >> - Why does every modern CPU still start in RM? I do get the >> compatibility problem, but on the other hand: Do you need it for anything >> beside booting MS-DOS on your Ryzen? Is it really impossible for AMD and >> Intel to create a new CPU-generation with the x86-instruction set without >> RM, 16-bit-registers and 20-bit-mode registers like CS, SS etc. No modern >> OS uses bios calls. No CPU is ever switched to RM again after booting up. >> They should get rid of this old stuff. >> >> Would be cool if someone could put this in its true light. >> >> Thanks, >> >> Philipp >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > > > >

1 0

Re: [coreboot] was this a UEFI update maybe?
by Gregg Levine Aug. 25, 2017

Aug. 25, 2017

Hello! I'm not surprised. However last year's problem is just, well, disturbing. It concerns not being able to access the BBC Internet Player. Hopefully that firm's new phones won't self destruct.... ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again." On Fri, Aug 25, 2017 at 1:32 PM, Vadim Bendebury <vbendeb(a)chromium.org> wrote: > Wow, this is gross, Samsung screwed up again. At least the TVs don't catch > fire :) > > As a side note I am pretty sure it would have been no problem returning > those TVs here in the states, gotta love consumer protection here. > > -vb > > On Fri, Aug 25, 2017 at 10:16 AM, ron minnich <rminnich(a)gmail.com> wrote: >> >> >> https://www.theguardian.com/technology/2017/aug/24/samsung-tv-buyers-furiou… >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] How is depreciating 95% of coreboot boards worth it for such minor improvements?
by Jonathan Neuschäfer Aug. 25, 2017

Aug. 25, 2017

On Wed, Aug 23, 2017 at 09:44:30PM +0000, ron minnich wrote: > On Wed, Aug 23, 2017 at 2:31 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > > > Ah I see thanks for explaining. > > > > I had read all the AGESA boards were going to be removed, besides the > > asus D8/D16 those are the last and best owner controlled x86 boards. > > Is there a current list of boards to be removed? > > > > > I don't know, but I have brought this up from time to time. I believe that > if they've not got a maintainer for more than a year it is time for them to > be removed. I think we should also take board_status[1] into account here. If a board has recently (for some value of "recently") been successfully booted into linux, the support can't be completely broken. > I would like to have a list of all boards ever supported, along > with the last coreboot revision where they can be found. There is such a page in the wiki[2]. It's probably incomplete. It doesn't list commits, either. We could migrate it into git, maybe, and make it a requirement that every commit that deletes a board updates the list. Jonathan [1]: https://www.coreboot.org/Supported_Motherboards [2]: https://www.coreboot.org/Graveyard

4 4

Re: [coreboot] was this a UEFI update maybe?
by Vadim Bendebury Aug. 25, 2017

Aug. 25, 2017

Wow, this is gross, Samsung screwed up again. At least the TVs don't catch fire :) As a side note I am pretty sure it would have been no problem returning those TVs here in the states, gotta love consumer protection here. -vb On Fri, Aug 25, 2017 at 10:16 AM, ron minnich <rminnich(a)gmail.com> wrote: > https://www.theguardian.com/technology/2017/aug/24/ > samsung-tv-buyers-furious-after-software-update-leaves-sets-unusable > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

was this a UEFI update maybe?
by ron minnich Aug. 25, 2017

Aug. 25, 2017

https://www.theguardian.com/technology/2017/aug/24/samsung-tv-buyers-furiou…

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com Aug. 25, 2017

Aug. 25, 2017

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1379932: Null pointer dereferences (FORWARD_NULL) /src/northbridge/amd/agesa/state_machine.c: 299 in agesa_execute_state() ________________________________________________________________________________________________________ *** CID 1379932: Null pointer dereferences (FORWARD_NULL) /src/northbridge/amd/agesa/state_machine.c: 299 in agesa_execute_state() 293 294 status = amd_create_struct(&aip, func, buf, len); 295 ASSERT(status == AGESA_SUCCESS); 296 297 /* Must call the function buffer was allocated for.*/ 298 AMD_CONFIG_PARAMS *StdHeader = aip.NewStructPtr; >>> CID 1379932: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "StdHeader". 299 ASSERT(StdHeader->Func == func); 300 301 if (ENV_ROMSTAGE) 302 final = romstage_dispatch(cb, func, StdHeader); 303 304 if (ENV_RAMSTAGE) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0