List Locking

I know in user-mode windows, there is no locking mechanism native to the
operating system that acts like a multiple-reader, single-writer lock.
Therefore programmers have to roll their own using native OS synchronization
mechanisms. My question is, how does one not only adequatly test, but PROVE
that a given locking mechanism actually WORKS? Any whitepapers, documents, links
etc. would be useful.

Asa

Proving the correctness of 2 screenfuls of code is usually not a hard task.
Just review any windows “between lines” and ask yourself a question “what will
occur if the other guy will sneak in while the first guy is running exactly
here”?
You can look at read-write spinlocks in Linux also. They use increment by 1
for reader and major huge decrement for writer (both interlocked for sure).
You can reverse-engineer the ExXxxResourceLite routines in the kernel,
which implement exactly this kind of lock.
ERESOURCE is widely used inside the filesystems, since the FS logic
requires sometimes to hold some lock till some disk write will complete.
For instance, this logic is necessary to avoid the file being truncated
while the paging writes (from Mapped Page Writer or from Cc’s lazy writer work
items) are in progress. For this, shared/exclusive lock is nearly a must (taken
shared on IO and exclusive on truncate), and it is what is really used in the
FSDs as PagingIoResource.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Asa Yeamans”
To: “Windows System Software Devs Interest List”
Sent: Monday, March 28, 2005 5:15 AM
Subject: [ntdev] List Locking

I know in user-mode windows, there is no locking mechanism native to the
operating system that acts like a multiple-reader, single-writer lock.
Therefore programmers have to roll their own using native OS synchronization
mechanisms. My question is, how does one not only adequatly test, but PROVE
that a given locking mechanism actually WORKS? Any whitepapers, documents,
links
etc. would be useful.

Asa


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

If you go to Google and enter “Correctness of concurrent
programs”, you get over 150,000 entries. Plenty to warrant a
lifetime of study. :slight_smile:

For a quick introduction to some of the methods to prove the
integrity of concurrent code, you can try Greg Andrews’s book
"Foundation sof Multithreaded, Parallel and Distributed
Programming, Addison Wesley, Chapter 2.

But for me as a code writer, the easiest thing to do is to suck
up solutions that are known to work and that have been hacked to
death by the academic community. For example, the Readers and
Writers problem is a well studied one. It is solved in just
about any serious introductory OS textbook. Try Stallings, for
example, the pseudocode is clear as water. The solution is very
simple if you can live with readers having priority over
writers: you need two one-deep semaphores or mutexes, one to
protect the object itself, the other to lock the writer(s). So:

ReadLock: wait on the object semaphore, increase the number of
readers. If transitioning from zero to one reader, wait on the
write semaphore. Release the object semaphore. Enter your read
critical section.

ReadUnlock: wait on the object semaphore, decrease the number of
readers. If transitioning from one to zero, release the write
semaphore. Relase the object semaphore.

WriteLock: wait on the write semaphore. Enter your write
critical section.

WriteUnlock: release the write semaphore.

The solution is a bit more complicated if you want writers to
have priority, but you can consult your friendly OS book for
that code.

If you are writing your driver in C++, you can easily
encapsulate these as guards inside the class of the object
you’re trying to protect, creating the equivalent of a Hoare’s
Monitor construct.

Last but not least, one caveat: the fact that there’s such a
mechanism implemented inside the OS is no guarantee that it is
proven correct either! No matter how well one tests it, there’s
always one bug left.

Alberto.

----- Original Message -----
From: “Asa Yeamans”
To: “Windows System Software Devs Interest List”

Sent: Sunday, March 27, 2005 8:15 PM
Subject: [ntdev] List Locking

I know in user-mode windows, there is no locking mechanism
native to the
operating system that acts like a multiple-reader, single-writer
lock.
Therefore programmers have to roll their own using native OS
synchronization
mechanisms. My question is, how does one not only adequatly
test, but PROVE
that a given locking mechanism actually WORKS? Any whitepapers,
documents, links
etc. would be useful.

Asa


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com

> If you are writing your driver in C++, you can easily

encapsulate these as guards inside the class of the object
you’re trying to protect, creating the equivalent of a Hoare’s
Monitor construct.

In C, you can encapsulate these in functions :slight_smile:

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Not much more to say than thanks to everyone on this group
for all the valuable insight everyone provides. In the few years
I’ve been subscribed, I have learned vast amounts about how the
internals of NT work, what to do and what not to do when coding.
I’ve heard countless times about how bad hooking is, I guess
no one here fishes because of their avoidance of hooking, and I’ve
seen API’s created where none existed before to avoid the hooking
corundrum. Ive also seen countless C vs C++ wars and comments about
how each really works.

Once again, thanks for all the knowledge/help and keep posting.

Asa

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Alberto Moreira
Sent: Monday, March 28, 2005 9:32 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] List Locking

If you go to Google and enter “Correctness of concurrent
programs”, you get over 150,000 entries. Plenty to warrant a
lifetime of study. :slight_smile:

For a quick introduction to some of the methods to prove the
integrity of concurrent code, you can try Greg Andrews’s book
"Foundation sof Multithreaded, Parallel and Distributed
Programming, Addison Wesley, Chapter 2.

But for me as a code writer, the easiest thing to do is to suck
up solutions that are known to work and that have been hacked to
death by the academic community. For example, the Readers and
Writers problem is a well studied one. It is solved in just
about any serious introductory OS textbook. Try Stallings, for
example, the pseudocode is clear as water. The solution is very
simple if you can live with readers having priority over
writers: you need two one-deep semaphores or mutexes, one to
protect the object itself, the other to lock the writer(s). So:

ReadLock: wait on the object semaphore, increase the number of
readers. If transitioning from zero to one reader, wait on the
write semaphore. Release the object semaphore. Enter your read
critical section.

ReadUnlock: wait on the object semaphore, decrease the number of
readers. If transitioning from one to zero, release the write
semaphore. Relase the object semaphore.

WriteLock: wait on the write semaphore. Enter your write
critical section.

WriteUnlock: release the write semaphore.

The solution is a bit more complicated if you want writers to
have priority, but you can consult your friendly OS book for
that code.

If you are writing your driver in C++, you can easily
encapsulate these as guards inside the class of the object
you’re trying to protect, creating the equivalent of a Hoare’s
Monitor construct.

Last but not least, one caveat: the fact that there’s such a
mechanism implemented inside the OS is no guarantee that it is
proven correct either! No matter how well one tests it, there’s
always one bug left.

Alberto.

----- Original Message -----
From: “Asa Yeamans”
To: “Windows System Software Devs Interest List”

Sent: Sunday, March 27, 2005 8:15 PM
Subject: [ntdev] List Locking

I know in user-mode windows, there is no locking mechanism
native to the
operating system that acts like a multiple-reader, single-writer
lock.
Therefore programmers have to roll their own using native OS
synchronization
mechanisms. My question is, how does one not only adequatly
test, but PROVE
that a given locking mechanism actually WORKS? Any whitepapers,
documents, links
etc. would be useful.

Asa


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@rivin.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

You cannot really encapsulate anything in C except by making it
local. C is a flat language with only two levels of
encapsulation: it’s in or its’ out. There’s a big difference
between the C code

semaphore s; function f (params p) { P(s); body_of_f(p);
V(s); }

and the corresponding object-oriented code

Class C { private: semaphore s; public function f(params p)
{ P(s); body_of_f(p); V(s); } }

in that in C the semaphore is public, while in an
object-oriented language it can be made private. Now, you can
make the semaphore s local to the function f, that is, if f is
complicated enough that it forks its own threads inside its
context, but then you will be in trouble having two functions
sharing it. For example, I don’t know how to do this in C
without making the semaphore s into a public (and hence not
encapsulated) entity, or else passing the semaphore as a
parameter which is even uglier:

Class C {private: semaphore s;
public: function f(params p) { P(s);
body_of_f(p); V(s); }
public: function g(params q) { P(s);
body_of_g(p); V(s); }}

because, remember, synchronization constructs are there to
protect code, not data, and you will will typically need to have
multiple procedures accessing the same piece of protected data.

In the object oriented case, the semaphore is encapsulated
inside the class, and it is not accessible to code outside the
class; but that’s not the case in C. So, in the case of
readers/writers, the code becomes

Class RW {private: semaphore s; semaphore w; private
nreaders;
RW::RW() { V(s); V(w); body_of_RW_Constructor();
nreaders=0; }
private: void Rlock() { P(s); if (nreaders++ == 0) P(w);
V(s); }
private: void Runlock() { P(s); if (nreaders-- == 1)
V(w); V(s); }
private: void Wlock() { P(w); }
private: void Wunlock() { V(w); }
public: void *Reader(params *pr) { body_of_reader, uses
Rlock/Runlock… }
public: void *Writer(params *pw) { body_of_writer, uses
Wlock/Wunlock… }}

and the whole of the locking and unlocking is done inside the
encapsulation and totally invisible to the outside world: you
can write your mainline code ignoring the fact that any
synchronization is performed inside the object of class C. This
adds robustness to the code, makes it more modular, and avoids
security gaps such as allowing those semaphores or the reader
count to be visible outside the object. Moreover, if now you
have two objects of class RW, not one, you do not need any
additional code: you can write

RW rwa, rwb;

and you know that each one is protected by its own semaphore,
automatically: the constructor initializes the semaphore. If
you’re doing it in C, you will need to create two semaphores,
initialize them by hand, and make sure that rwa code doesn’t use
rwb’s semaphore or vice-versa.

If you look at a Hoare’s Monitor, you see that it’s really a
synchronization object: multiple functions sharing one set of
synchronization primitives that are not usable from outside the
Monitor: only the public functions can be exercised. It’s really
an object-oriented API. You can’t program a Hoare Monitor in C
without leaving holes which will obviously end up becoming
security flaws in the code: you need an object oriented language
for that kind of encapsulation.

Alberto.

----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”

Sent: Monday, March 28, 2005 7:17 PM
Subject: Re: [ntdev] List Locking

>> If you are writing your driver in C++, you can easily
>> encapsulate these as guards inside the class of the object
>> you’re trying to protect, creating the equivalent of a
>> Hoare’s
>> Monitor construct.
>
> In C, you can encapsulate these in functions :slight_smile:
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

> an object-oriented API. You can’t program a Hoare Monitor in C

without leaving holes which will obviously end up becoming
security flaws in the code:

Why security flaws? any buffer overruns there? any other exploitable holes?

C++ is the same as C in the aspect that the internal details of the class are
declared in the public header accessible by everybody.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“You can’t program a Hoare Monitor in C without leaving holes which will
obviously end up becoming security flaws in the code: you need an object
oriented language for that kind of encapsulation.”

Hmmm… can I program such a thing in assembly language?

Chuck

----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, March 29, 2005 8:42 PM
Subject: Re: [ntdev] List Locking

> You cannot really encapsulate anything in C except by making it local.
> C is a flat language with only two levels of encapsulation: it’s in or
> its’ out. There’s a big difference between the C code
>
> semaphore s; function f (params p) { P(s); body_of_f(p); V(s); }
>
> and the corresponding object-oriented code
>
> Class C { private: semaphore s; public function f(params p) { P(s);
> body_of_f(p); V(s); } }
>
> in that in C the semaphore is public, while in an object-oriented
> language it can be made private. Now, you can make the semaphore s
> local to the function f, that is, if f is complicated enough that it
> forks its own threads inside its context, but then you will be in
> trouble having two functions sharing it. For example, I don’t know how
> to do this in C without making the semaphore s into a public (and
> hence not encapsulated) entity, or else passing the semaphore as a
> parameter which is even uglier:
>
> Class C {private: semaphore s;
> public: function f(params p) { P(s); body_of_f(p);
> V(s); }
> public: function g(params q) { P(s); body_of_g(p);
> V(s); }}
>
> because, remember, synchronization constructs are there to protect
> code, not data, and you will will typically need to have multiple
> procedures accessing the same piece of protected data.
>
> In the object oriented case, the semaphore is encapsulated inside the
> class, and it is not accessible to code outside the class; but that’s
> not the case in C. So, in the case of readers/writers, the code
> becomes
>
> Class RW {private: semaphore s; semaphore w; private nreaders;
> RW::RW() { V(s); V(w); body_of_RW_Constructor(); nreaders=0; }
> private: void Rlock() { P(s); if (nreaders++ == 0) P(w); V(s); }
> private: void Runlock() { P(s); if (nreaders-- == 1) V(w);
> V(s); }
> private: void Wlock() { P(w); }
> private: void Wunlock() { V(w); }
> public: void *Reader(params *pr) { body_of_reader, uses
> Rlock/Runlock… }
> public: void *Writer(params *pw) { body_of_writer, uses
> Wlock/Wunlock… }}
>
> and the whole of the locking and unlocking is done inside the
> encapsulation and totally invisible to the outside world: you can
> write your mainline code ignoring the fact that any synchronization is
> performed inside the object of class C. This adds robustness to the
> code, makes it more modular, and avoids security gaps such as allowing
> those semaphores or the reader count to be visible outside the object.
> Moreover, if now you have two objects of class RW, not one, you do not
> need any additional code: you can write
>
> RW rwa, rwb;
>
> and you know that each one is protected by its own semaphore,
> automatically: the constructor initializes the semaphore. If you’re
> doing it in C, you will need to create two semaphores, initialize them
> by hand, and make sure that rwa code doesn’t use rwb’s semaphore or
> vice-versa.
>
> If you look at a Hoare’s Monitor, you see that it’s really a
> synchronization object: multiple functions sharing one set of
> synchronization primitives that are not usable from outside the
> Monitor: only the public functions can be exercised. It’s really an
> object-oriented API. You can’t program a Hoare Monitor in C without
> leaving holes which will obviously end up becoming security flaws in
> the code: you need an object oriented language for that kind of
> encapsulation.
>
> Alberto.
>
>
>
> ----- Original Message -----
> From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
> Sent: Monday, March 28, 2005 7:17 PM
> Subject: Re: [ntdev] List Locking
>
>
>>> If you are writing your driver in C++, you can easily
>>> encapsulate these as guards inside the class of the object
>>> you’re trying to protect, creating the equivalent of a Hoare’s
>>> Monitor construct.
>>
>> In C, you can encapsulate these in functions :slight_smile:
>>
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com

This is a level of pontification that could only be written by someone who
never saw professional software being written ‘in the day’.

Before Bjorne came along, we knew how to create structured code without the
help of the compiler.

The Multics kernel was written in PL/1, and it was more structured than a
lot of C++ code that I have the displeasure to have to repair.

How did we do it?

To a first approximation, a class is a struct with a bunch of function
pointers. Make a family of functions to access to it, don’t include the
header with the class definition, and, !presto!, data hiding.

Don’t get started on public versus private. That’s fine for keeping unruly
children in line, but a poorly-behaved programmer will abuse it, and a
well-behaved programmer is perfectly capable of abiding by conventions like
“just call the defined interface.” Particularly advanced specimens can
handle ‘members whose names begin with _ are private to the module.’

I’m not making this up. I worked on large systems that were coded this way
in PL/I and C. I worked on the team that added exceptions to the initial
Cfront implementation of C++. I’m perfectly happy to use C++ when available,
but I’m really impatient with people who claim that the history of organized
programming began with C++. And don’t get me started on what we could do
with Lisp on a Lisp machine …

To begin with, you cannot easily have functions as members of a
C structure, so your case’s already only half made. But any
public global variable that is used as a synchronization
construct is a potential security gap. Think compile time, not
run time; not all security breaches are inflicted by hackers at
run time. Just use that variable from some other program in the
wrong way, or have a localized overflow that clobbers it, and
you may have more of a problem than you shopped for! And no,
private variables (or functions!) in C++ are not accessible “by
everybody”, the compiler will throw an error message if you try
it. Actually even protected variables can only be used by
objects in that class’s hierarchy. For example, if I have a
class such as

class CSortable
{

public: qsort(…) { … partition(); … }
private: partition(…) { … }

};

and if you declare a variable such as

SORTABLE s;

then you will be able to invoke s.qsort(), but the compiler
should not let you invoke s.partition(). Even if you declared
“protected: partition()”, the compiler would only allow
partition() to be used inside a class derived from CSortable.
The whole point of objects is that you can only use them through
their published interfaces, that is, whatever they declare as
“public”. Everything else is hidden and only usable inside the
boundaries of the class itself. In fact, Bjarne Stroustrup’s
book itself says that a struct is a class where members are
public by default!

Alberto.

----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”

Sent: Wednesday, March 30, 2005 4:32 AM
Subject: Re: [ntdev] List Locking

>> an object-oriented API. You can’t program a Hoare Monitor in
>> C
>> without leaving holes which will obviously end up becoming
>> security flaws in the code:
>
> Why security flaws? any buffer overruns there? any other
> exploitable holes?
>
> C++ is the same as C in the aspect that the internal details
> of the class are
> declared in the public header accessible by everybody.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

No - assembler language is, by definition, unprotected. Note the
difference between assembler - which is a *language* - and
instructions, which are *code*. Every program gets converted to
code, and obviously the resulting safety of your code will
depend on how well the underlying computer architecture protects
it from misuse, and to what extent the OS uses those
architectural features with the same objective in mind. So, for
example, at run time a buffer overflow could harm a
synchronization construct, unless the OS is wise enough to bound
the buffer within a segment so that overflows generate a trap
into the OS’s protection fault mechanism: the issue of runaway
code cloberring unwanted pieces of data through inadvertent or
intentional writing out-of-bounds has been addressed in the i386
architecture by segmentation and by allowing for a strict
separation between the physical addresses used for code, data
and stack. While in contemporary OS’s data, code and stack are
often aliased over the same address ranges, the underlying
architecture allows you to walk away from that obvious security
flaw by separating them into three different and non-aliased
segments.

There’s multiple levels of security, but not having it at source
code level can make all the lower level provisions ineffective!

Alberto.

----- Original Message -----
From: “Chuck Batson”
To: “Windows System Software Devs Interest List”

Sent: Wednesday, March 30, 2005 5:30 AM
Subject: Re: [ntdev] List Locking

> “You can’t program a Hoare Monitor in C without leaving holes
> which will obviously end up becoming security flaws in the
> code: you need an object oriented language for that kind of
> encapsulation.”
>
> Hmmm… can I program such a thing in assembly language?
>
> Chuck
>
> ----- Original Message -----
> From: “Alberto Moreira”
> To: “Windows System Software Devs Interest List”
>
> Sent: Tuesday, March 29, 2005 8:42 PM
> Subject: Re: [ntdev] List Locking
>
>
>> You cannot really encapsulate anything in C except by making
>> it local. C is a flat language with only two levels of
>> encapsulation: it’s in or its’ out. There’s a big difference
>> between the C code
>>
>> semaphore s; function f (params p) { P(s); body_of_f(p);
>> V(s); }
>>
>> and the corresponding object-oriented code
>>
>> Class C { private: semaphore s; public function f(params
>> p) { P(s); body_of_f(p); V(s); } }
>>
>> in that in C the semaphore is public, while in an
>> object-oriented language it can be made private. Now, you can
>> make the semaphore s local to the function f, that is, if f
>> is complicated enough that it forks its own threads inside
>> its context, but then you will be in trouble having two
>> functions sharing it. For example, I don’t know how to do
>> this in C without making the semaphore s into a public (and
>> hence not encapsulated) entity, or else passing the semaphore
>> as a parameter which is even uglier:
>>
>> Class C {private: semaphore s;
>> public: function f(params p) { P(s);
>> body_of_f(p); V(s); }
>> public: function g(params q) { P(s);
>> body_of_g(p); V(s); }}
>>
>> because, remember, synchronization constructs are there to
>> protect code, not data, and you will will typically need to
>> have multiple procedures accessing the same piece of
>> protected data.
>>
>> In the object oriented case, the semaphore is encapsulated
>> inside the class, and it is not accessible to code outside
>> the class; but that’s not the case in C. So, in the case of
>> readers/writers, the code becomes
>>
>> Class RW {private: semaphore s; semaphore w; private
>> nreaders;
>> RW::RW() { V(s); V(w); body_of_RW_Constructor();
>> nreaders=0; }
>> private: void Rlock() { P(s); if (nreaders++ == 0)
>> P(w); V(s); }
>> private: void Runlock() { P(s); if (nreaders-- == 1)
>> V(w); V(s); }
>> private: void Wlock() { P(w); }
>> private: void Wunlock() { V(w); }
>> public: void *Reader(params *pr) { body_of_reader, uses
>> Rlock/Runlock… }
>> public: void *Writer(params *pw) { body_of_writer, uses
>> Wlock/Wunlock… }}
>>
>> and the whole of the locking and unlocking is done inside the
>> encapsulation and totally invisible to the outside world: you
>> can write your mainline code ignoring the fact that any
>> synchronization is performed inside the object of class C.
>> This adds robustness to the code, makes it more modular, and
>> avoids security gaps such as allowing those semaphores or the
>> reader count to be visible outside the object. Moreover, if
>> now you have two objects of class RW, not one, you do not
>> need any additional code: you can write
>>
>> RW rwa, rwb;
>>
>> and you know that each one is protected by its own semaphore,
>> automatically: the constructor initializes the semaphore. If
>> you’re doing it in C, you will need to create two semaphores,
>> initialize them by hand, and make sure that rwa code doesn’t
>> use rwb’s semaphore or vice-versa.
>>
>> If you look at a Hoare’s Monitor, you see that it’s really a
>> synchronization object: multiple functions sharing one set of
>> synchronization primitives that are not usable from outside
>> the Monitor: only the public functions can be exercised. It’s
>> really an object-oriented API. You can’t program a Hoare
>> Monitor in C without leaving holes which will obviously end
>> up becoming security flaws in the code: you need an object
>> oriented language for that kind of encapsulation.
>>
>> Alberto.
>>
>>
>>
>> ----- Original Message -----
>> From: “Maxim S. Shatskih”
>> To: “Windows System Software Devs Interest List”
>>
>> Sent: Monday, March 28, 2005 7:17 PM
>> Subject: Re: [ntdev] List Locking
>>
>>
>>>> If you are writing your driver in C++, you can easily
>>>> encapsulate these as guards inside the class of the object
>>>> you’re trying to protect, creating the equivalent of a
>>>> Hoare’s
>>>> Monitor construct.
>>>
>>> In C, you can encapsulate these in functions :slight_smile:
>>>
>>> Maxim Shatskih, Windows DDK MVP
>>> StorageCraft Corporation
>>> xxxxx@storagecraft.com
>>> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

So, you deny that object orientation gives additional
structuring just because people misuse it ? Anyone can misuse
any language.

Benson, I lived in that era too. Operating Systems were written
in machine code too, or in ad-hoc PL/1 like languages such as
Plus. I did my fair amount of programming in PL/1 too, and
sorry, I totally disagree that it gives more structuring than a
modern object-oriented language does. But like the Burroughs
MCP, Multics was written with a certain level of hardware
features in mind - and those features are no longer provided or
used. So, in those days you could delegate things to the
hardware that today you cannot, if nothing else because even if
the hardware implements them, the OS refuses to use them on
ideological considerations such as “compatibility” and
“riscness”.

Such is life… This is 2005, not 1965.

Alberto

----- Original Message -----
From: “Benson Margulies”
To: “Windows System Software Devs Interest List”

Sent: Wednesday, March 30, 2005 7:38 AM
Subject: RE: [ntdev] List Locking

This is a level of pontification that could only be written by
someone who
never saw professional software being written ‘in the day’.

Before Bjorne came along, we knew how to create structured code
without the
help of the compiler.

The Multics kernel was written in PL/1, and it was more
structured than a
lot of C++ code that I have the displeasure to have to repair.

How did we do it?

To a first approximation, a class is a struct with a bunch of
function
pointers. Make a family of functions to access to it, don’t
include the
header with the class definition, and, !presto!, data hiding.

Don’t get started on public versus private. That’s fine for
keeping unruly
children in line, but a poorly-behaved programmer will abuse it,
and a
well-behaved programmer is perfectly capable of abiding by
conventions like
“just call the defined interface.” Particularly advanced
specimens can
handle ‘members whose names begin with _ are private to the
module.’

I’m not making this up. I worked on large systems that were
coded this way
in PL/I and C. I worked on the team that added exceptions to the
initial
Cfront implementation of C++. I’m perfectly happy to use C++
when available,
but I’m really impatient with people who claim that the history
of organized
programming began with C++. And don’t get me started on what we
could do
with Lisp on a Lisp machine …


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com

It seems to me that early versions of C++ were implemented preprocessors for
C, then compiled by the standard C compiler. That seems proof enough that
object oriented code can be written in C.

Larry

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alberto Moreira
Sent: Wednesday, March 30, 2005 8:36 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] List Locking

To begin with, you cannot easily have functions as members of a
C structure, so your case’s already only half made. But any
public global variable that is used as a synchronization
construct is a potential security gap. Think compile time, not
run time; not all security breaches are inflicted by hackers at
run time. Just use that variable from some other program in the
wrong way, or have a localized overflow that clobbers it, and
you may have more of a problem than you shopped for! And no,
private variables (or functions!) in C++ are not accessible “by
everybody”, the compiler will throw an error message if you try
it. Actually even protected variables can only be used by
objects in that class’s hierarchy. For example, if I have a
class such as

class CSortable
{

public: qsort(…) { … partition(); … }
private: partition(…) { … }

};

and if you declare a variable such as

SORTABLE s;

then you will be able to invoke s.qsort(), but the compiler
should not let you invoke s.partition(). Even if you declared
“protected: partition()”, the compiler would only allow
partition() to be used inside a class derived from CSortable.
The whole point of objects is that you can only use them through
their published interfaces, that is, whatever they declare as
“public”. Everything else is hidden and only usable inside the
boundaries of the class itself. In fact, Bjarne Stroustrup’s
book itself says that a struct is a class where members are
public by default!

Alberto.

----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”

Sent: Wednesday, March 30, 2005 4:32 AM
Subject: Re: [ntdev] List Locking

>> an object-oriented API. You can’t program a Hoare Monitor in
>> C
>> without leaving holes which will obviously end up becoming
>> security flaws in the code:
>
> Why security flaws? any buffer overruns there? any other
> exploitable holes?
>
> C++ is the same as C in the aspect that the internal details
> of the class are
> declared in the public header accessible by everybody.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@diebold.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Any code can be written in machine language or in strings of
zeros and ones. Does that mean that no language has more
expressive power than that ? Of course not. What we do want with
computer languages is to have something that we can solve as
many problems as we can at compile time - and whatever you
translate it to, it’s well known that all you need is a Turing
Machine anyway. Yet, am I going to only write my code in Turing
Machine tuples ? I don’t think so.

Now, if you yourself stick to your line of reasoning, you should
start writing your drivers in Visual Basic, after all, the .NET
runtime is the same no matter what language you use. Besides, it
all gets converted to machine code anyway. But both you and I
may agree that’s probably not a good idea.

Alberto.

----- Original Message -----
From: “Harmon, Larry (CT)”
To: “Windows System Software Devs Interest List”

Sent: Wednesday, March 30, 2005 8:56 AM
Subject: RE: [ntdev] List Locking

> It seems to me that early versions of C++ were implemented
> preprocessors for
> C, then compiled by the standard C compiler. That seems proof
> enough that
> object oriented code can be written in C.
>
> Larry
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> Alberto Moreira
> Sent: Wednesday, March 30, 2005 8:36 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] List Locking
>
> To begin with, you cannot easily have functions as members of
> a
> C structure, so your case’s already only half made. But any
> public global variable that is used as a synchronization
> construct is a potential security gap. Think compile time, not
> run time; not all security breaches are inflicted by hackers
> at
> run time. Just use that variable from some other program in
> the
> wrong way, or have a localized overflow that clobbers it, and
> you may have more of a problem than you shopped for! And no,
> private variables (or functions!) in C++ are not accessible
> “by
> everybody”, the compiler will throw an error message if you
> try
> it. Actually even protected variables can only be used by
> objects in that class’s hierarchy. For example, if I have a
> class such as
>
> class CSortable
> {
> …
> public: qsort(…) { … partition(); … }
> private: partition(…) { … }
> …
> };
>
> and if you declare a variable such as
>
> SORTABLE s;
>
> then you will be able to invoke s.qsort(), but the compiler
> should not let you invoke s.partition(). Even if you declared
> “protected: partition()”, the compiler would only allow
> partition() to be used inside a class derived from CSortable.
> The whole point of objects is that you can only use them
> through
> their published interfaces, that is, whatever they declare as
> “public”. Everything else is hidden and only usable inside the
> boundaries of the class itself. In fact, Bjarne Stroustrup’s
> book itself says that a struct is a class where members are
> public by default!
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
>
> Sent: Wednesday, March 30, 2005 4:32 AM
> Subject: Re: [ntdev] List Locking
>
>
>>> an object-oriented API. You can’t program a Hoare Monitor in
>>> C
>>> without leaving holes which will obviously end up becoming
>>> security flaws in the code:
>>
>> Why security flaws? any buffer overruns there? any other
>> exploitable holes?
>>
>> C++ is the same as C in the aspect that the internal details
>> of the class are
>> declared in the public header accessible by everybody.
>>
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@diebold.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

Hello Alberto,

To begin with, you cannot easily have functions as members of a C
structure, so your case’s already only half made.

Classes are essentially a structures with functions associated to them.
U write a.foo() instead of foo(&a).

But any public global variable that is used as a synchronization
construct is a potential security gap. Think compile time, not run
time; not all security breaches are inflicted by hackers at run time.
Just use that variable from some other program in the wrong way, or
have a localized overflow that clobbers it, and you may have more of a
problem than you shopped for! And no, private variables (or
functions!) in C++ are not accessible “by everybody”, the compiler
will throw an error message if you try it. Actually even protected
variables can only be used by objects in that class’s hierarchy. For
example, if I have a class such as

I will give you a counter-example:

<foo.h>

typedef struct _Sortable * PSortable;

// access functions
sometype func_1(PSortable * , params);
sometype func_2(PSortable * , params);


// if you want a global object -> create an access function
PSortable getGlobalSortable();

<foo.c>
# include “foo.h”

//
// this definition could be moved in foo_int.h for example
// this header could contain the definition for the “protected” functions
//
typedef struct _Sortable {
some_members;
} Sortable;

>>> implementation for the interface functions;

>>> implemetation for the private/protected functions


C++ is a great extension of C. But its power shows up when you are using
it for data abstraction / virtualization.

Andrei

> class CSortable
> {
> …
> public: qsort(…) { … partition(); … }
> private: partition(…) { … }
> …
> };
>
> and if you declare a variable such as
>
> SORTABLE s;
>
> then you will be able to invoke s.qsort(), but the compiler should not
> let you invoke s.partition(). Even if you declared “protected:
> partition()”, the compiler would only allow partition() to be used
> inside a class derived from CSortable. The whole point of objects is
> that you can only use them through their published interfaces, that
> is, whatever they declare as “public”. Everything else is hidden and
> only usable inside the boundaries of the class itself. In fact, Bjarne
> Stroustrup’s book itself says that a struct is a class where members
> are public by default!
>
> Alberto.
>
>
> ----- Original Message ----- From: “Maxim S. Shatskih”
>
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, March 30, 2005 4:32 AM
> Subject: Re: [ntdev] List Locking
>
>
>>> an object-oriented API. You can’t program a Hoare Monitor in C
>>> without leaving holes which will obviously end up becoming
>>> security flaws in the code:
>>
>>
>> Why security flaws? any buffer overruns there? any other
>> exploitable holes?
>>
>> C++ is the same as C in the aspect that the internal details of the
>> class are
>> declared in the public header accessible by everybody.
>>
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@bitdefender.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>


Ignorance more frequently begets confidence than does knowledge.
— Charles Darwin


This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/</foo.c></foo.h>

Andrei Zlate-Podani wrote:

// access functions
sometype func_1(PSortable * , params);
sometype func_2(PSortable * , params);

Correction:

sometype func_1(PSortable , params);
sometype func_2(PSortable , params);

Andrei


This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/

“And no, private variables (or functions!) in C++ are not accessible ‘by
everybody’, the compiler will throw an error message if you try it.
Actually even protected variables can only be used by objects in that
class’s hierarchy.”

What happens if I copy the header file and change all instances of
“private” and “protected” to “public”?

Chuck

----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 30, 2005 8:35 PM
Subject: Re: [ntdev] List Locking

> To begin with, you cannot easily have functions as members of a C
> structure, so your case’s already only half made. But any public
> global variable that is used as a synchronization construct is a
> potential security gap. Think compile time, not run time; not all
> security breaches are inflicted by hackers at run time. Just use that
> variable from some other program in the wrong way, or have a localized
> overflow that clobbers it, and you may have more of a problem than you
> shopped for! And no, private variables (or functions!) in C++ are not
> accessible “by everybody”, the compiler will throw an error message if
> you try it. Actually even protected variables can only be used by
> objects in that class’s hierarchy. For example, if I have a class such
> as
>
> class CSortable
> {
> …
> public: qsort(…) { … partition(); … }
> private: partition(…) { … }
> …
> };
>
> and if you declare a variable such as
>
> SORTABLE s;
>
> then you will be able to invoke s.qsort(), but the compiler should not
> let you invoke s.partition(). Even if you declared “protected:
> partition()”, the compiler would only allow partition() to be used
> inside a class derived from CSortable. The whole point of objects is
> that you can only use them through their published interfaces, that
> is, whatever they declare as “public”. Everything else is hidden and
> only usable inside the boundaries of the class itself. In fact, Bjarne
> Stroustrup’s book itself says that a struct is a class where members
> are public by default!
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, March 30, 2005 4:32 AM
> Subject: Re: [ntdev] List Locking
>
>
>>> an object-oriented API. You can’t program a Hoare Monitor in C
>>> without leaving holes which will obviously end up becoming
>>> security flaws in the code:
>>
>> Why security flaws? any buffer overruns there? any other
>> exploitable holes?
>>
>> C++ is the same as C in the aspect that the internal details of the
>> class are
>> declared in the public header accessible by everybody.
>>
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Exactly. Further, C compiles to assembly, which seems proof enough I
can write it in assembly (or machine code – more or less the same thing
in my book).

:slight_smile:

Chuck

----- Original Message -----
From: “Harmon, Larry (CT)”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 30, 2005 8:56 PM
Subject: RE: [ntdev] List Locking

> It seems to me that early versions of C++ were implemented
> preprocessors for
> C, then compiled by the standard C compiler. That seems proof enough
> that
> object oriented code can be written in C.
>
> Larry
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Alberto
> Moreira
> Sent: Wednesday, March 30, 2005 8:36 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] List Locking
>
> To begin with, you cannot easily have functions as members of a
> C structure, so your case’s already only half made. But any
> public global variable that is used as a synchronization
> construct is a potential security gap. Think compile time, not
> run time; not all security breaches are inflicted by hackers at
> run time. Just use that variable from some other program in the
> wrong way, or have a localized overflow that clobbers it, and
> you may have more of a problem than you shopped for! And no,
> private variables (or functions!) in C++ are not accessible “by
> everybody”, the compiler will throw an error message if you try
> it. Actually even protected variables can only be used by
> objects in that class’s hierarchy. For example, if I have a
> class such as
>
> class CSortable
> {
> …
> public: qsort(…) { … partition(); … }
> private: partition(…) { … }
> …
> };
>
> and if you declare a variable such as
>
> SORTABLE s;
>
> then you will be able to invoke s.qsort(), but the compiler
> should not let you invoke s.partition(). Even if you declared
> “protected: partition()”, the compiler would only allow
> partition() to be used inside a class derived from CSortable.
> The whole point of objects is that you can only use them through
> their published interfaces, that is, whatever they declare as
> “public”. Everything else is hidden and only usable inside the
> boundaries of the class itself. In fact, Bjarne Stroustrup’s
> book itself says that a struct is a class where members are
> public by default!
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
>
> Sent: Wednesday, March 30, 2005 4:32 AM
> Subject: Re: [ntdev] List Locking
>
>
>>> an object-oriented API. You can’t program a Hoare Monitor in
>>> C
>>> without leaving holes which will obviously end up becoming
>>> security flaws in the code:
>>
>> Why security flaws? any buffer overruns there? any other
>> exploitable holes?
>>
>> C++ is the same as C in the aspect that the internal details
>> of the class are
>> declared in the public header accessible by everybody.
>>
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@diebold.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@cbatson.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

I’m working on a Crypto framework and I have independent modules for
Crypto Message Syntax, Cryptographic operations via PKCS11, CSP, PCSC,
Certificate Handler, LDAP, OCSP and the list goes on.
C++ is the only way to do this kind of monster and as Andrei said,
abstraction / virtualization makes your life much easier.
This framework has almost

It doesn’t matter what language is used to create something but with C++
you can draw some art work.

Florian

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Andrei
Zlate-Podani
Sent: Wednesday, March 30, 2005 5:29 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] List Locking

Hello Alberto,

To begin with, you cannot easily have functions as members of a C
structure, so your case’s already only half made.

Classes are essentially a structures with functions associated to them.
U write a.foo() instead of foo(&a).

But any public global variable that is used as a synchronization
construct is a potential security gap. Think compile time, not run
time; not all security breaches are inflicted by hackers at run time.
Just use that variable from some other program in the wrong way, or
have a localized overflow that clobbers it, and you may have more of a

problem than you shopped for! And no, private variables (or
functions!) in C++ are not accessible “by everybody”, the compiler
will throw an error message if you try it. Actually even protected
variables can only be used by objects in that class’s hierarchy. For
example, if I have a class such as

I will give you a counter-example:

<foo.h>

typedef struct _Sortable * PSortable;

// access functions
sometype func_1(PSortable * , params);
sometype func_2(PSortable * , params);


// if you want a global object -> create an access function
PSortable getGlobalSortable();

<foo.c>
# include “foo.h”

//
// this definition could be moved in foo_int.h for example
// this header could contain the definition for the “protected”
functions
//
typedef struct _Sortable {
some_members;
} Sortable;

>>> implementation for the interface functions;

>>> implemetation for the private/protected functions


C++ is a great extension of C. But its power shows up when you are using

it for data abstraction / virtualization.

Andrei

> class CSortable
> {
> …
> public: qsort(…) { … partition(); … }
> private: partition(…) { … }
> …
> };
>
> and if you declare a variable such as
>
> SORTABLE s;
>
> then you will be able to invoke s.qsort(), but the compiler should not

> let you invoke s.partition(). Even if you declared “protected:
> partition()”, the compiler would only allow partition() to be used
> inside a class derived from CSortable. The whole point of objects is
> that you can only use them through their published interfaces, that
> is, whatever they declare as “public”. Everything else is hidden and
> only usable inside the boundaries of the class itself. In fact, Bjarne

> Stroustrup’s book itself says that a struct is a class where members
> are public by default!
>
> Alberto.
>
>
> ----- Original Message ----- From: “Maxim S. Shatskih”
>
> To: “Windows System Software Devs Interest List”
> Sent: Wednesday, March 30, 2005 4:32 AM
> Subject: Re: [ntdev] List Locking
>
>
>>> an object-oriented API. You can’t program a Hoare Monitor in C
>>> without leaving holes which will obviously end up becoming
>>> security flaws in the code:
>>
>>
>> Why security flaws? any buffer overruns there? any other
>> exploitable holes?
>>
>> C++ is the same as C in the aspect that the internal details of the
>> class are
>> declared in the public header accessible by everybody.
>>
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> xxxxx@storagecraft.com
>> http://www.storagecraft.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com

>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@bitdefender.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>


Ignorance more frequently begets confidence than does knowledge.
— Charles Darwin


This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@trustnet.ro
To unsubscribe send a blank email to xxxxx@lists.osr.com</foo.c></foo.h>

C++ name mangling will result in a linker error.

From: “Chuck Batson”
>Reply-To: “Windows System Software Devs Interest List”
>
>To: “Windows System Software Devs Interest List”
>Subject: Re: [ntdev] List Locking
>Date: Wed, 30 Mar 2005 21:40:18 +0700
>
>“And no, private variables (or functions!) in C++ are not accessible ‘by
>everybody’, the compiler will throw an error message if you try it.
>Actually even protected variables can only be used by objects in that
>class’s hierarchy.”
>
>What happens if I copy the header file and change all instances of
>“private” and “protected” to “public”?
>
>Chuck
>
>----- Original Message ----- From: “Alberto Moreira”
>To: “Windows System Software Devs Interest List”
>Sent: Wednesday, March 30, 2005 8:35 PM
>Subject: Re: [ntdev] List Locking
>
>
>>To begin with, you cannot easily have functions as members of a C
>>structure, so your case’s already only half made. But any public global
>>variable that is used as a synchronization construct is a potential
>>security gap. Think compile time, not run time; not all security breaches
>>are inflicted by hackers at run time. Just use that variable from some
>>other program in the wrong way, or have a localized overflow that clobbers
>>it, and you may have more of a problem than you shopped for! And no,
>>private variables (or functions!) in C++ are not accessible “by
>>everybody”, the compiler will throw an error message if you try it.
>>Actually even protected variables can only be used by objects in that
>>class’s hierarchy. For example, if I have a class such as
>>
>> class CSortable
>> {
>> …
>> public: qsort(…) { … partition(); … }
>> private: partition(…) { … }
>> …
>> };
>>
>>and if you declare a variable such as
>>
>> SORTABLE s;
>>
>>then you will be able to invoke s.qsort(), but the compiler should not let
>>you invoke s.partition(). Even if you declared “protected: partition()”,
>>the compiler would only allow partition() to be used inside a class
>>derived from CSortable. The whole point of objects is that you can only
>>use them through their published interfaces, that is, whatever they
>>declare as “public”. Everything else is hidden and only usable inside the
>>boundaries of the class itself. In fact, Bjarne Stroustrup’s book itself
>>says that a struct is a class where members are public by default!
>>
>>Alberto.
>>
>>
>>----- Original Message ----- From: “Maxim S. Shatskih”
>>
>>To: “Windows System Software Devs Interest List”
>>Sent: Wednesday, March 30, 2005 4:32 AM
>>Subject: Re: [ntdev] List Locking
>>
>>
>>>>an object-oriented API. You can’t program a Hoare Monitor in C
>>>>without leaving holes which will obviously end up becoming
>>>>security flaws in the code:
>>>
>>>Why security flaws? any buffer overruns there? any other exploitable
>>>holes?
>>>
>>>C++ is the same as C in the aspect that the internal details of the class
>>>are
>>>declared in the public header accessible by everybody.
>>>
>>>Maxim Shatskih, Windows DDK MVP
>>>StorageCraft Corporation
>>>xxxxx@storagecraft.com
>>>http://www.storagecraft.com
>>>
>>>
>>>—
>>>Questions? First check the Kernel Driver FAQ at
>>>http://www.osronline.com/article.cfm?id=256
>>>
>>>You are currently subscribed to ntdev as: xxxxx@ieee.org
>>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>—
>>Questions? First check the Kernel Driver FAQ at
>>http://www.osronline.com/article.cfm?id=256
>>
>>You are currently subscribed to ntdev as: xxxxx@cbatson.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com