On Mon, 2017-03-27 at 05:26 -0700, sa wrote:
> Dear Martin,
<snip>
> > > 2. and want to perform a check if the memory allocated to *p1 is between
> > > range (0 to 255)
> > > 3. and for q between p-q <4 && q between range (0 to 255)
> > > 4. and also check if p=q if i free p after allocation and then allocate
> > q.
> >
> > If you want to allocate memory in your model I would recommend using
> > malloc / free as you will then get leak checking and the rest of the
> > memory allocation checks.
> >
> > *My aim here is to write some formula's or constraints like*
> *(1. for p1 using malloc, anywhere in the heap ---------p1 belongs between
> 0 to 255*
> * 2. p2 using malloc ------p1-p2 <4 && p2 Belongs **between ** 0 to255)*
Pointer arithmetic like this is supported but malloc will return
non-overlapping segments so I'm not sure this can occur.
> *and implement them so that the memory allocated using malloc is random and
> not as obvious as it is in CBMC. *
> *If i have not mistaken then CBMC just allocates memory chunk after chunk
> when i use malloc, i want to make this allocation random so that
> vulnerability doesnt occur. Please let me know if there is a way to do
> this.*
>
> *Thanks in advance...*
So the way memory allocation is modelled in CPROVER is that it uses a
number of 'blocks' each of which is writable at a (large) number of
offsets. Each call to malloc (__CPROVE_malloc specifically) creates a
new one of these. Reads and writes need to know the block and offset.
So that pointer arithmetic works easily and so that some type unsafe
access to pointers work, we pack these into pointer values. This will
give the impression of sequentially allocated blocks while in practice
the memory model doesn't assume a contiguous address space. It's not an
ideal system but it works reasonably well. Errors that could result in
memory "corruption" can be caught with --bounds-check and
--pointer-check.
Your question seems to be about the particular bit patterns used for
pointers. I'm not sure these are actually accessible in ISO C without
undefined behaviour. Thus programs that depend on these are likely to
be non-portable (at best) or unstable (at worst) given things like ASLR.
Changing the bit pattern we use would be possible but might require
changes at the encoding level which is not simple. Alternatively,
allocate one block with malloc and then hand out parts of it as you
want, giving the non-deterministic behaviour you want.
Cheers,
- Martin