Slashdot Mirror

That's pretty much never been the rule. NT 4 SP 3 introduced certain new features, such as DirectX to the operating system. While they don't usually do massive changes, Service Packs have never been precluded from having new features added.

RPC on Windows is a set of runtime libraries, compiler support (MIDL), and a server process (rpcss) for coordinating connections and hosting libraries, used to abstract function calls so that they can be used across process and possibly machine boundaries. Since every process runs in a different address space, the application interface for making a remote function call is the same if the call destination is just in another process or on another machine, so Microsoft uses the same system for both local and remote out-of-process function calls, a system called RPC.

Every RPC interface has a set of allowed transports. One of these transports, NCALRPC, is a wrapper over LPC ports, a primitive IPC method that the OS provides that uses shared memory and only works on the local machine. If the only allowed transport is NCALRPC, then the interface can only be connected to from the local machine, even though it's still called RPC and still uses most of the common RPC components. This way, while the RPC system is used in local calls for the convenient marshaling support, support for connections to remote computers is disabled.

That sounds like the same as NT's event pairs, used to implement Quick LPC. An event pair consists of a high and a low event. The server thread waits on the high event and the client thread waits on the low event. Only one event can be signalled at one time, and two software interrupts are provided to toggle the event pair's state: interrupt 0x2C calls the function KiSetLowWaitHighThread() and interrupt 0x2B calls the function KiSetHighWaitLowThread(). When one of these is called and another thread (in another process) is waiting on the other event, the kernel schedules the other thread immediately, continuing the same timeslice of the calling thread. Transfer of data is done through a shared memory section mapped to both processes. Quick LPC was introduced in NT 3.51 to make the out-of-process GUI server faster. Apparently Microsoft didn't think it was fast enough, so they moved much of the GUI server into kernel mode in NT4.

For more information, scroll down to Quick LPC in Local Procedure Call from Undocumented Windows NT.

The NT kernel's design has all kinds of wonderful possibilities for building a secure OS around. I really wish Microsoft would do it.

So do I. Maybe Reactos?

The Win32 subsystem, however, is inherently insecure. And without the Win32 subsystem, NT is not a complete OS.

Yes, Win32 IS insecure, to a point. Window station, desktop and job objects are securable objects that NT adds that can be used to partition Win32 into sandboxes. They just aren't used much.

Win32, includes not just the GUI but the equivalent of all the UNIX daemons and system services, and large parts of what in UNIX would be kernel modules. Take that out and you're left with less than the UNIX kernel.

Most built in services are written for the Win32 subsystem since the user mode service control manager's interface is part of win32, but several have only superficial dependencies. The SMB client and server come to mind.

I thought that the NT had more, not less things running in kernel mode. Nothing in kernel mode depends on win32, ever. The only thing related to win32 that runs in kernel mode is win32k.sys, the server part of win32. Nothing in the kernel depends on win32, or can even use win32. Moving win32 into kernel mode didn't change that.

What, specifically, in Windows is implemented as a user-mode win32 dependent service that would normally be a kernel module in UNIX?

Also, there is no such thing as THE UNIX kernel. There are UNIX kernels such as Linux or OpenBSD's kernel, but no one 'true' UNIX kernel.
Compared to Linux, the NT kernel and executive services (ntoskrnl.exe) do a couple of things that Linux doesn't: the Configuration Manager AKA the Registry; a database for configuration info, the extensible Object Manager (althought the VFS comes close), and a dedicated local proceduce call facility (you can use pipes under either, but only NT has LPC) If you include all the modules that run in kernel mode (besides win32), there is more: SMB: the client is in mrxsmb.sys and the server is in srv.sys, MUP (mup.sys), CD burning support (as a filesystem), audio processing, the mailslot filesystem (msfs.sys), the named pipe filesystem (npfs.sys), plus all the things you'd expect: filesystems, bus drivers, USB drivers, and network stuff.

If you were logged on to an NT workstation as a normal user, first of all, you're more likely to be infected by a virus in the first place because the design of the Win32 subsystem practically invites them in.

Invites? How's that?

Secondly, there's a lot more opportunities for an application to boost security to Administrator or even LOCALSYSTEM: not only is the security model very complex, but you have to have all the rights any application you run is ever going to need.

NT isn't any more vulnerable to privilege escilation than UNIX is. Just because the security model is complex, doesn't mean it is broken. It may be harder to use, but it also provides much granularity (if you use it). For the last part, I don't understand what you are trying to say; how is this different from any other security model? Define a user's permissions so that they can do everything they need to. ACLs can be changed, but you should be able to set them up once.

To top it all off, there's no hard "system call" interface between different security domains.

Sure there is. It's called the Native API. The only way to request services of the kernel is through the system call interrupt, and all those functions are exported by ntdll.dll. Win32k adds an extra function table, though; it exports the services that used to be in us

1983: Novell introduces NetWare X and NetWare S
1985: Novell introduces Advanced NetWare 2.0
1987 Apr: Microsoft introduces OS/2 Lan Manager, an network operating system to compete with Novell's NetWare. It's a patched up rehash of IBM's old PCNet.
1988: Novell introduces Advanced NetWare 2.15.
1988 Oct: 3Com introduces the 3+Open network, based on Microsoft's Lan Manager (based on IBM's old PCNet). In 1990 a famous "shoot out" was held between 3+ and Novell NetWare. 3Com dropped out of the network software business in Dec 1990.
1992: Novell purchases Unix from AT&T
1993: Novell introduces NetWare 3.12 and NetWare 4.0. 4.0 introduces Novell Directory Services in place of the Bindery.
1994 February: Microsoft released Windows for Workgroups 3.11, adding networking to the product. The network, derived from IBM's primitive PCNet, is so totally piss poor people continue to buy Lantastic instead.
1994 October: IBM released OS/2 version 3.0, an operating system far superior to anything Microsoft had, or would have for years. IBM launched a major campaign to get software developed for it. Many major software houses signed up to port their applications, but nearly all had to drop OS/2 development when they read the NDA (Non-Disclosure Agreement) for the Windows95 development kit. If you were developing anything for OS/2, you could not participate in the Windows95 program. The NDA itself required total secrecy, so the reason everyone dropped OS/2 development was only rumored for years.
1994: Novell purchases WordPerfect and Quatro Pro.
1998 October: Novell introduces NetWare 5.0. NetWare gets great reviews, and Microsoft feels the heat, especially from comparisons between NetWare 5.0 (shipping, works great) and Windows NT 5.0 (very, very late; very, very buggy, not shipping yet), so renames Windows NT 5.0 to Windows 2000 to stop the 5.0 vs 5.0 comparisons.
2000 Jan: Novell introduces NetWare 5.1. Windows NT 5.0 still not shipping.

"Network Basic Input/Output System was designed for IBM by an organization named Sytek, Inc. It was created to provide an easy-to-use programming interface for connections between computers over a network. Microsoft began developing products for the MS-Net and LAN Manager (the predecessor to Windows NT) using the NetBIOS interface, anticipating the popularity of the standard. Ironically, the standard is only popular today because of Microsoft's implementation of it."

NT has a lot of ways to do IPC too. There is file based communction that uses the IO manager and file system drivers, which include pipes (the named pipe filesystem), disk files, and network sockets. There is shared memory in the form of section objects, which can optionally memory map a file. One process can read the private memory of another process, although that's usually used for debugging. There is the local procedure call (LPC) system which creates a kernel managed and message oriented (message boundries preserved) communictions port. There is the quick LPC method that continues a thread's quantum for a remote function call. Back before NT4, there used to be a lot of LPC traffic.

I'm not complaining, just trying to show the other side.

NT has a lot of ways to do IPC too. There is file based communction that uses the IO manager and file system drivers, which include pipes (the named pipe filesystem), disk files, and network sockets. There is shared memory in the form of section objects, which can optionally memory map a file. One process can read the private memory of another process, although that's usually used for debugging. There is the local procedure call (LPC) system which creates a kernel managed and message oriented (message boundries preserved) communictions port. There is the quick LPC method that continues a thread's quantum for a remote function call. Back before NT4, there used to be a lot of LPC traffic.

I'm not complaining, just trying to show the other side.

The Windows NT kernel (same one in 2000/xp) has nothing to do with "Internet Explorer/Media Player/Instant Messenger". Microsoft whined that they couldn't be removed not because it is technically infeasable but because it is part of an 'indispensible user expierence'.

NT design 101: On the bottom, there is the kernel, then the executive, which includes the object, configuration, process, VM, I/O managers, the security ref monitor (a runtime to create tokens, check ACLs) and the local procedure call provider. After that, device drivers. After that, everything is in user mode with one exception. Then there are the intrinsic subsystems: the session manager (the init process, aka smss), the local security authority (lsass), the security accounts manager (SAM), winlogon, and the service control manager. Then the environment subsystems, namely win32. The entire syscall interface is exported to user mode by the Nt* functions in ntdll.dll. Environment subsystems translate calls from their API into native calls. Win32's environment server is hosted in csrss.exe. With NT4, the meat of win32 was moved into kernel mode (win32k.sys) to reduce context switching overhead; win32 was not then and still isn't integrated into the kernel itself. The kernel doesn't care what environment subsystems are running. After that, you have the shell components; these all run in the security context of the logged on user (subsystem components run as SYSTEM). The shell includes Internet Explorer and the start menu. On top of that (usually) are applications.

Each layer only cares about the one immediately above and below it at most. To the kernel, Internet Explorer is just another user mode program. A hole in IE cannot escilate beyond the user's privledges in the process's security context. Your machine be hosed by a hole in IE if you are running it as Admin (just as a hole in Mozilla if it was running as root), but not if it is running as a normal user. You need to exploit a local vuln in the kernel first, just like any other OS.

Look at the entire syscall interface (the Nt* functions). Tell me which functions are "directly tied into the lowest levels of the operating system".

having done this spared a lot of context switches, so it has a positive impact on performance.. at the price of a lower reliability. at my knowledge this compromise wasn't made on linux, i don't know if this eventuality was studied.

for more, look for win32k.sys on these pages:
http://www.windowsitlibrary.com/Content/356/01/2.h tml
http://www.windowsitlibrary.com/Content/356/01/3.h tml

having done this spared a lot of context switches, so it has a positive impact on performance.. at the price of a lower reliability. at my knowledge this compromise wasn't made on linux, i don't know if this eventuality was studied.

for more, look for win32k.sys on these pages:
http://www.windowsitlibrary.com/Content/356/01/2.h tml
http://www.windowsitlibrary.com/Content/356/01/3.h tml

Uh, other than the fact that Windows NT *was* OS/2 v3, that it contained the full OS/2 subsystem, and that Microsoft worked with IBM on OS/2 v1-v3 until renaming v3 to Windows NT?

Chapter 3, Server Types and Security Modes, is available online for free.

Just a side note, I wasn't blaming the problems with OSX on its kernel, I was just saying Apple made a bad decision on their kernel and it does affect the system, even at a minimal level.

Sorrfy for this rant, but I really get tired of all these uninformed people that keep on saying how bad a choice Mach was for Apple and that they should have used a Linux or BSD kernel instead. Those kernels are only now catching up to Apple's Darwin kernel in terms of several - for Apple - critical features such as low-latency (at the interrupt service/driver level), proper smp and real-time support. They do have other advantages over the Darwin kernel (such as much higher fork/clone performance), but that's how it goes in general (you win some, you lose some) and you have to choose the best tool for your job.

As far as I know - and for what it's worth (not much), I checked with Google - x86-compatible CPUs can address 4 GB. There are extensions in some Intel CPUs that allow programs to address a 36-bit address space, even.
As for the 2 GB limit, there seems to be a feature in the Windows memory architecture - the upper 2 GB of a process' virtual address space is reserved for shared memory. Or something - I kind of stopped thinking at that point. ;) If you're interested, more info is available.

[blank] =Word 8.0/97 (*.doc)
MSWord6Exp =Word 6.0/95 (*.doc)
WrdPrfctWin =Word Perfect 5.x for Windows (*.doc)
WrdPrfctDOS51 =Word Perfect 5.1 for DOS (*.doc)
WrdPrfctDat =Word Perfect 5.1 or 5.2 Secondary File (*.doc)
WrdPrfctDOS50 =Word Perfect 5.0 for DOS (*.doc)
WrdPrfctDat50 =Word Perfect 5.0 Secondary File (*.doc)
HTML =HTML Document (*.html; *.htm; *.htx)
Text =Text Only (*.txt)
CRText =Text Only with Line Breaks (*.txt)
8Text =MS-DOS Text (*.txt)
8CRText =MS-DOS Text with Line Breaks (*.txt)
Unicode =Unicode Text (*.txt)
rtf =Rich Text Format (*.rtf)
Dot =Document Template (*.dot)

There may be a way to do this via broadcast the same way Windows machines without WINS do, but I don't know it.

WINS Clients -- Unix and Unix-like Systems It's very easy to configure any computer running SAMBA as a WINS client, but recall from the server discussion that SAMBA can't be a WINS server and a WINS client at the same time. So, first ensure that the smb.conf file entry "wins support = yes" (which configures the SAMBA computer as a WINS server) is a comment (the default). Then edit the next line to read "wins server = www.xxx.yyy.zzz ," where www.xxx.yyy.zzz is the IP address of your WINS server. You don't have to reboot the Unix computer. SAMBA automatically reads the configuration file changes. To force the changes to take place immediately, rather than waiting for SAMBA to read the changes from the configuration file, you can stop and restart the SAMBA programs using the /etc/rc.d/init.d/smb stop and /etc/rc.d/init.d/smb start commands.

You will have to configure a WINS server on one of the Windows servers for this to work, and add the WINS server entry to your DHCP configuration.