OSDev.org

The Place to Start for Operating System Developers
It is currently Sat Feb 24, 2018 6:04 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 13 posts ] 
Author Message
 Post subject: BIOS data area and SMM
PostPosted: Thu Dec 07, 2017 12:53 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 877
Location: Finland
linux/arch/x86/boot/compressed/head_32.S wrote:
Page 0 is deliberately kept safe, since System Management Mode code in laptops may need to access the BIOS data stored there. This is also useful for future device drivers that either access the BIOS via VM86 mode.


Does anyone know more about this? I thought that only the extended BIOS data may be used by SMM. I need to take this detail into account but it should not be a big deal. Tactically finding another reason to handle page 0 in a special way and solving the problem as a side effect. :)

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Thu Dec 07, 2017 6:42 am 
Offline
Member
Member
User avatar

Joined: Sun Feb 20, 2011 2:01 pm
Posts: 36
The intel manuals don't document this. As SMM is reliant on the firmware, I'd leave any memory not explicitly marked as reclaimable in the low MB untouched. In my OS, I do this anyway to allow real mode code execution, using the original IVT.

I'd consult this for bits of memory that are usable.
http://wiki.osdev.org/Memory_Map

_________________
Whoever said you can't do OS development on Windows?


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Thu Dec 07, 2017 12:40 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8248
Location: At his keyboard!
Hi,

Antti wrote:
linux/arch/x86/boot/compressed/head_32.S wrote:
Page 0 is deliberately kept safe, since System Management Mode code in laptops may need to access the BIOS data stored there. This is also useful for future device drivers that either access the BIOS via VM86 mode.


Does anyone know more about this? I thought that only the extended BIOS data may be used by SMM. I need to take this detail into account but it should not be a big deal. Tactically finding another reason to handle page 0 in a special way and solving the problem as a side effect. :)


As far as I know; SMM shouldn't touch page 0 and shouldn't assume page 0 has been left intact after the OS has ceased using the BIOS. I suspect that once upon a time a Linux developer found a computer with buggy firmware that doesn't comply with "should", and this is the result.

I'd also wonder if the (assumed) problem was caused by something using VM86 mode (OS doesn't cease using the BIOS) and/or the OS failing to disable "PS/2 emulation for USB devices" before using page 0. Note that there seems to be more problems than just page 0 (e.g. reports of suspend/resume and/or integrated graphics on sandy bridge CPUs corrupting the first 64 KiB of RAM), and to mitigate firmware/hardware bugs Linux developers seem to have built an entire system for disabling a configurable number of low memory pages and (optionally) periodically checking to see if RAM within that area was corrupted by BIOS.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Thu Dec 07, 2017 11:31 pm 
Offline
Member
Member
User avatar

Joined: Wed Jul 13, 2011 7:38 pm
Posts: 536
Location: Victoria, Canada
Brendan wrote:
I suspect that once upon a time a Linux developer found a computer with buggy firmware that doesn't comply with "should", and this is the result.


I suspect also that the comment dates back at least two if not two and a half decades, considering it implies System Management Mode is a primarily laptop thing, and originally it was only on the 386SL (an incredibly popular laptop CPU well into the early 1990s) and 486SL until being integrated into all 486DX and DX variants from late 1993 onwards.

_________________
In our business, a one in a million chance is next Tuesday.


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Fri Dec 08, 2017 1:26 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 877
Location: Finland
In the strictest sense, is using Long Mode safe at all? :)

The "PS/2 emulation for USB devices" seems to be a big problem for many reasons. I need to reconsider my boot infrastructure because it seems that using Long Mode too early may be unsafe. Unfortunately, this includes many hobby operating systems because I am almost sure that Long Mode is used before disabling the PS/2 emulation. Perhaps I need to disable it during the boot phases but doing so could be a good idea anyway. Later initialization phases could assume that emulation is disabled. Only real PS/2 hardware (checked if really available) may be supported until USB support is ready and this is a disadvantage, of course, but it could significantly speed up the development of the native USB support.

Kazinsal wrote:
I suspect also that the comment dates back at least two if not two and a half decades, considering it implies System Management Mode is a primarily laptop thing


At least Linux 1.0 had the same comment, so yes. At the time of its heyday, mainstream operating systems for PCs most likely keeped the BDA available at run time.

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Fri Dec 08, 2017 6:13 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 445
SMM is independent of long mode. Enabling long mode early is not problematic. Linux also enables long mode before looking at PCI.


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Fri Dec 08, 2017 6:38 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 877
Location: Finland
Korona wrote:
SMM is independent of long mode.


Unfortunately, this is questionable.

I'd really like to know the answer to this specific question: are the "PS/2 emulation" bugs waken up only if a CPU executing in long mode tries to read/write ports 0x60 or 0x64 which triggers the SMI handlers (but are interrupts involved in this scenario too)? There is a huge difference. I'm really worried about the "passive" state after entering long mode, i.e. a state in which "traditional" BIOS firmware is not in control (but obviously SMM still is) and the operating system / initialization code itself has not done anything yet. I'd understand the following scenario: emulation enabled, long mode, port read/write, and crash. If just being in long mode doing nothing crashes the computer... oh well.

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Fri Dec 08, 2017 3:42 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8248
Location: At his keyboard!
Hi,

Antti wrote:
Korona wrote:
SMM is independent of long mode.


Unfortunately, this is questionable.

I'd really like to know the answer to this specific question: are the "PS/2 emulation" bugs waken up only if a CPU executing in long mode tries to read/write ports 0x60 or 0x64 which triggers the SMI handlers (but are interrupts involved in this scenario too)?


For "PS/2 emulation for USB devices" I'd assume firmware may need to try to figure out which instruction caused the SMI (e.g. was it "in al,dx" or "in ax,dx" or ...?) so that it can emulate that instruction. This could involve doing a manual page table walk to find the instruction in physical memory, which implies that firmware's SMM code would need to support all the different paging modes and all of their features (large pages, "no-execute", ...); including things like "instruction split across page boundary" and including emulating page faults (e.g. "insb" writing to a not-present page).

Antti wrote:
There is a huge difference. I'm really worried about the "passive" state after entering long mode, i.e. a state in which "traditional" BIOS firmware is not in control (but obviously SMM still is) and the operating system / initialization code itself has not done anything yet.


Are you accessing the PS/2 chip's IO ports while in this passive state?

Antti wrote:
I'd understand the following scenario: emulation enabled, long mode, port read/write, and crash. If just being in long mode doing nothing crashes the computer... oh well.


Excluding "PS/2 emulation for USB devices" and "suspend/resume"; for everything else that SMM is used for (power management, ECC "scrubbing" in some computers, etc) the firmware's SMM code has no reason to care what the OS is doing (or which mode the CPU was in, etc).

Note that long mode was introduced in about 2000 (and I guess there may be "teething problems" in firmware involving "PS/2 emulation" and long mode for computers created at/near the introduction of long mode); and ACPI was introduced in about 1999 (and there are "teething problems" in firmware involving ACPI for computers created at/near the introduction of ACPI); and these time-frames are close enough to overlap (e.g. computers from around 2000 where firmware has problems with both long mode and ACPI). If an OS supports older 32-bit CPUs (e.g. and has a 32-bit kernel, etc) it should be relatively easy to force the OS to use 32-bit (e.g. using automated blacklist/whitelist approach and/or heuristics, and/or a manual user setting); and if the OS doesn't support older 32-bit CPUs then 64-bit computers from around 2000 are only slightly newer than computers the OS developer has already decided are too old to care about and it probably wouldn't matter much if the OS developer didn't support a few more old computers.

I should also mention that I'm relatively sceptical of some of the problems Linux sees - often it's too hard to know if they're just working around symptoms of Linux doing something incredibly silly (e.g. not disabling "PS/2 emulation" in USB controllers before starting PS/2 drivers). For this reason I'd be tempted to ignore some of the problems Linux seems to have with firmware (until/unless I have similar problems with my OS). ;)


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Sat Dec 09, 2017 12:50 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 877
Location: Finland
Brendan wrote:
I'd assume firmware may need to try to figure out which instruction caused the SMI
Brendan wrote:
could involve doing a manual page table walk


It is very reasonable to assume that doing all that is error-prone. Also, if we look at "SMRAM State-Save Area" format, maybe the old firmware was not very familiar with the new version ("AMD64") when it needed to read things from it for the emulation purposes. Or it simply wasn't tested very well because the whole architecture was new.

Brendan wrote:
Are you accessing the PS/2 chip's IO ports while in this passive state?


"No" :)

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Sat Dec 09, 2017 12:50 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 877
Location: Finland
Brendan wrote:
If an OS supports older 32-bit CPUs (e.g. and has a 32-bit kernel, etc) it should be relatively easy to force the OS to use 32-bit


To answer to a question "what are the minimum requirements?", I'd answer that "it depends on what features you want". A lot of work has been done so that the earliest PCs should be included. From the boot loader's perspective, there are three main categories (those may contain subcategories but the boot loader is not aware of them):

  • From "8086" to pre-Pentium. A 16-bit "toy thing" that communicates with the real OS via serial cable like a terminal but there are some native features also.
  • From "Pentium" onwards. Modern 32-bit kernel(s) but details are not available yet.
  • From "x86-64" onwards. Modern (BIOS/UEFI) 64-bit kernel(s) but details are not available yet.

The boot code chooses the branch and now I should investigate how to put higher threshold for selecting the "x86-64" category. What would be a good CPU feature flag for skipping all those early chips? That could work-around more problems than just this and I would accept that those computers were seen as 32-bit. Please note that I'm doing this for the pre-Pentium category too (all those are 16-bit). I'm going to fully concentrate on (relatively) modern OSDev so the "Pentium" is the minimum requirement in practice.

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Sat Dec 09, 2017 6:40 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 445
IIRC the BIOS emulates the keyboard by passing data to the "real" PS/2 controller (using commands 0xD2 and 0xD3). It does not emulate the whole PS/2 controller in SMM. It does not need to know the instruction that caused the read/write.

Antti wrote:
Korona wrote:
SMM is independent of long mode.


Unfortunately, this is questionable.

I'd really like to know the answer to this specific question: are the "PS/2 emulation" bugs waken up only if a CPU executing in long mode tries to read/write ports 0x60 or 0x64 which triggers the SMI handlers (but are interrupts involved in this scenario too)? There is a huge difference. I'm really worried about the "passive" state after entering long mode, i.e. a state in which "traditional" BIOS firmware is not in control (but obviously SMM still is) and the operating system / initialization code itself has not done anything yet. I'd understand the following scenario: emulation enabled, long mode, port read/write, and crash. If just being in long mode doing nothing crashes the computer... oh well.

Do you realize that SMI's disable long mode and re-enter real-mode? Did you ever encounter SMM crashing your code or do you have any evidence that it might happen? I have not ever seen something like this.


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Sat Dec 09, 2017 9:20 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 877
Location: Finland
Korona wrote:
Do you realize that SMI's disable long mode and re-enter real-mode?


Yes. That is the answer relevant in this context (ignoring possible terminology inaccuracies and the difference between observable behavior and implementation details).

Korona wrote:
Did you ever encounter SMM crashing your code or do you have any evidence that it might happen?


I did not encounter SMM crashing. I don't have proper hardware (early 64-bit systems) to do any tests and the only evidence I have is this.

Vojtech Pavlik wrote:
If AMD64 64-bit mode is enabled, again system crashes often happen, because the SMM BIOS isn't expecting the CPU to be in 64-bit mode


I fully agree that it might not be true, e.g. the crashes were a combination of different factors. However, I firmly believe that some kind of problems were real and the quote is authentic and I understood it correctly.

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: BIOS data area and SMM
PostPosted: Sat Dec 09, 2017 12:26 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8248
Location: At his keyboard!
Hi,

Antti wrote:
The boot code chooses the branch and now I should investigate how to put higher threshold for selecting the "x86-64" category. What would be a good CPU feature flag for skipping all those early chips? That could work-around more problems than just this and I would accept that those computers were seen as 32-bit. Please note that I'm doing this for the pre-Pentium category too (all those are 16-bit). I'm going to fully concentrate on (relatively) modern OSDev so the "Pentium" is the minimum requirement in practice.


For a higher threshold for selecting the "x86-64" category (to avoid using long mode on "more likely to be buggy" computers from near the introduction of long mode); I'd consider using the existence of CMPXCHG16b, PREFETCHW and LAHF/SAHF instructions. The reason for CMPXCHG16b is that it's highly useful for lock-free and block-free algorithms (e.g. atomically update a pair of pointers), and the reason for the others is that CMPXCHG16B alone doesn't create a high enough threshold and it matches the requirements for 64-bit Windows 8.1 and Windows 10.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group