Author Topic: native mainframe mini-clone  (Read 2118 times)

Rich Walsh

  • Sr. Member
  • ****
  • Posts: 414
  • Karma: +30/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: native mainframe mini-clone
« Reply #15 on: September 13, 2025, 01:15:54 am »
can I have a normal executable (.exe), running at the OS/2 fullscreen prompt, that has the privilege required to disable interrupts and switch from PM32 to LM64?

Can a Ring 3 executable execute a Ring 0 priveleged instruction that could blow up the entire system? Hell no!

Quote
If so, what do I need to do to get such privilege on OS/2?

You would need a device driver which operates at Ring 0.  In the UEFI version of ArcaOS, the bootloader stub which remains after the OS is running will switch to long-mode to read the machine's NVRAM variables, then will switch back. While doing so, all of OS/2 must stop because it is 100% *incompatible* with long-mode. Why? Because the kernel and device drivers are all 16-bit code, and the flag that signals "16-bit code" on an x86 signals "64-bit code" when long-mode is enabled.  You can have 16/32 code or 32/64 code but not 16/32/64.

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #16 on: September 13, 2025, 01:00:02 pm »
You would need a device driver which operates at Ring 0.
Ok, in that case, I guess I am after the minimum device driver that's sole duty is to switch from ring 3 to ring 0 - callable from any ordinary app.

That would be enough to prove the concept of allowing me to create my own mini-Win64 that purely uses memory above 4 GiB.

Note that I am only interested in executing non-buggy programs, so I don't mind OS/2 crashing the same way that MSDOS crashed if you run a buggy program.

I simply debug the application.

Running everything privileged has worked fine for me for decades. I'm not trying to make a commercial quality product. Fleshing that out is left as an exercise for the reader or whoever sees a commercial opportunity for something more robust.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 5570
  • Karma: +136/-1
    • View Profile
Re: native mainframe mini-clone
« Reply #17 on: September 13, 2025, 06:02:46 pm »
There's some sample drivers at http://hobbesarchive.com/?path=%2fpub%2fos2%2fdev%2fsamples%2fdrivers Perhaps the fastio driver, http://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/dev/samples/drivers/FastIO_A1-0.zip can be modified. From the blurb,
Code: [Select]
FastioA$ Device Driver for direct port I/O. Based on Holger Veits EDM/2 fastio driver. Modified for use with watcom. Includes watcom project files and example program. (FastIOA1.0.zip)

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #18 on: September 14, 2025, 05:47:22 am »
Perhaps the fastio driver
Thanks - looking at that, there is something I didn't think of.

It does a far call into the I/O driver, which gives an opportunity for the cs to change, and I'm guessing that while in the driver, it has a privileged cs, but on return to the caller, the original cs is restored to an unprivileged cs. ie it's not that easy to simply say "go privileged".

I guess I can modify the GDT table to make the original cs privileged though. Not sure if ds needs a change too.

Lars

  • Hero Member
  • *****
  • Posts: 1459
  • Karma: +73/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #19 on: September 14, 2025, 11:25:10 am »
You might want to have a look at:

https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/system/drivers/misc/SysCall_3-0.wpi

That is a package that I have written to run code in Ring 0.
It comes with full source code. Which would allow you to adapt/extend it to your needs.

The idea was to have an interfacing DLL to be used by an application. That DLL will return to the caller an entry point that will allow the caller to execute user functions in Ring 0.

It uses the syscall/sysret instructions as the fastest way to enter Ring 0.
« Last Edit: September 14, 2025, 11:26:52 am by Lars »

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #20 on: September 15, 2025, 06:59:48 am »
You might want to have a look at:

https://hobbesarchive.com/Home/Download?path=/Hobbes/pub/os2/system/drivers/misc/SysCall_3-0.wpi

That is a package that I have written to run code in Ring 0.
It comes with full source code. Which would allow you to adapt/extend it to your needs.

The idea was to have an interfacing DLL to be used by an application. That DLL will return to the caller an entry point that will allow the caller to execute user functions in Ring 0.

It uses the syscall/sysret instructions as the fastest way to enter Ring 0.

Looks exactly what I need - thanks!

There are some competing priorities for what I should do next though - a strategy for this being the most interesting at the moment:

https://gcc.gnu.org/pipermail/gcc/2025-September/246666.html

(I need a solution different from the x32 solution which I now know is 0x67 override)

Lars

  • Hero Member
  • *****
  • Posts: 1459
  • Karma: +73/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #21 on: September 15, 2025, 09:43:01 am »
Correction: it is sysenter/sysexit that is used and not syscall/sysret.

For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.

For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)
« Last Edit: September 15, 2025, 09:50:39 am by Lars »

kerravon

  • Jr. Member
  • **
  • Posts: 63
  • Karma: +2/-0
    • View Profile
Re: native mainframe mini-clone
« Reply #22 on: September 21, 2025, 09:45:53 am »
Correction: it is sysenter/sysexit that is used and not syscall/sysret.

For exactly this reason: only sysenter/sysexit are available in x32 for both, Intel and AMD. The interfacing DLL/the Syscall device driver makes no attempt whatsoever to switch from x32 to x64. Everything remains in x32 mode.

For syscall/sysret it is more complicated. I think for Intel it only works for x64 (long mode) (or was it AMD ? I cannot remember ...)

Hi Lars.

I'm not sure if you've used the wrong terminology or I'm just confused.

x32 is a target of gcc. I'm not very familiar with it, but I believe it uses x64 instructions, but 32-bit addresses. And it does the latter (as I just found out) by using 0x67 override (which isn't appropriate if you were really running in x86 mode).

So this is very different from x86, and that's why the different target exists. ie it isn't i386.

What you described above sounds like you are describing x86 (aka i386 aka 80386).