Checked C?

Checked C?

[Sandy Harris]

Slashdot reports that Microsoft have come up with something they call
"checked C". It claims to prevent a wide variety of memory & pointer
bugs, using a mix of compile-time and run-time checks, at moderate
overheads.

Implementation is as extensions to Clang so it might be hard to apply
to the kernel which I think has some GNU-isms. Perhaps still worth a
look?

Paper describing it is at:
https://www.microsoft.com/en-us/research/publication/checkedc-making-c-safe-by-extension/
Code is at:
https://github.com/Microsoft/checkedc

Re: Checked C?

[Greg KH]

On Sun, Sep 09, 2018 at 08:22:44AM -0400, Sandy Harris wrote:
> Slashdot reports that Microsoft have come up with something they call
> "checked C". It claims to prevent a wide variety of memory & pointer
> bugs, using a mix of compile-time and run-time checks, at moderate
> overheads.
> 
> Implementation is as extensions to Clang so it might be hard to apply
> to the kernel which I think has some GNU-isms. Perhaps still worth a
> look?

The kernel builds just fine using Clang for some architectures.  The
pixel phones have been using it for a few years now.

And if you wish to work on converting the kernel to use these
extensions, please go ahead, that would be a great research project!

greg k-h

Re: Checked C?

[Theodore Y. Ts'o]

On Sun, Sep 09, 2018 at 02:59:12PM +0200, Greg KH wrote:
> On Sun, Sep 09, 2018 at 08:22:44AM -0400, Sandy Harris wrote:
> > Slashdot reports that Microsoft have come up with something they call
> > "checked C". It claims to prevent a wide variety of memory & pointer
> > bugs, using a mix of compile-time and run-time checks, at moderate
> > overheads.
> > 
> > Implementation is as extensions to Clang so it might be hard to apply
> > to the kernel which I think has some GNU-isms. Perhaps still worth a
> > look?

What would be really interesting would be implementing the Microsoft
extensions as Clang plugins, so the kernel changes don't require
distributions to ship a modified Clang.

Whoever does this will need to remember that kernel modifications need
to work with:

   * Clang with the extensions

   * Clang without the extensions (in case the extensions are Clang
     version dependent, and the system has a Clang which is too old).

   * Gcc without the extensions

We've been doing that sort of thing already, using CPP magic, so there
are plenty of examples about ways of doing that.

    	       	     	       	  	- Ted

Re: Checked C?

[Boris Lukashev]

Quick glance over the paper describes type and bounds checks
attempting to make access safer at compile and runtime via new
syntax... The caveat of "The safety provided by checked pointers can
be thwarted by unsafe operations, such as writes to traditional
pointers" leads to some immediate coverage concerns.
Doesn't grsecurity/PaX already do things like this with GCC plugins?
My understanding is that analogous functionality is available with
GCC, and wouldn't require adopting MSFT's take on "how C should be" in
Linux.
If the kernel is to move to Clang (which seems to be a direction which
Google and others are going), then implementing LLVM passes to do such
things may not require explicit syntax to declare these pointers, but
more likely exceptions to default use of safe types.

-Boris

On Sun, Sep 9, 2018 at 12:56 PM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Sun, Sep 09, 2018 at 02:59:12PM +0200, Greg KH wrote:
>> On Sun, Sep 09, 2018 at 08:22:44AM -0400, Sandy Harris wrote:
>> > Slashdot reports that Microsoft have come up with something they call
>> > "checked C". It claims to prevent a wide variety of memory & pointer
>> > bugs, using a mix of compile-time and run-time checks, at moderate
>> > overheads.
>> >
>> > Implementation is as extensions to Clang so it might be hard to apply
>> > to the kernel which I think has some GNU-isms. Perhaps still worth a
>> > look?
>
> What would be really interesting would be implementing the Microsoft
> extensions as Clang plugins, so the kernel changes don't require
> distributions to ship a modified Clang.
>
> Whoever does this will need to remember that kernel modifications need
> to work with:
>
>    * Clang with the extensions
>
>    * Clang without the extensions (in case the extensions are Clang
>      version dependent, and the system has a Clang which is too old).
>
>    * Gcc without the extensions
>
> We've been doing that sort of thing already, using CPP magic, so there
> are plenty of examples about ways of doing that.
>
>                                         - Ted



-- 
Boris Lukashev
Systems Architect
Semper Victus