[ros-dev] WIN32K: LPC use

[Alex Ionescu]

Emanuele Aliberti wrote:

> Hi Alex,
> I hope you are fine now, after the party and a restful night... ;-)

Someone reads my ROS Blogs! =)

>
> David Welch wrote our initial LPC code to resemble the BSD sockets 
> general design (an LPC port behaves exactly like a BSD socket; there 
> are ports in listening state and connected ports to send/receive 
> datagrams). 

An understandble implementation, since in many ways LPC ports are like 
Sockets, but the internal semantics are quite different (although to the 
outside you have your basic listen/accept/connect commands).

> That is, of course, not the way NT LPC works, but at the time David 
> wrote the code, we knew almost nothing about LPC, but the incomplete 
> information Prasad Dabak wrote in "Undocumented Windows NT" (1999). 

Yes, back then most Windows Internals were very well kept. Dabak was the 
first to go into LPC territory, although unfortunately most of that info 
is now really outdated (such as Quick LPC).

> That code was good enough to start with user mode subsystem servers, 
> but till now it has prevented us from testing real system components 
> like the SM, CSR and friends etc. for compatibility in ROS. 

Unforunately, most of our LPC-dependent components are really broken 
because they depend on the not-so-correct LPC implementation.

> This is what I have done for the last three years. What I got from the 
> researching is some better understanding of how LPC works, but not a 
> complete picture. I am glad to see you are working or planning to work 
> on LPC, because there is at least one API that is incompatible with 
> NT's, and the general semantics of the path connect->request->reply is 
> wrong. 

Also checking with some PDFs, some of our  checks are incorrect, and a 
lot of our stuff is just hard-coded. It took me a day to figure out 
where the max data/message sizes come from, but I think it was worth it, 
because that was just a small step in understanding the bigger picture.

> In short, it is the the listening port that receives the messages from 
> the clients even after the connection happens and not the server side 
> connected port). This could be deducted by studing more carefully the 
> sample code provided by Dabak, but I found it indipendently with some 
> simple c/s test code. 

One of the first functions I re-coded was LPC Port closing, and I 
noticed this fact because we were doing stuff almost backwards.

> I told it to David, Eric and others and they agreed that should be 
> correct. I will share what I know and I can send my unfinished code if 
> it may be of interest (not that I am that a skilled coder, but you 
> could just tour it for fun).

Anytime, just send it to my personal e-mail and we can collaborate.

> Recalling what David Welch told me in many occasions, NT LPC has many 
> flaws, many are security related (this led Microsoft to introduce 
> secure ports with NT 5.0, mostly to armour the LSA). 

One of my goals is to introduce support for secure ports. The problem 
with LPC is that it was "Security through obscurity". Once people found 
out how it worked, problems started appearing.

> The overall problem with the real LPC is that it looks like really 
> old, not well understood in Microsoft and almost untouched for years 
> (many unfixed LPC bugs still plague Windows). 

It was recently re-touched with the delivery of XP. It now uses Paged 
Lookaside Lists instead of Zones, and a lot of buffer checks have been 
added.

> You could even imagine it was part of the Prism project at DEC, in the 
> '80s, perhaps with the name "Channel" for what we now know as "port" 
> (undocumented and unimplemented APIs existed in NT 3.1, NT 3.5, NT 
> 3.51, NT 4.0 and NT 5.0, but disappeared in NT 5.1 and NT 5.2). 

 From what I was told, Channels were supposed to be extra high-speed 
LPCs for use in Win32.

> It seems that only lately (1999+) Microsoft forced the NT kernel team 
> to face the old LPC code to improve it.

Yep, as I said above, XP has a lot of fixes.

> Alex, what are your plans for rewriting the LPC code?

I'll email them privately.

>
> Emanuele

Best regards,
Alex Ionescu