Using snprintf() inside Driver

The question is easy: Is it allowed using C run-times such as _snprintf() in Kernel Driver?
Other (sub)question: Is it allowed using _snprintf() on DISPATCH_LEVEL or PASSIVE_LEVEL only?

I got over few sources, including this forum and did not find direct answer on this (simple? :)) questions:

  1. Microsoft gives the list of safe string functions which recommend(!!!) replace standard C++ functions. _snprintf() in the list. But this source does not forbid using _snprintf() in Driver.
    https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/summary-of-kernel-mode-safe-string-functions

  2. The discussion http://www.osronline.com/showThread.cfm?link=36543 references on Walter Owner book with nice table of functions that can be used. snprintf() not in the list.
    The last Message 5 of Walter Owner tells:
    “You should never use wsprintf anyway, because it can easily overwrite a
    buffer. _snwprintf is better but still on the “mildly deprecated” list
    because it won’t put a null terminator on the target string if the
    needed length is >= the length of the target buffer.”
    But it does not forbid using _snwprintf (and _snwprintf) directly.
    Must be noted that this discussion from 2002 year…

What is current real situation with using these function (_snwprintf and _snwprintf) in kernel?
Additional my question 2 about using them on DISPATCH_LEVEL.

Thanks & Regards,
MG.

Allowed by WHOM, exactly? If you use or, or if you don’t, the police aren’t going to come and arrest you. Can you build your driver with it? Can you install it? Then it’s allowed. End of story.

That doesn’t make it a good idea.

But… you already know that using this function isn’t a good idea (even Walter Oney said so more than ten years ago). At best, it’s considered poor programming practice, and there’s no reason not to use the equivalent kernel-mode Safe String Handling functions (or, in user mode, the equivalent user-mode safe string handling function).

Soooo… you already know this. But you’re still asking “Is it allowed.”

Thus, my answer is, “Yes, there is nothing that prevents driver devs who want to write or support code that is prone to error and does not represent long-established best practices from using this function.”

Peter
OSR
@OSRDrivers

Peter,
I have serious reasons to ask about snprintf() using…

  1. I found this _snprintf() in one old driver

  2. I see it inside stack in Crash Dump which I was asked to check.

  3. My opinion, this snprintf() may be suspected as reason for crash. But long history and really huge number of success working driver instances whispers me continue searching - problem is other.

There are reasons.
By the way, crash occurs in DPC.

Regards,
MG.

>There are reasons. By the way, crash occurs in DPC.

I think you got it right. The problem lies not with the use of unsafe function per se but with the fact that your DPC is calling a function that , apparently, may be called only at PASSIVE_LEVEL just like its safe RtlXXXX cousins. Apparently, this routine’'s code is pageable so that you just hit a page fault on code. Taking into consideration the RAM size of modern computers, there is very little surprise that this bug does not reveal itself every other time you run your code…

Certainly, I am not saying that this is the only possible reason for a crash, but this bug most certainly needs to get fixed…

Anton Bassov

Use of string insertion (%s, %ws, %wZ, etc) in a format string, regardless of API (xprintf, safe string functions RtlUnicodeStringXxx, etc) requires PASSIVE_LEVEL. If you stick to other types, dispatch level and above is allowed.

d

-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@intel.com
Sent: Thursday, May 24, 2018 8:16 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Using snprintf() inside Driver

Peter,
I have serious reasons to ask about snprintf() using…

1. I found this _snprintf() in one old driver

2. I see it inside stack in Crash Dump which I was asked to check.

3. My opinion, this snprintf() may be suspected as reason for crash. But long history and really huge number of success working driver instances whispers me continue searching - problem is other.

There are reasons.
By the way, crash occurs in DPC.

Regards,
MG.


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

>the police aren’t going to come and arrest you.



OMG - I just imagine someone getting arrested by NTDEV police for calling unsafe function
(not using KMDF, sharing memory or otherwise getting at odds with “the best practices” of the day),
and being brought in front of “The Hanging Judge”

Anton Bassov

I’d stay away from the calling C runtime directly whenever possible. For
formatted string printing, I use:

RtlStringCchPrintfW()

On Thu, May 24, 2018 at 12:17 PM xxxxx@hotmail.com <
xxxxx@lists.osr.com> wrote:

>the police aren’t going to come and arrest you.


>
>
> OMG - I just imagine someone getting arrested by NTDEV police for calling
> unsafe function
> (not using KMDF, sharing memory or otherwise getting at odds with “the
> best practices” of the day),
> and being brought in front of “The Hanging Judge”
>
>
>

Anton Bassov


NTDEV is sponsored by OSR

Visit the list online at: <
http://www.osronline.com/showlists.cfm?list=ntdev\>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>


Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to
archiving. Nothing else really matters.
</http:>

xxxxx@intel.com wrote:

The question is easy: Is it allowed using C run-times such as _snprintf() in Kernel Driver?

Yes.  The library libcntpr.lib contains a virtually complete
implementation of the C run-time library for kernel drivers.  Just about
the only major omission is file I/O.

Note that I am not arguing that this is the BEST option, but it is
available.

 

Other (sub)question: Is it allowed using _snprintf() on DISPATCH_LEVEL or PASSIVE_LEVEL only?

Anything that uses Unicode requires PASSIVE_LEVEL.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> Use of string insertion (%s, %ws, %wZ, etc) in a format string, regardless of

API (xprintf, safe string functions RtlUnicodeStringXxx, etc) requires
PASSIVE_LEVEL. If you stick to other types, dispatch level and above is
allowed.

d

Doron, even %s requires PASSIVE? (when both source and destination are non-paged of course). Looks like I’m not alone surprised…

–pa

*MY* understanding was that the IRQL PASSIVE_LEVEL restriction only applied to UNICODE. This could have changed, or I could be wrong.

Peter
OSR
@OSRDrivers

For “the police aren’t going to come and arrest you” :

In those huge bureaucratic places, you cannot “modernize” something ugly or worth improvement. They have procedures. An issue must be opened, prioritized, scheduled, assigned (no, you can’t just do it yourself!) only then you get permit to fix. And then - code reviews and tests. There has to be a big deal: violation of a known rule or security flaw. Else it just stays there.

Regards,
– pa

I can never remember all of the details, it could very well be Unicode only needs passive while ansi string insertion is fine at any IRQL. No idea what ANSI_STRING would require though…

d

-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@osr.com
Sent: Thursday, May 24, 2018 12:48 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Using snprintf() inside Driver



MY understanding was that the IRQL PASSIVE_LEVEL restriction only applied to UNICODE. This could have changed, or I could be wrong.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

I guess there’s some logic to that. You don’t what people randomly changing shit to make it more attractive.

Peter
OSR
@OSRDrivers

Well, the idea in itself is perfectly reasonable - as they say, if it ain’t broke don’t fix it. After all,
don’t forget that writing any code is potentially fraught with introducing bugs. Therefore, what is the point of taking the risk of introducing new bugs to the code that, despite its obvious shortcomings and rusty spots, works just fine ???

Anton Bassov

So, let’s hope our colleague Michael G. won’t need to worry.
The libcntpr.lib will stay, narrow strings won’t become UTF-8 or something else.

– pa

Thank a lot for really interesting recommendations and discussion!

I continued working for problem. (For example, I found in Dump that it’s seen code segment with output_l() which called from nt!snprint() was damaged (swapped?).

I have some additional questions:

  1. One of the line which return me !vm command is:


Free System PTEs: 4294977283 (17179909132 Kb)

******* 70592 kernel stack PTE allocations have failed ******

Unfortunately there is not significant information about “PTE allocations have failed” problem in Inet. But probably it was hardware problem only? :slight_smile:

  1. I try to find more information about using libcntpr.lib inside driver and way it may help. There is no information about it target using in Inet.

  2. By the way, _snprintf() in the map resolved by ntoskrnl:ntoskrnl.exe:

0001:0059a8ea _snprintf 000000014059b8ea f ntoskrnl:ntoskrnl.exe

0003:000004d8 __imp__snprintf 00000001406184d8 ntoskrnl:ntoskrnl.exe

I try to understand way its using inside driver (in condition of control output size) may cause crash?

On May 28, 2018, at 1:26 AM, xxxxx@intel.com wrote:
>
> I continued working for problem. (For example, I found in Dump that it’s seen code segment with output_l() which called from nt!snprint() was damaged (swapped?).

Well, I don’t think you have showed us any of the dump here, so all of us are just guessing blindly. Show us the dump analysis and the code you called, and perhaps one of us can spot the flaw.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.