This is where peter is supposed to interject that you can use the NtWhatever
interface that allows you to set the security, and I respond that as that is
undocumented in ntddk.h it isn’t really a ddk solution, and then the thread
has gone full circle and we can all wait a few months 'till it comes around
again. It is a meme-virus, a FAQ-NAR.*
* frequently asked question, never adequately resolved
-----Original Message-----
From: Scott Noone [mailto:xxxxx@osr.com]
Sent: Thursday, August 22, 2002 6:16 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Passing event notification from driver
to applicationThe problem with creating a named event in KM is that should
this event happen to be created within the context of the
system process your user mode application’s request for a
handle will be denied.Bottom line if you’re looking to share events - create the
named event in user mode, open the named event in kernel mode.-snoone
OSR“Nar Ganapathy[MS]” wrote in
> message news:xxxxx@ntdev…
> >
> > You can use IoCreateSynchronizationEvent in the kernel. You
> can then
> > open the same even in user mode. This way the name never
> gets passed
> > from user
> to
> > kernel and vice versa. There is also
> IoCreateNotificationEvent. Until
> > .NET server the handle returned by these APIs are process specific
> > handles and you should immediately convert them to object
> pointers. In
> > .NET server
> these
> > have been fixed.
> >
> > –
> > Nar Ganapathy
> > Windows Core OS group
> > This posting is provided “AS IS” with no warranties, and confers no
> rights.
> >
> > “Phil Barila” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > “Peter Viscarola” wrote in message
> > > news:xxxxx@ntdev…
> > > >
> > > > “Phil Barila” wrote in message
> > > > news:xxxxx@ntdev…
> > > > >
> > > > > Is it at least a valid approach to pass the name of
> the event
> > > > > from user-mode to kernel mode? Or is there a security hole
> > > > > there, too,
> > that
> > > > I’m
> > > > > not seeing?
> > > > >
> > > >
> > > > Passing the name is fine. Subject to usual barage of
> caveats and
> > warnings
> > > > about validating buffers, etc.
> > > >
> > > > Probably the best mechanism would be to pass the name as a
> > NULL-terminated
> > > > WCHAR string in the InBuffer (not using METHOD_NEITHER). Don’t
> > > > forget
> > the
> > > > name lives in “base named objects” and that the name is, thus,
> > > > unique
> in
> > > the
> > > > SYSTEM (not per session).
> > >
> > > I was about to reply that a UNICODE_STRING seems like a
> better idea,
> > > but then I realized that there is no way to verify that the
> > > Length/MaxLength members are valid, short of revalidating the
> > > Buffer, but the Buffer
> > doesn’t
> > > have to be null terminated, so maybe that’s not such a
> good idea.
> > > I
> > guess
> > > the worst thing that can happen is that the Length indication is
> > > longer
> > than
> > > the buffer, so you read beyond a page boundary and cause a PF in
> NonPaged
> > > area, or one of the other bugchecks that can be caused by reading
> > > beyond your allocation. For that matter, a malicious user could
> > > pass you a
> > buffer
> > > that ends on a page boundary, without a null, you strlen
> or strcpy
> > > it,
> go
> > > into the next page, and you have the same problem. Seems like
> > > passing
> any
> > > string from UM to KM has some risks. Comments / rebuttal
> anyone?
> > > I’d
> > love
> > > to be shown to not have a clue on this one.
> > >
> > > Michal pointed out the previous discussion, which I had
> forgotten,
> > > of
> the
> > > potential for mis-using a driver to twiddle system events that the
> > user-mode
> > > app should only be able to read. So, I guess sharing a name in a
> > > common header file is the way to go, after all. :-Z
> > >
> > > Phil
> > > –
> > > Philip D. Barila
> > > Seagate Technology, LLC
> > > (720) 684-1842
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@stratus.com To unsubscribe send a blank email to
> %%email.unsub%%
>