3 ms·

11 and Server)

42 points by walterbell 1y ago

Surac 1y ago
i do not see exactly the point in this empty table
- ryao 1y ago
  The table is not empty. You need to pick the windows versions to show since the table would be so huge if it showed all of them that they are hidden by default. Click “show” in the table head.
- senectus1 1y ago
  click on the "show" at the headers...
ryao 1y ago
I wonder how the DRM used in some video games that calls Windows system calls directly handles these changes. We know that some of it uses windows system calls directly because both Linux and Wine had to be patched to support it: https://docs.kernel.org/admin-guide/syscall-user-dispatch.html https://docs.kernel.org/admin-guide/syscall-user-dispatch.ht... If I recall correctly, Jurassic World Evolution’s DRM is one of those that needed this to work.
- e4m2 1y ago
  There's a million and one ways to do it, here's just some of the ones I remember: - https://www.mdsec.co.uk/2022/04/resolving-system-service-numbers-using-the-exception-directory https://www.mdsec.co.uk/2022/04/resolving-system-service-num... - https://klezvirus.github.io/RedTeaming/AV_Evasion/NoSysWhisper https://klezvirus.github.io/RedTeaming/AV_Evasion/NoSysWhisp... - https://whiteknightlabs.com/2024/07/31/layeredsyscall-abusing-veh-to-bypass-edrs https://whiteknightlabs.com/2024/07/31/layeredsyscall-abusin... Though I'm not sure which of these techniques, if any, would be most favored by a game DRM as I've never looked into it.
cies 1y ago
I count 506 on the Win list. 17 are no longer in use for recent version. So 489. And 467 on the Linux list https://filippo.io/linux-syscall-table https://filippo.io/linux-syscall-table. Ballpark the same number.
- JdeBP 1y ago
  It's a fairly meaningless number. Some operating systems have massive fan-in and fan-out on what is internally one single system call crossing the shell/kernel divide. Witness how much is done by sysctl() on the BSDs, for example. Whereas others will be more 1-to-1. Then there's the fact that the Native API for Windows NT is structurally very different to the Linux API (as they are both different from, say, XNU). It's basically entirely coincidental that the numbers are even close, and there are no general conclusions that one can draw from such statistics. Except, perhaps, a general but rather facile conclusion that these operating systems aren't running on 8-bit processor architectures. (-:
  - dooglius 1y ago
    I recall discussion (can't find now) that performance would be impacted for Linux if a syscall table lookup had to spill to a second page. That gives a limit of 512 64-bit pointers for syscalls we want to be high-performance, which may drive both OS's to start limiting new syscalls as they get close. I don't know if there's more to this claim than just concern about an extra TLB entry though.
trzeci 1y ago
Dragon Sector's doing good!
mike_hearn 1y ago
The interesting thing about this is that some syscalls are versioned, even though the syscall interface is internal and private. There's NtLoadKey, NtLoadKey2, NtLoadKey3 and even NtLoadKeyEx. This kind of versioning on public APIs, I understand, but syscalls are only meant to be invoked by ntdll. Why do they need more than one?
- meibo 1y ago
  I can't tell you if that is actually the case here but most private Win32 API is actually public API since so many things are using it anyways. They never drew the line there and a lot of people go "well, they never changed this in the past, why would they now".
  - JdeBP 1y ago
    This is not the Win32 API, and Raymond Chen and others at Microsoft very much did draw a line when it came to people using the Native API of Windows NT.
    - fredoralive 1y ago
      Some third party software like antivirus (and kernel mode drivers?) does use the native API, so they probably want to avoid gratuitously breaking things even at the NTDLL level (although as this table shows, making raw syscalls is something they'll break).
      - JdeBP 1y ago
        Drivers are a very different kettle of fish, and don't really involve NTDLL.DLL at all. They don't have to involve a full syscall transition, for starters, and there is a whole flavour of the Native API that doesn't. (I'm glossing over the details a bit. Go and read about Zw versus Nt in any good device driver book.) Stability of the Native API per se isn't really a big concern for drivers, not least because Microsoft invented other APIs for drivers, such as the one for graphics drivers that made drivers so loosely coupled to other things that it let the entire graphics subsystem be moved into the kernel in Windows NT 4. And the reliance of antivirus softwares on the Native API, and thus the need for stability, is somewhat overblown, not least because the Native API is far too high level a layer for antivirus softwares to trust. The flashy GUI bits might as well be just written in ordinary Win32 et al., and the other bits are busy being … well … essentially rootkits. (-:
uncircle 1y ago
I was wondering how the syscall mechanism works on Windows compared to Linux, and I found this delightful article: https://alice.climent-pommeret.red/posts/a-syscall-journey-in-the-windows-kernel/ https://alice.climent-pommeret.red/posts/a-syscall-journey-i... EDIT: also, wondering why the above article says SetMenu requires a syscall, which is not mentioned in OP, I found this: http://www.fengyuan.com/article/win32ksyscall.html http://www.fengyuan.com/article/win32ksyscall.html - looks like many GUI operations on Windows NT/2000 were implemented in kernel. That can't have been very good for performance to constantly context-switch to draw a window, no?
- fredoralive 1y ago
  Moving bits of GDI and USER into the kernel was to improve performance in Windows NT 4.0, I think previously in NT 3.x they often needed user space context switches, whilst syscalls were cheaper (or something like that), especially for ones that ended up making driver / kernel calls anyway. In hindsight a silly idea, trading off security for a speed boost.
- xeonmc 1y ago
  Also see https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37003 https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37...
- pjc50 1y ago
  In the early days, GDI was drawing directly into the framebuffer; making callers go through the kernel provides a limited amount of security against just drawing all over or reading the entire desktop, I suppose. Back in those days you had enough RAM to store one (1) copy of the framebuffer, the active one, and non-foreground windows or parts thereof simply got overpainted. Aero introduced accelerated compositing: https://learn.microsoft.com/en-us/archive/msdn-magazine/2007/april/aero-glass-create-special-effects-with-the-desktop-window-manager https://learn.microsoft.com/en-us/archive/msdn-magazine/2007... And WPF and subsequent toolkits follow a more modern model of "application draws into its own RAM region using DirectX which is then composited into the desktop".
- JdeBP 1y ago
deleted 1y ago
[deleted]

42 points by walterbell 1y ago

Surac 1y ago

i do not see exactly the point in this empty table

ryao 1y ago
The table is not empty. You need to pick the windows versions to show since the table would be so huge if it showed all of them that they are hidden by default. Click “show” in the table head.
senectus1 1y ago
click on the "show" at the headers...

ryao 1y ago

I wonder how the DRM used in some video games that calls Windows system calls directly handles these changes. We know that some of it uses windows system calls directly because both Linux and Wine had to be patched to support it: https://docs.kernel.org/admin-guide/syscall-user-dispatch.html https://docs.kernel.org/admin-guide/syscall-user-dispatch.ht... If I recall correctly, Jurassic World Evolution’s DRM is one of those that needed this to work.

e4m2 1y ago
There's a million and one ways to do it, here's just some of the ones I remember: - https://www.mdsec.co.uk/2022/04/resolving-system-service-numbers-using-the-exception-directory https://www.mdsec.co.uk/2022/04/resolving-system-service-num... - https://klezvirus.github.io/RedTeaming/AV_Evasion/NoSysWhisper https://klezvirus.github.io/RedTeaming/AV_Evasion/NoSysWhisp... - https://whiteknightlabs.com/2024/07/31/layeredsyscall-abusing-veh-to-bypass-edrs https://whiteknightlabs.com/2024/07/31/layeredsyscall-abusin... Though I'm not sure which of these techniques, if any, would be most favored by a game DRM as I've never looked into it.

cies 1y ago

I count 506 on the Win list. 17 are no longer in use for recent version. So 489. And 467 on the Linux list https://filippo.io/linux-syscall-table https://filippo.io/linux-syscall-table. Ballpark the same number.

JdeBP 1y ago
It's a fairly meaningless number. Some operating systems have massive fan-in and fan-out on what is internally one single system call crossing the shell/kernel divide. Witness how much is done by sysctl() on the BSDs, for example. Whereas others will be more 1-to-1. Then there's the fact that the Native API for Windows NT is structurally very different to the Linux API (as they are both different from, say, XNU). It's basically entirely coincidental that the numbers are even close, and there are no general conclusions that one can draw from such statistics. Except, perhaps, a general but rather facile conclusion that these operating systems aren't running on 8-bit processor architectures. (-:
- dooglius 1y ago
  I recall discussion (can't find now) that performance would be impacted for Linux if a syscall table lookup had to spill to a second page. That gives a limit of 512 64-bit pointers for syscalls we want to be high-performance, which may drive both OS's to start limiting new syscalls as they get close. I don't know if there's more to this claim than just concern about an extra TLB entry though.

trzeci 1y ago

Dragon Sector's doing good!

mike_hearn 1y ago

The interesting thing about this is that some syscalls are versioned, even though the syscall interface is internal and private. There's NtLoadKey, NtLoadKey2, NtLoadKey3 and even NtLoadKeyEx. This kind of versioning on public APIs, I understand, but syscalls are only meant to be invoked by ntdll. Why do they need more than one?

meibo 1y ago
I can't tell you if that is actually the case here but most private Win32 API is actually public API since so many things are using it anyways. They never drew the line there and a lot of people go "well, they never changed this in the past, why would they now".
- JdeBP 1y ago
  This is not the Win32 API, and Raymond Chen and others at Microsoft very much did draw a line when it came to people using the Native API of Windows NT.
  - fredoralive 1y ago
    Some third party software like antivirus (and kernel mode drivers?) does use the native API, so they probably want to avoid gratuitously breaking things even at the NTDLL level (although as this table shows, making raw syscalls is something they'll break).
    - JdeBP 1y ago
      Drivers are a very different kettle of fish, and don't really involve NTDLL.DLL at all. They don't have to involve a full syscall transition, for starters, and there is a whole flavour of the Native API that doesn't. (I'm glossing over the details a bit. Go and read about Zw versus Nt in any good device driver book.) Stability of the Native API per se isn't really a big concern for drivers, not least because Microsoft invented other APIs for drivers, such as the one for graphics drivers that made drivers so loosely coupled to other things that it let the entire graphics subsystem be moved into the kernel in Windows NT 4. And the reliance of antivirus softwares on the Native API, and thus the need for stability, is somewhat overblown, not least because the Native API is far too high level a layer for antivirus softwares to trust. The flashy GUI bits might as well be just written in ordinary Win32 et al., and the other bits are busy being … well … essentially rootkits. (-:

uncircle 1y ago

I was wondering how the syscall mechanism works on Windows compared to Linux, and I found this delightful article: https://alice.climent-pommeret.red/posts/a-syscall-journey-in-the-windows-kernel/ https://alice.climent-pommeret.red/posts/a-syscall-journey-i... EDIT: also, wondering why the above article says SetMenu requires a syscall, which is not mentioned in OP, I found this: http://www.fengyuan.com/article/win32ksyscall.html http://www.fengyuan.com/article/win32ksyscall.html - looks like many GUI operations on Windows NT/2000 were implemented in kernel. That can't have been very good for performance to constantly context-switch to draw a window, no?

fredoralive 1y ago
Moving bits of GDI and USER into the kernel was to improve performance in Windows NT 4.0, I think previously in NT 3.x they often needed user space context switches, whilst syscalls were cheaper (or something like that), especially for ones that ended up making driver / kernel calls anyway. In hindsight a silly idea, trading off security for a speed boost.
xeonmc 1y ago
Also see https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37003 https://devblogs.microsoft.com/oldnewthing/20041215-00/?p=37...
pjc50 1y ago
In the early days, GDI was drawing directly into the framebuffer; making callers go through the kernel provides a limited amount of security against just drawing all over or reading the entire desktop, I suppose. Back in those days you had enough RAM to store one (1) copy of the framebuffer, the active one, and non-foreground windows or parts thereof simply got overpainted. Aero introduced accelerated compositing: https://learn.microsoft.com/en-us/archive/msdn-magazine/2007/april/aero-glass-create-special-effects-with-the-desktop-window-manager https://learn.microsoft.com/en-us/archive/msdn-magazine/2007... And WPF and subsequent toolkits follow a more modern model of "application draws into its own RAM region using DirectX which is then composited into the desktop".
JdeBP 1y ago

deleted 1y ago

[deleted]