any BIOS standard(s) for calling to SMM ?

[Czernobyl]

Is there a standard, or quasi-standard, among BIOSes, for using the (chipset dependent) SMI-command-port to control motherboard and/or APM related functions ?
Asking just about BIOS, not OS/ACPI stuff.

Or would the functions be proprietary, varying by BIOs brand, even motherboard models ?

Would appreciate pointers to one or more online accessible document(s), if possible. TIA. No flames, please !

[Combuster]

As many other threads will have told you, there's no generic way to gain control over SMM, while it is a Bad Idea (tm) to try, as you'll be tampering with the computer's failsafes.

If what you really want is access to the features, implement ACPI support instead.

[Brendan]

Hi,

Is there a standard, or quasi-standard, among BIOSes, for using the (chipset dependent) SMI-command-port to control motherboard and/or APM related functions ?
Asking just about BIOS, not OS/ACPI stuff.

It's "varying by firmware" - a firmware update could change which values the firmware's SMM code uses for what.

Also note that an OS can find out which values are used for various things (enable/disable "ACPI mode", enter S4, etc) in an easy/standard way (from fields in ACPI's FADT); and that there's no reason for the firmware to support any other values, which would imply that there probably aren't any commands that an OS can't easily find out about.


Cheers,

Brendan

[Czernobyl]

In summary, as I feared, no BIOS standards (outside of ACPI, which imho is utter nonsene) - even none private to AMI, Award, Phienix... and the likes ? - Thanks to both of you!

@Combuster : it's not like I had problems gaining access to and customising SMM code on _my own_ rigs, using SMIs in some non malicious, sometimes useful (°) , (and somewhat creative) ways. Lacking a BIOS standard however impedes any generalisation - on the bright side, it may also prevent the spreading of SMM based malware.

° example 1: some extremely & unpredictably long, typically running for days or even weeks, iterative number theoretic calculations running entirely on integer registers, _including_ r/e/SP, so, no stack possible, few if any memory accesses (even cache accesses are slooow...) - but wouldn't it be convenient to still be able to interrupt the calculation, look at its state, and restart it afterwards? _No stack_, hence no interrupts possible (besides taking time away from the main problem, taking interrupts would pollute the cache, hence take even more time). Of course polling of e.g. the keyboard ports is out of the question. SMI, by pressing a button or (on my SiS chipsets) a hotkey, solves the problem elegantly.

° Another example of (non OS) utility of SMIs : to easily make "flashrom" work on boards where the (e.g. Intel) chipset & BIOS would normally trap and reject attempts at accessing the flash w/o knowing "secret" handshakes, including GPIOs and the like, which are difficult to "reverse engineer". Much easier is to hack a quick and dirty RSM instruction in place of the SMI handler's first instruction (depending on what the mobo uses SMIs for, it might be slightly more complicated, especially on portables, but still easier than tracking the GPIOs :=)

- OK, this is not OS works and I should apologise here. I sincerely hope I have hinted there is more to SMIs than power and mobo management, and maybe a few simple ideas some ppl may find interesting - even for OS works ?

[Brendan]

Hi,

° example 1: some extremely & unpredictably long, typically running for days or even weeks, iterative number theoretic calculations running entirely on integer registers, _including_ r/e/SP, so, no stack possible, few if any memory accesses (even cache accesses are slooow...) - but wouldn't it be convenient to still be able to interrupt the calculation, look at its state, and restart it afterwards? _No stack_, hence no interrupts possible (besides taking time away from the main problem, taking interrupts would pollute the cache, hence take even more time). Of course polling of e.g. the keyboard ports is out of the question. SMI, by pressing a button or (on my SiS chipsets) a hotkey, solves the problem elegantly.

Um. If you're worried about things like IRQs messing up cache contents (which is bizarre to begin with); put your IRQ handler and its stack in an "uncached" area (either by messing with MTTRs or the "cache disable" flag in page tables). Not only would this be far more portable, it'd be easier and also faster (because the CPU has to save/load a lot of additional state when entering/leaving SMM, switch CPU modes, etc).

° Another example of (non OS) utility of SMIs : to easily make "flashrom" work on boards where the (e.g. Intel) chipset & BIOS would normally trap and reject attempts at accessing the flash w/o knowing "secret" handshakes, including GPIOs and the like, which are difficult to "reverse engineer". Much easier is to hack a quick and dirty RSM instruction in place of the SMI handler's first instruction (depending on what the mobo uses SMIs for, it might be slightly more complicated, especially on portables, but still easier than tracking the GPIOs :=)

Instead of spending ages to find a way to accidentally brick your motherboard before throwing it in the trash; why not just throw the motherboard in the trash without wasting that time?


Cheers,

Brendan

[Octocontrabass]

_No stack_, hence no interrupts possible

Run your code in user mode. You can give the kernel its own stack pointer, and it will be unaffected by whatever the user-mode program is doing. If disabling interrupts is so important, you can use NMI for the interrupt instead; server motherboards usually have a connection for a button you can push to send a NMI to the CPU. (But before you do all of that, you should probably try rewriting your algorithm to use SIMD instructions/registers.)

[Czernobyl]

If disabling interrupts is so important, you can use NMI for the interrupt instead; server motherboards usually have a connection for a button you can push to send a NMI to the CPU.

I have been known to hack my own NMI button off the contacts present on (old ISA) slots. But in the present case, NMI would not help - because ESP is in constant use in the calculations and cannot hold a stack pointer. No register free. Admittedly it is an extreme case, where the technique - using SMIs to interrupt a computation, asynchonously - is the only possible avenue.

(But before you do all of that, you should probably try rewriting your algorithm to use SIMD instructions/registers.)

Not suitable for fast long integer arithmetic. I do use some MMX or even SSE regs as temporaries, when the need arise.

[Octocontrabass]

But in the present case, NMI would not help - because ESP is in constant use in the calculations and cannot hold a stack pointer.

Run your code in user mode. You can give the kernel its own stack pointer, and it will be unaffected by whatever the user-mode program is doing.

[Czernobyl]

° example 1: theoretic calculations running entirely on integer registers, _including_ r/e/SP, so, no stack possible

If you're worried about things like IRQs messing up cache contents (which is bizarre to begin with); put your IRQ handler and its stack in an "uncached" area (either by messing with MTTRs or the "cache disable" flag in page tables). Not only would this be far more portable, it'd be easier and also faster

Ack'ed. But that would not be possible in my (very real) set of programs, because ALL 8 (on X32) general registers are in constant use for arithmetic, including ESP. The programs MUST disable interrupts (including NMI).

° Another example of (non OS) utility of SMIs : to easily make "flashrom" work on boards where the (e.g. Intel) chipset & BIOS would normally trap and reject attempts at accessing the flash (...) Much easier is to hack a quick and dirty RSM instruction in place of the SMI handler...

Instead of spending ages to find a way to accidentally brick your motherboard before throwing it in the trash; why not just throw the motherboard in the trash without wasting that time?

It's you PoV as a hobby-OS dev; actually, the Flashrom/Coreboot developers were very interested in my method when hinted on their mailing list. I had to point to them that unfortunately, it has to be hand tailored for each chipset+mobo combo :=) So, yes, I am aware these techniques are not universally applicable. Still who sayz I mustn't do it if I can ?

Nor does it take "ages", last time doing that hack I recall it took half an hour to "unlock" a DELL mobo which I had not seen before, most of which is browsing thru the chipset docs - provided one can find them - often the real obstacle, but I am sure _you_ know this very well !


Cheers !

[Czernobyl]

@ Octocontrabass

You're right about using dual privilege PM. I'm not sure though that setting up a custom protected mode "OS" or simply a "supervisor", with all the necessary machinery, just for the puprose of running a single, mostly uninterruptible, task, is a simpler solution than my admittedly bizarre solution, running in plain real mode augmented with a custom handler for SMI that processes just the one (or 2, actually) SMI events I'm interested in. All other SMI sources I disable preliminarily.

Cheers !

[Octocontrabass]

I can't say for sure that it's simpler if you're only running it on one specific motherboard, but if you want to be able to run it on any x86-based PC, it is definitely the simplest.

I wouldn't be surprised if it also makes your calculations run faster; modern x86 CPUs are not optimized for performance in real mode. (And if you go to 64-bit mode, you have twice as many GPRs with zero additional overhead.)

[Czernobyl]

I wouldn't be surprised if it also makes your calculations run faster; modern x86 CPUs are not optimized for performance in real mode.

There was some partial truth to that myth for the (edit:)386s and, perhaps, (edit end) original Intel 486s. It was not "real" vs "protected" so much as "16-bit" versus "32-bit".
Later processors, including 486-DX2 / DX4 flavors and certainly Pentia, have corrected the bias, in my experience.

(And if you go to 64-bit mode, you have twice as many GPRs with zero additional overhead.)

I'm still not sure I'll ever buy a 64-bit capable, Intel compatible system. If I succumb finally, it'll be more for the accompanying HW virtualisation capabilities than for 64-bit mode itself : though you're very right, more and longer GP registers would offer tremendous advancement possibilities for my number theoretic programs (OTOH, it would not be fun if it were easy).

[Brendan]

Hi,

° example 1: theoretic calculations running entirely on integer registers, _including_ r/e/SP, so, no stack possible

If you're worried about things like IRQs messing up cache contents (which is bizarre to begin with); put your IRQ handler and its stack in an "uncached" area (either by messing with MTTRs or the "cache disable" flag in page tables). Not only would this be far more portable, it'd be easier and also faster

Ack'ed. But that would not be possible in my (very real) set of programs, because ALL 8 (on X32) general registers are in constant use for arithmetic, including ESP. The programs MUST disable interrupts (including NMI).

So you "spill" some variables (e.g. the 2 least frequently used variables) onto the stack. 80x86 is exceptionally well optimised for this (fast L1 caches, register renaming, out of order execution, etc); and I wouldn't be surprised if it made no performance difference. You can also use privilege levels (already mentioned by Octocontrabass); or hardware task switching ("task gates" for interrupt handlers).

° Another example of (non OS) utility of SMIs : to easily make "flashrom" work on boards where the (e.g. Intel) chipset & BIOS would normally trap and reject attempts at accessing the flash (...) Much easier is to hack a quick and dirty RSM instruction in place of the SMI handler...

Instead of spending ages to find a way to accidentally brick your motherboard before throwing it in the trash; why not just throw the motherboard in the trash without wasting that time?

It's you PoV as a hobby-OS dev; actually, the Flashrom/Coreboot developers were very interested in my method when hinted on their mailing list. I had to point to them that unfortunately, it has to be hand tailored for each chipset+mobo combo :=) So, yes, I am aware these techniques are not universally applicable. Still who sayz I mustn't do it if I can ?

I'm not saying you can't; but I am saying that the only practical use for it that I can think of is malicious. For people like (e.g.) Coreboot developers, getting their code into firmware is the least of their problems (they really do need full specs and/or manufacturer support).


Cheers,

Brendan

[Czernobyl]

So you "spill" some variables (e.g. the 2 least frequently used variables) onto the stack. 80x86 is exceptionally well optimised for this (fast L1 caches, register renaming, out of order execution, etc); and I wouldn't be surprised if it made no performance difference.

All you say is true for "ordinary" programs, but even push/pop to/from the fast L1 cache has several cycles of penalty (versus direct register access that cost virtually nothing). It does make a huge difference - that add to hours after trillions of operations ! - in my pure computing tasks (one of which is Collatz-like iterations on 7x32=224 bit-long unsigned integers.) I did lots experimenting, with timing in pure optimised assembler, believe me.

Using privilege levels or HW task switching would be similar, only much worse :=)

I'm not saying you can't; but I am saying that the only practical use for it that I can think of is malicious. For people like (e.g.) Coreboot developers, getting their code into firmware is the least of their problems (they really do need full specs and/or manufacturer support).

Well, we hobbyists like to have our "special" ways, don't we ?
I agree most of the cases for (ab)use of SMM is malicious not excluding "law and order" applications. SMM should not have existed in the first place, the design and implementations thereof have been appalling from its inception... but since it's here to stay, better know your enemy in depth and play with the Devil is one way to know to avoid his traps.

[Combuster]

Using privilege levels or HW task switching would be similar, only much worse :=)

Considering SMI doesn't care which CPU mode to return to, do you have an actual experiment saying that running the same code in ring 3 protected mode is slower than running it in real mode? Do you also have an experiment showing that empty SMI interrupt handlers are faster than than protected mode interrupts? The way you wrote it shows it's merely an expectation. The key thing is that running in protected mode makes 32-bit instructions shorter and you do seem to use that particular register width.

On another note, it's also rather amusing that you're trying to do very lengthy calculations, on old x86 machines, and then hack those machines for speed boosts while you'd be off much faster by actually getting yourself a modern multi-core with 64-bit support. And if it's SMM you're trying to defile on purpose, why not get an FPGA while you're at it, so you can do many of the key instructions in one clock cycle instead of fighting register widths. All in all, it sounds like this whole SMM thing is a challenge to yourself, and you're after said challenge rather than the goal of the actual computation.