Is it safe to use atoi in kernel mode?

I’ve seen some code using functions like atoi rather than RtlUnicodeStringToInteger and was wondering if that’s safe, are there any cons about using it?

There is a virtually complete implementation of the C standard library for kernel drivers, except for things like I/O, provided by the library libcntpr.lib. It’s been there for decades. Of course it’s “safe”, as long as you are aware of which C runtime library functions are problematic in the first place.

Is it safe to call atoi at Apc,dpc level? Dirql?
For RtlUnicodeStringToInteger we know the answer.

I personally see kernel c library same as any undocumented functions.

1 Like

Well, I’m somewhere between Mr. Pisarev and Mr. Roberts on this one.

First, “atoi” is an ancient function, which most people would consider “deprecated” or “obsolete” in ANY code. In kernel-mode code, I like it even less.

So, if there’s an alternative, like RtlUnicodeStringToInteger (perhaps) in this case, then I’d strongly recommend using that. It satisfies Mr. Pisarev’s constraint of being documented, while working on counted character strings properly (remember… the buffer in a UNICODE_STRING structure isn’t necessarily NULL terminated), and being “modern.”

Having written all that, I have never hesitated to use the CRTL functions that are in kernel mode, any more than I hesitate to use the ones in user mode (and, I am increasingly hesitant to use many of those due to their age/status, as previously noted).

Peter

how could a function that can’t fail (based on its signature) and can’t raise exceptions unless passed invaid parameters be a problem to call?

it might not produce the correct result and there is almost no reason to attempt it in KM, but is is not dangerious]

how could a function that can’t fail (based on its signature) and can’t raise exceptions unless passed
invaid parameters be a problem to call?

Actually, this “assignment” is not as complex as it may seem to be at the first glance, at least not in the Windows kernel…

The only thing the target function has to do in order to become potentially problematic in some cases is to touch the pageable code section. To begin with, you may have to “see a Big Bang” if you call it at IRQL>=DISPATCH_LEVEL, for the obvious reasons. To make it even more interesting, consider what may happen if you invoke it on the paging IO path to the pagefile, and the page of interest happens to be swapped out at the moment…

Please note that I am just answering your question as it has been presented - I do not claim that the function in question actually calls the pageable code…

Anton Bassov

how could a function that can’t fail (based on its signature) and can’t raise exceptions unless passed invaid parameters be a problem to call?

Seriously? One example: You could, ah, call it on an improperly terminated string and as a result blue screen the system.

Why would anyone use this function, for anything, in 2020?

Peter

Passing invalid parameters to just about any of the documented kernel apis
can result in a BSOD. Arguing against using atoi on that basis is odd. The
other argument, that there is no good reason to convert a string value to
an integer in a driver is equally odd. There are many good reasons which is
why the unicode version exists.

Mark Roddy

Are there good reasons to convert strings to integers in KM? well, maybe

Usually, that means that you are processing some kind of protocol (IPC, file, network etc.) rather than processing the fundamental IO that needs to be processed in KM. So usually that means you are doing work in the ‘wrong’ place, but anyways

In my own practice, I never call any CRT functions; of if I do, i always provide a specific implementation in source or assembly so that that complier cannot get it wrong or change it under mey feet

Are there good reasons to convert strings to integers in KM?

Well, it depends on what you call a “string” in this context. If you mean a “classical” string, i.e. a NULL-terminated sequence of one-byte ANSI characters (i.e. the kind of string that atoi() deals with), one should, probably, recall that NT kernel has been natively thinking of a string
as of UNICODE_STRING structure, i.e. as of a sequence of two-byte unicode characters that its preceded by the character count, since its very inception.

At this point one may start wondering if RtlInitAnsiString() - RtlAnsiStringToUnicodeString() sequence may be of use whenever a “classical” string is encountered, because a plethora of well-documented RtlXXX… kernel functions for dealing with strings becomes immediately available to you once you have converted your string to UNICODE_STRING, which, in turn, eliminates any need for asking “Is it safe
to use atoi in kernel mode” et al questions

i always provide a specific implementation in source or assembly so that that complier cannot get it wrong or change it under mey feet

Assuming that you are speaking about well-defined built-in CRT functions like strcpy() or strcat(), how can a complier possibly “get it wrong”, let alone “change it under your feet”???

Anton Bassov