Douglas Walls' Weblog

Monday February 27, 2006

IPL32 to LP64, Number One Porting Issue

ILP32 - integer, long, and pointer types are 32-bits in size
LP64 - long and pointer types are 64-bits in size, int remains 32-bitsin size

What's the number one issue with porting 32-bit application (ILP32) to a
64-bit environment (LP64)?

• Review all data structures and interfaces to verify that these are still valid in the 64-bit environment.
 
• Include <inttypes.h> in your code to pull in the _ILP32 or_LP64 definitions as well as many basic derived types.  Systems programsmay wish to include <sys/types.h>(or at a minimum, <sys/isa_defs.h>) to obtain the definitions of _ILP32 or _LP64.
 
• Move function prototypes and external declarations with non-local scope to headers and include these headers in your code.
 
• Run lint using the -errchk=longptr64,signext option.  Review each warning individually.  Keep in mind that not all warnings require a change to the code.  Depending on the changes, run lint again in both 32-bit and 64-bit modes, -Xarch=generic64.
 
• Compile code as both 32-bit and 64-bit.
 
• Test the application by executing the 32-bit version on the32-bit operating system, and the 64-bit version on the 64-bit operating system.  With Solaris you can also test the 32-bit version on the64-bit operating system.

• Migrating to Solaris 64-bit: 32-bit Applications and Data Model
 
• Some considerations for Device Drivers
 
• Converting Applications for a 64-Bit Environment
 
• Solaris 64-bit Developer's Guide
 
• Why LP64?

Tuesday February 21, 2006

Catching security vulnerabilities in C code

Check out what Sun Studio C compiler has provided for detect coding practices that could lead to security vulnerabilities. Specifically, Sun added security vulnerability checking to lint, the C program checker.

Below is an overview of the flag to specify on the lint command to obtain security vulnerability checking. And here is a testimonial about how it is used in the Solaris sources.

-errsecurity=v

lint -errsecurity=core

Checks for source code constructs that are almost always either unsafe or difficult to verify. Checks at this level include:

• Use of variable format strings with the printf() and scanf()family of functions
• Use of unbounded string (%s) formats in scanf() functions
• Use of functions with no safe usage: gets(), cftime(),ascftime(), creat()
• Incorrect use of open() with O_CREAT
  

Consider source code that produces warnings at this level to be abug.  The source code in question should be changed. In all cases, straightforward safer alternatives are available.

lint -errsecurity=standard

Includes all checks from the core level plus constructs that may be safe, but have better alternatives available.  This level is recommended when checking newly-written code. Additional checks at this level include:

• Use of string copy functions other than strlcpy()
• Use of weak random number functions
• Use of unsafe functions to generate temporary files
• Use of fopen() to create files
• Use of functions that invoke the shell
  

Replace source code that produces warnings at this level with new or significantly modified code.  Balance addressing these warnings in legacy code against the risks of destabilizing the application.

lint -errsecurity=extended

Contains the most complete set of checks, including everything from the Core and Standard levels.  In addition, a number of warnings are generated about constructs that may be unsafe in some situations. The checks at this level are useful as an aid in reviewing code, but need not be used as a standard with which acceptable source code must comply.  Additional checks at this level include:

• Calls to getc() or fgetc() inside a loop
• Use of functions prone to pathname race conditions
• Use of the exec() family of functions
• Race conditions between stat() and other functions

Review source code that produces warnings at this level to determine ifthe potential security issue is present.

Sunday February 12, 2006

c89 command on linux

Suns's compilers have previewed on linux, take a look here http://developers.sun.com/prodtech/cc/linux_index.html.

This is just a preview, we have a long way to go before we can or will make this a product offering. On the way to doing that we got some feed back on the SDN, that our c89 command should work like the c89 command encountered on Linux.

Specifically, the following simple test case gets an error using the c89 command from Sun:

long long foo;

But the c89 command on linux accepts this declaration.

Why does the c89 (/bin/c89) command on linux allow this? It makes no sense at all, the entire purpose of the c89 command is to provide a portable compilation environment to those conforming to SUSv3. SUSv3 support the 1994 ISO C standard. long long is not an allowed type in the ISO 1994 C standard.

Sun is porting it's compiler from Solaris it Linux. On Solaris, Sun supports SUSv2 which defines the c89 command. We implement the c89 command by being pedantic about the 1994 C ISO language as required by SUSv2, and thus long long must not be accepted as a legal type. There are conformance tests that check this, and you cannot pass them without producing an error message.

We can change the error message into a warning and thus pass the conformance test and still present a consistent interface across Solaris and Linux.

But what we do not yet understand, is why /bin/c89 on linux does not produce even a warning message for the above program ...