> Pavel A wrote:
> You do.
Thank you. It’s important to me to get a confirmation of acceptableness of
a potentially possible solution.
> Have your original application open the handle correctly (bInheritHandle
> in the lpSecurityAttributes arg must be false) then child apps won’t
> inherit the handle.
> Protect the app against remote DuplicateHandle
Thanks again. I didn’t have a notion of protected processes. But this
still does not protect against multiple malicious processes playing around
with handles to my device, assuming at least one of those could open it
directly. But… May be I found a solution. If I mark an incoming ioctl
request with the requester’s PEPROCESS in EvtIoInCallerContext and map the
MMIO region in the corresponding EvtIoDeviceControl (not in
EvtDeviceFileCreate) only if I previously processed EvtDeviceFileCreate
for that PEPROCESS, then I could peacefully do the unmap and forget that
PEPROCESS in EvtRequestCancel. This seems to cover all possible attack
scenarios.
> This is why custom devices often are protected so that only privileged
> accounts can access them.
Do you think, it’s enough to protect the device by allowing only
privileged processes to access the device? I mean, it could still be a
valid possibility to crash the kernel from user mode. Even though that’s
sometimes called a feature like in the case of
NtSetInformationProcess(ProcessBreakOnTermination).
Joseph M. Newcomer wrote:
> Generally, any design that starts, “I could map this kernel buffer to
> user space…” is going to lead you into a minefield of weird corner
> conditions that would frighten most experienced driver writers
Maybe, but there’s a potential performance gain. I’d be happy to avoid
that if I knew of any other supported way to achieve at least potential
zero-copy. E.g., it would be perfect to be able to do the whole displaying
thing completely in the kernel, but I’m not aware of any supported
graphics output interfaces in the kernel.
> Part of the question is, how expensive is the copy?
I feel like I’m going to observe all the stale tomatos thrown in my
direction, but I didn’t do the measurements. Just because my common sense
tells me it’s very likely to get singnificant perfomance degradation while
outputting FullHD at 50 Hz (which could be a bit overestimated, but also
may become a possible scenario). In fact, the purpose is not just to
ensure fluent output, but also disburden the CPU as much as possible from
handling tasks related to the PCI device, because other soft real time
tasks like 3D gaming are likely to be executed in parallel.
OK, so this is a consumer-oriented product, which is an important
parameter in the design space. However, “common sense” is not a good
gauge of performance, because common sense tends to think of things
scaling linearly. When we talk about such algorithms formally, we
categorize them as O(n) algorithms. However, this “big-O” notation is a
shorthand notation for cost = setup + C* f(n) + teardown, where C is the
“constant of proportionality”. My point is that “common sense” will not
tell you that C is nonlinear with respect to caching, for example, and in
fact the point of multilevel caching is to reduce C to a number smaller
than 1.0. Note also that large block copies are typically done
interruptible, that is, at PASSIVE_LEVEL. If you are dealing with 50Hz
frames, and the frames are only displayed visually, you can easily afford
to lose half of them, reducing your display rate to 25Hz, very close to
the standard movie frame rate of 24Hz.
> Also note that you would not free up resources on the IRP_MJ_CLEANUP
> operation, except those which are handle-specific (if any).
I assume you’re not correctly expressing yourself. The resources are not
handle specific, but FILE_OBJECT specific. And this is what actually
creates a problem.
If they are FILE_OBJECT specific, and you have multiple handles on a
FILE_OBJECT, the IRP_MJ_CLEANUP is not called until the last handle on the
FILE_OBJECT is closed. So I’m not sure why this presents a problem.
> A duplicated or inherited handle should pose absolutely no problem, in
> that you would not free up the resources until the IRP_MJ_CLOSE
> operation, meaning all handles are closed.
Yes. That’s exactly what creates the problem. If I allocate process
specific resources such as a user mode memory mapping, then I also need to
free the resources in the context of that process. MSDN suggests using
PsSetCreateProcessNotifyRoutine for such cases, but this does not seem to
me a clean solution. At least because of the following remark: “but keep
in mind that such callbacks are a limited system resource”. 64 callbacks
system-wide is really not that many.
Why do you need process-specific resources if a handle is duplicated to
multiple processes?
And the whole problem of unmapping memory shared with an app is one of the
many cans of worms that you create as soon as you consider doing
memory-maps of kernel space to user space. It gets rapidly messy.
> DoS attacks by creating handles and holding files open are
> next-to-impossible to prevent anyway, so why do you think this poses a
> particular problem for your driver?
That’s not the DoS I’m talking about. I’m talking about beeing able to
force the driver to free the process context specific resources in a
different process context. I’m not aware of consequences of that, but it
doesn’t seem good anyway.
If your driver can crash the kernel, you have to make sure that does not
happen. No matter what insanely stupid or insanely malicious software
runs, you have to be utterly and completely impervious to it. Hence the
can of worms. Trusting a user process to “do the right thing”? Well, if
you believe that, did I tell you about my uncle in the Nigerian army that
needs some help sneaking his money out of the country?
Note also that, independent of the zero-copy issue, there is still going
to be a copy, as the bits are transferred from the input device to the
display card’s frame buffer. SetDiBits isn’t going to make this copy
operation go away.
You should probably look at DirectX-types of support here, rather than GDI
support.
Expecting any user app to keep up with 50Hz full-HD is asking a lot. How
do you plan to deal with all those times when the threads are being
preempted by higher-priority threads? You have only 20ms per frame, and
if you are preempted for one scheduler cycle, you lose 30ms unless your
preempting thread finishes sooner than a “timeslice”. Expecting to
maintain this data rate, of one frame every 20ms while also running a game
does not seem to be reasonable. Even with the multimedia scheduling
service of Vista+, it does not seem to be sustainable. Perhaps a
DirectXpert has something to say about this.
joe
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer