From sanghu1790 at gmail.com  Wed Jun  1 09:54:20 2022
From: sanghu1790 at gmail.com (Sangharatna Godboley)
Date: Wed, 1 Jun 2022 14:24:20 +0530
Subject: [klee-dev] Klee terminating oddly
In-Reply-To: <CAF=ATfP_TPV8KbzpRBqw9y-HSmJnnOzgRA0VrT4DdquyF0EKSw@mail.gmail.com>
References: <CAF=ATfP_TPV8KbzpRBqw9y-HSmJnnOzgRA0VrT4DdquyF0EKSw@mail.gmail.com>
Message-ID: <CAFshPhsEVWepuPOUq_VJUBJoBWNpeSMts1COa73SLw-o-qQ2ZA@mail.gmail.com>

Hi Shaheen,

My suggestion:

Try running with below command

klee --max-time=60 --watchdog binmult.bc

Usually max time count is in seconds.

Please check and let us know if it works.

Thanks
Sanghu

On Wed, 1 Jun 2022 at 1:50 PM, Shaheen Cullen-Baratloo <shaheen at gmail.com>
wrote:

> Hi,
>
> I'm running Klee on a program that performs binary multiplication:
> -------
>
> #include <stdio.h>
>
> #include <klee/klee.h>
>
>
> int binmult(long binary1, long binary2)
>
> {
>
>
>     long multiply = 0;
>
>     int digit, factor = 1;
>
>     while (binary2 != 0)
>
>     {
>
>         digit =  binary2 % 10;
>
>         if (digit == 1)
>
>         {
>
>             binary1 = binary1 * factor;
>
>
>             int i = 0, remainder = 0, sum[20];
>
>             int binaryprod = 0;
>
>
>             while (binary1 != 0 || binary2 != 0)
>
>             {
>
>                 sum[i++] =(binary1 % 10 + binary2 % 10 + remainder) % 2;
>
>                 remainder =(binary1 % 10 + binary2 % 10 + remainder) / 2;
>
>                 binary1 = binary1 / 10;
>
>                 binary2 = binary2 / 10;
>
>             }
>
>             if (remainder != 0)
>
>                 sum[i++] = remainder;
>
>             --i;
>
>             while (i >= 0)
>
>                 binaryprod = binaryprod * 10 + sum[i--];
>
>             multiply = binaryprod;
>
>         }
>
>         else
>
>             binary1 = binary1 * factor;
>
>         binary2 = binary2 / 10;
>
>         factor = 10;
>
>     }
>
>     return 0;
>
> }
>
>
> int main() {
>
>
>   long binary1;
>
>   klee_make_symbolic(&binary1, sizeof(binary1),
> "2b6700e0c99f4934b960a895efa60e22");
>
>
>   long binary2;
>
>   klee_make_symbolic(&binary2, sizeof(binary2),
> "f55f4c1e835743c3b415e6f1290b372f");
>
>   return binmult(binary1, binary2);
>
> }
>
> -------
>
> I'm compiling it with
>
> clang-6.0 -I /app/klee/include -emit-llvm -c -g -O0 -Xclang
> -disable-O0-optnone binmult.c
>
> and running klee with
>
> klee --max-time=1min --watchdog binmult.bc
>
>
> On a computer running Ubuntu 22.04, running this occasionally works
> properly but mostly gives me a message about solver failure, and then
> trying to check the output gives incomplete results (there's no number for
> paths covered, for example):
>
> -------
>
> KLEE: WARNING: KLEE: WATCHDOG: time expired, attempting halt via INT
>
>
> KLEE: WARNING: Unexpected solver failure. Reason is "interrupted from
> keyboard,"
>
>
>
> /usr/lib/llvm-6.0/lib/libLLVM-6.0.so.1(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1a)[0x7ff50e16471a]
>
>
> /usr/lib/llvm-6.0/lib/libLLVM-6.0.so.1(_ZN4llvm3sys17RunSignalHandlersEv+0x3e)[0x7ff50e1627ee]
>
> /usr/lib/llvm-6.0/lib/libLLVM-6.0.so.1(+0x92097d)[0x7ff50e16297d]
>
> /lib/x86_64-linux-gnu/libc.so.6(+0x37840)[0x7ff50d395840]
>
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7ff50d3957bb]
>
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7ff50d380535]
>
> klee(+0xbf782)[0x56326e66a782]
>
> klee(+0xc06cf)[0x56326e66b6cf]
>
> klee(+0xc3fb0)[0x56326e66efb0]
>
> klee(+0xc4864)[0x56326e66f864]
>
> klee(+0xc29f5)[0x56326e66d9f5]
>
> klee(+0xb8387)[0x56326e663387]
>
> klee(+0x838ed)[0x56326e62e8ed]
>
> klee(+0x4d08e)[0x56326e5f808e]
>
> klee(+0x564b6)[0x56326e6014b6]
>
> klee(+0x5be21)[0x56326e606e21]
>
> klee(+0x5c6a5)[0x56326e6076a5]
>
> klee(+0x2d919)[0x56326e5d8919]
>
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7ff50d38209b]
>
> klee(+0x3928a)[0x56326e5e428a]
>
> KLEE: WARNING: KLEE: watchdog exiting (no child)
>
> -------
>
>
> On my 2019 MacBook Pro running macOS Monterey, the error happens very
> occasionally but it usually runs and terminates fine. I am running Klee in
> a Docker image, so it's extra strange that the two machines run
> differently. Does anyone have any idea why this could be happening, and how
> to get the path count/test count to display properly when the program halts?
>
>
> Thanks,
>
> Shaheen
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>
-- 
---------------------
Thanks & Regards,

Dr. Sangharatna Godboley,
Ph.D.(NITR), Post-Doc(NUS),
Assistant Professor,
IEEE and ACM Member,
ER-22 (Web Chair),
Department of Computer Science and Engineering,
National Institute of Technology (NIT) Warangal,
Telangana, Pin- 506004, India.
Mobile: +91-7013306805
Vidwan Website <https://nitw.irins.org/profile/154056>
-------------- next part --------------
HTML attachment scrubbed and removed

From f.busse at imperial.ac.uk  Wed Jun  1 10:13:40 2022
From: f.busse at imperial.ac.uk (Frank Busse)
Date: Wed, 1 Jun 2022 10:13:40 +0100
Subject: [klee-dev] Klee terminating oddly
In-Reply-To: <CAF=ATfP_TPV8KbzpRBqw9y-HSmJnnOzgRA0VrT4DdquyF0EKSw@mail.gmail.com>
References: <CAF=ATfP_TPV8KbzpRBqw9y-HSmJnnOzgRA0VrT4DdquyF0EKSw@mail.gmail.com>
Message-ID: <20220601101340.4eb299e3@haengemotte.localdomain>

Hi,


On Tue, 31 May 2022 13:44:49 -0700
Shaheen Cullen-Baratloo <shaheen at gmail.com> wrote:

> and running klee with
> 
> klee --max-time=1min --watchdog binmult.bc
> 
> 
> On a computer running Ubuntu 22.04, running this occasionally works
> properly but mostly gives me a message about solver failure, and then
> trying to check the output gives incomplete results (there's no
> number for paths covered, for example):

Looks like KLEE is stuck in the solver when the watchdog kills it. You
can try running it without watchdog and specifying a threshold for the
solver invocations, e.g.:

klee --max-time=1min --max-solver-time=30s run.bc


Kind regards,

Frank


From gwpublic at wp.pl  Sat Jun  4 22:26:47 2022
From: gwpublic at wp.pl (gwpublic at wp.pl)
Date: Sat, 4 Jun 2022 23:26:47 +0200
Subject: [klee-dev] Idea: Klee experiment on Coreutils reimplementation in
	Rust
Message-ID: <CAH-uPsyKwVenX_PbZM++qcqQeHO-kzYisDpZKVsgM2p+eE-tgA@mail.gmail.com>

Klee got famous with coreutils experiments.

As they reimplement coreutils in Rust, maybe it would be interesting
to prepare e.g. Dockerfile allowing to repeat experiment but on those:
https://github.com/uutils/coreutils


From 1106929795 at qq.com  Mon Jun  6 15:06:47 2022
From: 1106929795 at qq.com (=?gb18030?B?t7+6z777?=)
Date: Mon, 6 Jun 2022 22:06:47 +0800
Subject: [klee-dev] Errors when files unconform to the format!
Message-ID: <tencent_E7F2E732F9AE61172A4C7E8C090992670B08@qq.com>

Hello!

I recently tried to use Klee to detect a project that handles PNG images. I use sym files to generate input files, but the generated files do not necessarily meet the format requirements of PNG pictures. Therefore, I hope to fix some characters to make the generated files conform to the format.

I found in the past mailing list that you mentioned that it can be specified through the file in POSIX, but I can't figure out which file can be set. So can you tell me the specific file path.

Similarly, I want to confirm whether Klee is also used in POSIX_ Assume (), or there are other functions.

If you are willing to give a simple example, it would be great.


Thanks and regards,
yukai
-------------- next part --------------
HTML attachment scrubbed and removed

From c.cadar at imperial.ac.uk  Sat Jun 11 21:55:03 2022
From: c.cadar at imperial.ac.uk (Cristian Cadar)
Date: Sat, 11 Jun 2022 21:55:03 +0100
Subject: [klee-dev] 3rd International KLEE Workshop on Symbolic Execution --
 submission site NOW OPEN
In-Reply-To: <3c0f0a23-7252-b11f-9f2c-beb59e56c986@imperial.ac.uk>
References: <3c0f0a23-7252-b11f-9f2c-beb59e56c986@imperial.ac.uk>
Message-ID: <aec3c71c-45c6-4f05-3d0e-cb7774f78e30@imperial.ac.uk>

Hi all,

The submission site for the 3rd KLEE Workshop is now OPEN!  The deadline 
is in about one month, on 12th July.  We are looking forward to your 
interesting presentation and poster proposals!  Remember that the 
workshop has no proceedings, so you can present both published and 
ongoing work.
https://srg.doc.ic.ac.uk/klee22/cfpresentations.html
https://srg.doc.ic.ac.uk/klee22/cfposters.html

Best,
Cristian, on behalf of the KLEE'22 Organising Team


-------- Forwarded Message --------
Subject: [klee-dev] 3rd International KLEE Workshop on Symbolic 
Execution -- 15-16 September, London and online
Date: Mon, 16 May 2022 23:00:20 +0100
From: Cristian Cadar <c.cadar at imperial.ac.uk>
To: klee-dev at imperial.ac.uk <klee-dev at imperial.ac.uk>

Hi all,

I'm very excited to announce the 3rd International KLEE Workshop on 
Symbolic Execution (KLEE 2022), taking place in London and online on 
15-16 September 2022:
https://srg.doc.ic.ac.uk/klee22/
https://twitter.com/kleesymex/status/1526310428485341187

The first two workshops were really great, with participants from around 
the world (over 80 to the first one in London, over 200 to the second 
one online) with an array of interesting keynotes, talks and posters:
https://srg.doc.ic.ac.uk/klee18/
https://srg.doc.ic.ac.uk/klee21/

I am looking forward to another one, so please consider contributing an 
interesting presentation and/or poster:
https://srg.doc.ic.ac.uk/klee22/cfpresentations.html
https://srg.doc.ic.ac.uk/klee22/cfposters.html

Big thanks to Daniel, Frank, Martin, Hassan and Jamie for their role as 
co-organizers of this 3rd edition!

Many thanks to Bloomberg, Samsung, Google and Imperial College London 
for their sponsorship!  To keep registration costs low, we are still 
looking for a few more sponsors, so if your organization is interested 
in sponsoring the workshop, please let me know.

Looking forward to seeing many of you in September!
Cristian

_______________________________________________
klee-dev mailing list
klee-dev at imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev


From mvanotti at dc.uba.ar  Thu Jun 16 18:55:55 2022
From: mvanotti at dc.uba.ar (Marco Vanotti)
Date: Thu, 16 Jun 2022 10:55:55 -0700
Subject: [klee-dev] Working with fixed memory locations.
Message-ID: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>

Hi klee-dev!

I am new to KLEE, and have a question about using it with one of my
programs.

I have a program that when compiled, adds a program header that loads a
data blob into a fixed memory location.

This means that my program has this fixed memory location hardcoded all
around the place (also this blob has references to itself).

I would like to load my program in KLEE to get a better understanding of
how it works. The problem I am facing is that I have no idea how to make
KLEE understand that I need this blob mapped in that address.

This are the things I've tried:

* Using wllvm/gclang to get the full program linked together, following my
link script, then extracting the bc and running that with KLEE. This didn't
work. KLEE complains that the pointers are invalid.

* Manually embedding the blob into my program as an array, then calling
`mmap` with `MAP_FIXED` to map the area that I want and copying over the
blob.

The issue here is that MAP_FIXED returns EPERM because probably the address
range I am trying to map is already mapped.


* Setting the KLEE deterministic allocations to encompass the range that I
care about, then doing a big `malloc` and making sure that my range is
inside that malloc chunk.

For this last one, I am using flags like:
--allocate-determ --allocate-determ-start-address=8404992
--allocate-determ-size=3145728

One of the things that I see is that KLEE fails to mmap big chunks (in the
order of 100MiB). But even if I decrease the size, I still get failures
when I try to assert things like:

uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
klee_assert(BASE_ADDR >= malloc_addr);
klee_assert(BASE_ADDR < malloc_addr + malloc_size);

------

Something that might be relevant is that in reality I need two of these
blobs loaded into different regions of memory, but so far I can't even get
to load one. And they are not too far apart from each other, so if, for
example, the malloc approach works, I could just increase the size and make
the two allocations.

One thing that might complicate things, is that these addresses might
collide with where KLEE tries to load the program. I don't know how to deal
with that either.

Any advice on how to tune KLEE for this use case?

Best Regards,
Marco
-------------- next part --------------
HTML attachment scrubbed and removed

From c.cadar at imperial.ac.uk  Thu Jun 16 20:17:55 2022
From: c.cadar at imperial.ac.uk (Cristian Cadar)
Date: Thu, 16 Jun 2022 20:17:55 +0100
Subject: [klee-dev] How to determine the concretized size when dealing
 with malloc()
In-Reply-To: <CA+gEVMt6cZ0WjjTx6+WmY3gJHsdoczYXSawEMB+bNDRjKu75_A@mail.gmail.com>
References: <CA+gEVMt6cZ0WjjTx6+WmY3gJHsdoczYXSawEMB+bNDRjKu75_A@mail.gmail.com>
Message-ID: <66624e5c-6e51-9034-5044-a4064eaaca6d@imperial.ac.uk>

Hi Austin,

Sorry to see that nobody has answered your email.  I'm not sure what you 
are trying to do though.  Are you trying to make KLEE choose a specific 
size?

(That code is a bit broken, btw.  We fixed it in some extensions but 
haven't managed to merge the changes into the mainline yet.)

Best,
Cristian

On 18/04/2022 10:55, Wang Austin wrote:
> Hello klee-dev members,
> 
> I'm working on a project involving KLEE and SMT solvers. We are 
> collecting queries from KLEE using the v2.2 klee docker image with the 
> "--use-query-log=solver:smt2" option. I observed that the queries 
> collected are not always complete when KLEE dealing with malloc(), and 
> KLEE would throw an error:
> ...
> KLEE: ERROR: tif_unix.c:334: concretized symbolic size
> ...
> 
> I'm expecting to determine the concretized size for malloc() in 
> accordance with the value of size in the actual execution and check if 
> the queries are more complete in this case.
> 
> I checked the source code (klee/lib/Core/Executor.cpp), finding that 
> KLEE would "optimize" when the size is symbolized. And I tried the 
> "--allocate-determ" option for memory management according to the 
> document, which I thought would determine the size to a specific value 
> and resolve the error, whereas, it doesn?t seem to be running right, 
> here are the results.
> 
> 1) Normal execution:
> ...
> KLEE: ERROR: tif_unix.c:334: concretized symbolic size
> KLEE: NOTE: now ignoring this error at this location
> KLEE: seeding done (0 states remain)
> ...
> 
> 2) Execution with --allocate-determ=1 --allocate-determ-size=10:
> ...
> KLEE: ERROR: tif_unix.c:334: concretized symbolic size
> KLEE: NOTE: now ignoring this error at this location
> KLEE: seeding done (0 states remain)
> KLEE: Deterministic memory allocation starting frow 0x7ff30000000
> ...
> 
> The size still?got concretized or perhaps I misunderstood the usage of 
> the "--allocate-determ" option.
> 
> I?m wondering if there is a way to "determine the concretized size to a 
> specific value when malloc()" or "NOT to?optimize?the size", so I can 
> collect queries with more completeness using KLEE.
> 
> Best Regards,
> Austin Wang
> 
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev


From c.cadar at imperial.ac.uk  Thu Jun 16 20:28:14 2022
From: c.cadar at imperial.ac.uk (Cristian Cadar)
Date: Thu, 16 Jun 2022 20:28:14 +0100
Subject: [klee-dev] KLEE for stateful C API
In-Reply-To: <CABaeavNuq_9vS6xGEHwBjqptqyOZtSk0-9_pXSxa70S6NNd9vg@mail.gmail.com>
References: <CABaeavNuq_9vS6xGEHwBjqptqyOZtSk0-9_pXSxa70S6NNd9vg@mail.gmail.com>
Message-ID: <6fda7524-9277-b5ee-8257-7b6ce8b89f81@imperial.ac.uk>

Hi Niklaus,

There is no obvious improvement to recommend for the general case.  Of 
course, search heuristics have an important influence on which API 
sequences are explored first.  There is also a lot of research into this 
problem: I would recommend Randoop 
(https://homes.cs.washington.edu/~mernst/pubs/feedback-testgen-icse2007.pdf) 
and EvoSuite 
(https://www.evosuite.org/wp-content/papercite-data/pdf/esecfse11.pdf) 
as starting points.

Best,
Cristian

On 02/05/2022 08:50, Niklaus Leuenberger wrote:
> Hello klee-dev members,
> 
> I'm currently testing out a few approaches on how to test and fuzz a
> stateful C API. In the process thereof I found KLEE and am fascinated
> by it. I managed to get it to work and am now asking if my approach is
> ok or if it has some major drawbacks or problems.
> 
> Let's suppose we have following simple but buggy stateful API:
> ---
> #include <assert.h>
> static int g_state;
> void setState(int state) {
>      g_state = state;
> }
> void run(void) {
>      if (g_state == 123) {
>          assert(0);
>      }
> }
> ---
> If the state is set to 123 and then run() is invoked the placed assertion fails.
> 
> For this I have written following KLEE harness:
> ---
> #include "klee/klee.h"
> #include "buggy_api.h"
> int main(void) {
>      for (int i = 0; i < 2; ++i) { // sequentially call 2 APIs
>          int f_select = klee_choose(2); // what API to call
>          if (f_select == 0) {
>              int state = 0;
>              klee_make_symbolic(&state, sizeof(state), "state");
>              setState(state);
>          } else if (f_select == 1) {
>              run();
>          }
>      }
>      return 0;
> }
> ---
> 
> When running with KLEE, the sequence of calls necessary to trigger the
> assertion is found almost immediately. But when extending it with more
> functions, each doubles the runtime. So it scales rather poorly on
> larger APIs.
> Is this how I can use KLEE for checking an API? Or does someone have
> pointers to a better approach?
> 
> Best Regards,
> Niklaus Leuenberger
> 
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev


From m.carrasco at imperial.ac.uk  Thu Jun 16 20:43:12 2022
From: m.carrasco at imperial.ac.uk (Carrasco, Manuel G)
Date: Thu, 16 Jun 2022 19:43:12 +0000
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
Message-ID: <AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>

Hi Marco!
I have a program that when compiled, adds a program header that loads a data blob into a fixed memory location.
?I'm sorry to ask, but could you explain a bit more how this works? At first glance, I'd say that if any of this happens on a stage later than LLVM-IR, it may be hard to mimic in KLEE.

As far as I understand, when KLEE executes a LLVM-IR load instruction<https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>, it will try to find<https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191> the MemoryObjects (more than one if it is a symbolic pointer) that contain the address. Conceptually, you want KLEE to somehow have a MemoryObject at the hardcoded address.

One way to go could be modelling this as a LLVM-IR GlobalVariable at your fixed address with the content of your blob.  If this makes sense, you may want to check this function<https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648> and addExternalObject perhaps as well.

I apologise if you already know this!

Best regards,
Manuel.

________________________________
From: klee-dev-bounces at imperial.ac.uk <klee-dev-bounces at imperial.ac.uk> on behalf of Marco Vanotti <mvanotti at dc.uba.ar>
Sent: 16 June 2022 18:55
To: klee-dev <klee-dev at imperial.ac.uk>
Subject: [klee-dev] Working with fixed memory locations.

Hi klee-dev!

I am new to KLEE, and have a question about using it with one of my programs.

I have a program that when compiled, adds a program header that loads a data blob into a fixed memory location.

This means that my program has this fixed memory location hardcoded all around the place (also this blob has references to itself).

I would like to load my program in KLEE to get a better understanding of how it works. The problem I am facing is that I have no idea how to make KLEE understand that I need this blob mapped in that address.

This are the things I've tried:

* Using wllvm/gclang to get the full program linked together, following my link script, then extracting the bc and running that with KLEE. This didn't work. KLEE complains that the pointers are invalid.

* Manually embedding the blob into my program as an array, then calling `mmap` with `MAP_FIXED` to map the area that I want and copying over the blob.

The issue here is that MAP_FIXED returns EPERM because probably the address range I am trying to map is already mapped.


* Setting the KLEE deterministic allocations to encompass the range that I care about, then doing a big `malloc` and making sure that my range is inside that malloc chunk.

For this last one, I am using flags like:
--allocate-determ --allocate-determ-start-address=8404992 --allocate-determ-size=3145728

One of the things that I see is that KLEE fails to mmap big chunks (in the order of 100MiB). But even if I decrease the size, I still get failures when I try to assert things like:

uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
klee_assert(BASE_ADDR >= malloc_addr);
klee_assert(BASE_ADDR < malloc_addr + malloc_size);

------

Something that might be relevant is that in reality I need two of these blobs loaded into different regions of memory, but so far I can't even get to load one. And they are not too far apart from each other, so if, for example, the malloc approach works, I could just increase the size and make the two allocations.

One thing that might complicate things, is that these addresses might collide with where KLEE tries to load the program. I don't know how to deal with that either.

Any advice on how to tune KLEE for this use case?

Best Regards,
Marco
-------------- next part --------------
HTML attachment scrubbed and removed

From f.busse at imperial.ac.uk  Thu Jun 16 21:03:27 2022
From: f.busse at imperial.ac.uk (Frank Busse)
Date: Thu, 16 Jun 2022 21:03:27 +0100
Subject: [klee-dev] KLEE for stateful C API
In-Reply-To: <CABaeavNuq_9vS6xGEHwBjqptqyOZtSk0-9_pXSxa70S6NNd9vg@mail.gmail.com>
References: <CABaeavNuq_9vS6xGEHwBjqptqyOZtSk0-9_pXSxa70S6NNd9vg@mail.gmail.com>
Message-ID: <20220616210327.604ff0d4@haengemotte.localdomain>

Hi,


On Mon, 2 May 2022 09:50:23 +0200
Niklaus Leuenberger <niklaus.leuenb at gmail.com> wrote:

> For this I have written following KLEE harness:
> ---
> #include "klee/klee.h"
> #include "buggy_api.h"
> int main(void) {
>     for (int i = 0; i < 2; ++i) { // sequentially call 2 APIs
>         int f_select = klee_choose(2); // what API to call
>         if (f_select == 0) {
>             int state = 0;
>             klee_make_symbolic(&state, sizeof(state), "state");
>             setState(state);
>         } else if (f_select == 1) {
>             run();
>         }
>     }
>     return 0;
> }

What I find a little odd here is that you drop the constraints of the
global state every time you get f_select == 0. Is this supposed to be a
reset and if so, would everything afterwards not be covered by a
similar path starting from the initial state?

> When running with KLEE, the sequence of calls necessary to trigger the
> assertion is found almost immediately. But when extending it with more
> functions, each doubles the runtime. So it scales rather poorly on
> larger APIs.
> Is this how I can use KLEE for checking an API? Or does someone have
> pointers to a better approach?

Hard to give recommendations without more knowledge about the problem.
In general: KLEE tries to execute all paths - if your program has a lot
of paths, than that's the issue. ;) You can also play with KLEE's flags,
e.g. disable test generation (--write-no-tests) or use a less expensive
search strategy (--search=[dfs,bfs,random-state]).

You can also check KLEE's stats to see where it spends time or branches
heavily, see: https://klee.github.io/tutorials/testing-coreutils/ (Step
6).



Kind regards,

Frank


From c.cadar at imperial.ac.uk  Thu Jun 16 21:16:35 2022
From: c.cadar at imperial.ac.uk (Cristian Cadar)
Date: Thu, 16 Jun 2022 21:16:35 +0100
Subject: [klee-dev] Idea: Klee experiment on Coreutils reimplementation
 in Rust
In-Reply-To: <CAH-uPsyKwVenX_PbZM++qcqQeHO-kzYisDpZKVsgM2p+eE-tgA@mail.gmail.com>
References: <CAH-uPsyKwVenX_PbZM++qcqQeHO-kzYisDpZKVsgM2p+eE-tgA@mail.gmail.com>
Message-ID: <08b957bc-90d5-d305-843f-cb9353839e14@imperial.ac.uk>

You should look at the work of Alastair Reid / Google on this topic:
https://project-oak.github.io/rust-verification-tools/2021/07/14/coreutils.html

Best,
Cristian

On 04/06/2022 22:26, gwpublic at wp.pl wrote:
> Klee got famous with coreutils experiments.
> 
> As they reimplement coreutils in Rust, maybe it would be interesting
> to prepare e.g. Dockerfile allowing to repeat experiment but on those:
> https://github.com/uutils/coreutils
> 
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev


From m.nowack at imperial.ac.uk  Thu Jun 16 21:19:53 2022
From: m.nowack at imperial.ac.uk (Nowack, Martin)
Date: Thu, 16 Jun 2022 20:19:53 +0000
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
	<AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
Message-ID: <48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>

Hi Marco,

Maybe the following helps you:
https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c

Best,
Martin

On 16. Jun 2022, at 20:43, Carrasco, Manuel G <m.carrasco at imperial.ac.uk<mailto:m.carrasco at imperial.ac.uk>> wrote:

Hi Marco!
I have a program that when compiled, adds a program header that loads a data blob into a fixed memory location.
?I'm sorry to ask, but could you explain a bit more how this works? At first glance, I'd say that if any of this happens on a stage later than LLVM-IR, it may be hard to mimic in KLEE.

As far as I understand, when KLEE executes a LLVM-IR load instruction<https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>, it will try to find<https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191> the MemoryObjects (more than one if it is a symbolic pointer) that contain the address. Conceptually, you want KLEE to somehow have a MemoryObject at the hardcoded address.

One way to go could be modelling this as a LLVM-IR GlobalVariable at your fixed address with the content of your blob.  If this makes sense, you may want to check this function<https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648> and addExternalObject perhaps as well.

I apologise if you already know this!

Best regards,
Manuel.

________________________________
From: klee-dev-bounces at imperial.ac.uk<mailto:klee-dev-bounces at imperial.ac.uk> <klee-dev-bounces at imperial.ac.uk<mailto:klee-dev-bounces at imperial.ac.uk>> on behalf of Marco Vanotti <mvanotti at dc.uba.ar<mailto:mvanotti at dc.uba.ar>>
Sent: 16 June 2022 18:55
To: klee-dev <klee-dev at imperial.ac.uk<mailto:klee-dev at imperial.ac.uk>>
Subject: [klee-dev] Working with fixed memory locations.

Hi klee-dev!

I am new to KLEE, and have a question about using it with one of my programs.

I have a program that when compiled, adds a program header that loads a data blob into a fixed memory location.

This means that my program has this fixed memory location hardcoded all around the place (also this blob has references to itself).

I would like to load my program in KLEE to get a better understanding of how it works. The problem I am facing is that I have no idea how to make KLEE understand that I need this blob mapped in that address.

This are the things I've tried:

* Using wllvm/gclang to get the full program linked together, following my link script, then extracting the bc and running that with KLEE. This didn't work. KLEE complains that the pointers are invalid.

* Manually embedding the blob into my program as an array, then calling `mmap` with `MAP_FIXED` to map the area that I want and copying over the blob.

The issue here is that MAP_FIXED returns EPERM because probably the address range I am trying to map is already mapped.


* Setting the KLEE deterministic allocations to encompass the range that I care about, then doing a big `malloc` and making sure that my range is inside that malloc chunk.

For this last one, I am using flags like:
--allocate-determ --allocate-determ-start-address=8404992 --allocate-determ-size=3145728

One of the things that I see is that KLEE fails to mmap big chunks (in the order of 100MiB). But even if I decrease the size, I still get failures when I try to assert things like:

uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
klee_assert(BASE_ADDR >= malloc_addr);
klee_assert(BASE_ADDR < malloc_addr + malloc_size);

------

Something that might be relevant is that in reality I need two of these blobs loaded into different regions of memory, but so far I can't even get to load one. And they are not too far apart from each other, so if, for example, the malloc approach works, I could just increase the size and make the two allocations.

One thing that might complicate things, is that these addresses might collide with where KLEE tries to load the program. I don't know how to deal with that either.

Any advice on how to tune KLEE for this use case?

Best Regards,
Marco
_______________________________________________
klee-dev mailing list
klee-dev at imperial.ac.uk<mailto:klee-dev at imperial.ac.uk>
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev

-------------- next part --------------
HTML attachment scrubbed and removed

From c.cadar at imperial.ac.uk  Thu Jun 16 21:45:44 2022
From: c.cadar at imperial.ac.uk (Cristian Cadar)
Date: Thu, 16 Jun 2022 21:45:44 +0100
Subject: [klee-dev] Errors when files unconform to the format!
In-Reply-To: <tencent_E7F2E732F9AE61172A4C7E8C090992670B08@qq.com>
References: <tencent_E7F2E732F9AE61172A4C7E8C090992670B08@qq.com>
Message-ID: <a7745509-99ab-b94f-bb80-165e4a625f6c@imperial.ac.uk>

Hi Yukai,

You can use klee_assume 
(https://klee.github.io/docs/intrinsics/#klee_assumecondition) on the 
desired symbolic file created by the POSIX runtime, see 
https://github.com/klee/klee/blob/master/runtime/POSIX/fd_init.c#L61

Best,
Cristian

On 06/06/2022 15:06, ??? wrote:
> Hello!
> 
> I recently tried to use Klee to detect a project that handles PNG 
> images. I use sym files to generate input files, but the generated files 
> do not necessarily meet the format requirements of PNG pictures. 
> Therefore, I hope to fix some characters to make the generated files 
> conform to the format.
> 
> I found in the past mailing list that you mentioned that it can be 
> specified through the file in POSIX, but I can't figure out which file 
> can be set. So can you tell me the specific file path.
> 
> Similarly, I want to confirm whether Klee is also used in POSIX_ Assume 
> (), or there are other functions.
> 
> If you are willing to give a simple example, it would be great.
> 
> 
> Thanks and regards,
> yukai
> 
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev


From c.cadar at imperial.ac.uk  Thu Jun 16 21:54:38 2022
From: c.cadar at imperial.ac.uk (Cristian Cadar)
Date: Thu, 16 Jun 2022 21:54:38 +0100
Subject: [klee-dev] Need help in understanding a kquery generated by KLEE
In-Reply-To: <CAOp8ELHH65rWYh_+=P+4ZrMz20uhf7CGop3usS3OtXdcbeNJUQ@mail.gmail.com>
References: <CAOp8ELHH65rWYh_+=P+4ZrMz20uhf7CGop3usS3OtXdcbeNJUQ@mail.gmail.com>
Message-ID: <98712dc1-a893-e3a6-139d-ee4404740e97@imperial.ac.uk>

Hi Sandip,

Those constants are most likely derived from concrete addresses, but you 
should try to simplify the program as much as possible and send a full 
program that can be compiled and run.

Best,
Cristian

On 02/05/2022 19:22, Sandip Ghosal wrote:
> Hello,
> 
> I need help in understanding a kquery?file generated by KLEE.
> 
> Consider the following C program:
> 
> void* foo(struct node *item1. struct node *item2){
>  ? ? ? ? ?if(item1 == item2){
>  ? ? ? ? ? ? ?item1->next = NULL;
>  ? ? ? ? ?}
>  ? ? ? ? ?return item1;
> }
> 
> void main(){
>  ? ? ? struct list *array[3];
>  ? ? ? // next allocate memory for each array[I], i=0,1,2
>  ? ? ?int item1 = klee_range(0, 3, "item1");
>  ? ? ?int item2 = klee_range(0, 3, "item2");
>  ? ? ?foo(array[item1], array[item2]);
> }
> 
> Since my main objective is to understand the query, the above program is 
> simplified and loosely written for reference. Now KLEE generates one 
> kquery?as follows:
> 
> array const_arr1[24] : w32 -> w8 = [32 77 0 133 168 85 0 0 240 68 0 133 
> 168 85 0 0 0 77 0 133 168 85 0 0]
> array item1[4] : w32 -> w8 = symbolic
> array item2[4] : w32 -> w8 = symbolic
> 
> (query [(Ult N0:(ReadLSB w32 0 item1)
>  ? ? ? ? ? ? ? 3)
> 
>  ? ? ? ? ?(Ult N1:(ReadLSB w32 0 item2)
>  ? ? ? ? ? ? ? 3)
> 
>  ? ? ? ? ?(Eq N2:(ReadLSB w64 N3:(Extract w32 0 (Mul w64 8 (SExt w64 
> N0))) const_arr1)
>  ? ? ? ? ? ? ?(ReadLSB w64 N4:(Extract w32 0 (Mul w64 8 (SExt w64 N1))) 
> const_arr1))
> 
>  ? ? ? ? ?(Eq false
>  ? ? ? ? ? ? ?(Ult (Add w64 18446649891435295456 N2) 9))
> 
>  ? ? ? ? ?(Ult (Add w64 18446649891435295488 N2) 9)]
>  ? ? ? ? false)
> 
> I am struggling to understand the second and third last line of the 
> query which seems to be performing a boundary check on a flat?byte 
> memory address. I understand KLEE is implicitly branching over the 
> statement? item1->next = NULL, 18446649891435295456 perhaps is the base 
> address for item1, and N2 computes the offset. However, I am failing to 
> understand how the base address is computed and why it is always 
> compared with a constant value of 9?
> 
> Thanks in advance.
> 
> -- 
> Thanks & Regards
> Sandip Ghosal
> 
> 
> 
> 
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev


From mvanotti at dc.uba.ar  Thu Jun 16 23:48:34 2022
From: mvanotti at dc.uba.ar (Marco Vanotti)
Date: Thu, 16 Jun 2022 15:48:34 -0700
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
	<AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
	<48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>
Message-ID: <CAO7cxQWLDT+2RE_1fTJ7M5SO6M69-VBs3JQ6OqevUXYUTUEcdw@mail.gmail.com>

Hi Martin, Manuel,

Thanks for your answer :) !

On Thu, Jun 16, 2022 at 1:19 PM Nowack, Martin <m.nowack at imperial.ac.uk>
wrote:

> Hi Marco,
>
> Maybe the following helps you:
>
> https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
>

This seems to be what I am looking for, thanks!. I tried using it for small
variables and it works. However, for a big object (0x256000 bytes) it shows
the following warning:

*KLEE: WARNING ONCE*: flushing 2449408 bytes on read, may be slow and/or
crash: MO195[2449408] allocated at main():  call void
@klee_define_fixed_object(i8* inttoptr (i64 8404992 to i8*), i64 2449408),
!dbg !171

KLEE is still running, so maybe it just means it is slow.

I went with the approach of having my blob as a global variable, and then
`memcpy` it into the address after calling define_fixed_object.

Best,
> Martin
>
> On 16. Jun 2022, at 20:43, Carrasco, Manuel G <m.carrasco at imperial.ac.uk>
> wrote:
>
> Hi Marco!
>
> I have a program that when compiled, adds a program header that loads a
> data blob into a fixed memory location.
>
> I'm sorry to ask, but could you explain a bit more how this works? At
> first glance, I'd say that if any of this happens on a stage later than
> LLVM-IR, it may be hard to mimic in KLEE.
>
> I have a bunch of files that I add as .incbin into a section, and then my
linker scripts put them in a fixed address when it links the program
altogether. I think there is no way this would work with LLVM IR.

>
> As far as I understand, when KLEE executes a LLVM-IR load instruction
> <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>,
> it will try to find
> <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191> the
> MemoryObjects (more than one if it is a symbolic pointer) that contain the
> address. Conceptually, you want KLEE to somehow have a MemoryObject at the
> hardcoded address.
>
> One way to go could be modelling this as a LLVM-IR GlobalVariable at your
> fixed address with the content of your blob.  If this makes sense, you may
> want to check this function
> <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648> and
> addExternalObject perhaps as well.
>
> Thanks! This looks interesting, but I am a bit puzzled about how to go
with this. Should I recompile KLEE to add support for my use case? I
checked on the MemoryManager class and it seems like it just allocates
stuff at whatever place is available.

>
> I apologise if you already know this!
>
>
I did not know any of that :) This is the second time I am using KLEE, and
the first one was a big failure :P

Thanks!
Marco



>
> Best regards,
> Manuel.
>
> ------------------------------
> *From:* klee-dev-bounces at imperial.ac.uk <klee-dev-bounces at imperial.ac.uk>
> on behalf of Marco Vanotti <mvanotti at dc.uba.ar>
> *Sent:* 16 June 2022 18:55
> *To:* klee-dev <klee-dev at imperial.ac.uk>
> *Subject:* [klee-dev] Working with fixed memory locations.
>
> Hi klee-dev!
>
> I am new to KLEE, and have a question about using it with one of my
> programs.
>
> I have a program that when compiled, adds a program header that loads a
> data blob into a fixed memory location.
>
> This means that my program has this fixed memory location hardcoded all
> around the place (also this blob has references to itself).
>
> I would like to load my program in KLEE to get a better understanding of
> how it works. The problem I am facing is that I have no idea how to make
> KLEE understand that I need this blob mapped in that address.
>
> This are the things I've tried:
>
> * Using wllvm/gclang to get the full program linked together, following my
> link script, then extracting the bc and running that with KLEE. This didn't
> work. KLEE complains that the pointers are invalid.
>
> * Manually embedding the blob into my program as an array, then calling
> `mmap` with `MAP_FIXED` to map the area that I want and copying over the
> blob.
>
> The issue here is that MAP_FIXED returns EPERM because probably the
> address range I am trying to map is already mapped.
>
>
> * Setting the KLEE deterministic allocations to encompass the range that I
> care about, then doing a big `malloc` and making sure that my range is
> inside that malloc chunk.
>
> For this last one, I am using flags like:
> --allocate-determ --allocate-determ-start-address=8404992
> --allocate-determ-size=3145728
>
> One of the things that I see is that KLEE fails to mmap big chunks (in the
> order of 100MiB). But even if I decrease the size, I still get failures
> when I try to assert things like:
>
> uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
> klee_assert(BASE_ADDR >= malloc_addr);
> klee_assert(BASE_ADDR < malloc_addr + malloc_size);
>
> ------
>
> Something that might be relevant is that in reality I need two of these
> blobs loaded into different regions of memory, but so far I can't even get
> to load one. And they are not too far apart from each other, so if, for
> example, the malloc approach works, I could just increase the size and make
> the two allocations.
>
> One thing that might complicate things, is that these addresses might
> collide with where KLEE tries to load the program. I don't know how to deal
> with that either.
>
> Any advice on how to tune KLEE for this use case?
>
> Best Regards,
> Marco
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>
>
>
-------------- next part --------------
HTML attachment scrubbed and removed

From mvanotti at dc.uba.ar  Fri Jun 17 05:02:07 2022
From: mvanotti at dc.uba.ar (Marco Vanotti)
Date: Thu, 16 Jun 2022 21:02:07 -0700
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <CAO7cxQWLDT+2RE_1fTJ7M5SO6M69-VBs3JQ6OqevUXYUTUEcdw@mail.gmail.com>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
	<AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
	<48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>
	<CAO7cxQWLDT+2RE_1fTJ7M5SO6M69-VBs3JQ6OqevUXYUTUEcdw@mail.gmail.com>
Message-ID: <CAO7cxQUcBFk=3g8_RqxE5-2D+Gci+fTeN6xEam0xUZt2yq6jZQ@mail.gmail.com>

After letting it run for a few hours I've observed that klee spawns a
subprocess that keeps growing on memory until it reaches ~100GiB and then
it stops and restarts again.
Nothing is being printed indicating an error, but I'm not sure if the
behavior is normal. This is with KLEE from the docker container.

I've tried building KLEE from source, both with STP and Z3 support, and
running my program makes it crash with a segfault :(

Here is the backtrace for the crash with the STP solver:
https://pastebin.com/raw/xpf9D9VD

Best Regards,
Marco

On Thu, Jun 16, 2022 at 3:48 PM Marco Vanotti <mvanotti at dc.uba.ar> wrote:

> Hi Martin, Manuel,
>
> Thanks for your answer :) !
>
> On Thu, Jun 16, 2022 at 1:19 PM Nowack, Martin <m.nowack at imperial.ac.uk>
> wrote:
>
>> Hi Marco,
>>
>> Maybe the following helps you:
>>
>> https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
>>
>
> This seems to be what I am looking for, thanks!. I tried using it for
> small variables and it works. However, for a big object (0x256000 bytes) it
> shows the following warning:
>
> *KLEE: WARNING ONCE*: flushing 2449408 bytes on read, may be slow and/or
> crash: MO195[2449408] allocated at main():  call void
> @klee_define_fixed_object(i8* inttoptr (i64 8404992 to i8*), i64 2449408),
> !dbg !171
>
> KLEE is still running, so maybe it just means it is slow.
>
> I went with the approach of having my blob as a global variable, and then
> `memcpy` it into the address after calling define_fixed_object.
>
> Best,
>> Martin
>>
>> On 16. Jun 2022, at 20:43, Carrasco, Manuel G <m.carrasco at imperial.ac.uk>
>> wrote:
>>
>> Hi Marco!
>>
>> I have a program that when compiled, adds a program header that loads a
>> data blob into a fixed memory location.
>>
>> I'm sorry to ask, but could you explain a bit more how this works? At
>> first glance, I'd say that if any of this happens on a stage later than
>> LLVM-IR, it may be hard to mimic in KLEE.
>>
>> I have a bunch of files that I add as .incbin into a section, and then my
> linker scripts put them in a fixed address when it links the program
> altogether. I think there is no way this would work with LLVM IR.
>
>>
>> As far as I understand, when KLEE executes a LLVM-IR load instruction
>> <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>,
>> it will try to find
>> <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191> the
>> MemoryObjects (more than one if it is a symbolic pointer) that contain the
>> address. Conceptually, you want KLEE to somehow have a MemoryObject at the
>> hardcoded address.
>>
>> One way to go could be modelling this as a LLVM-IR GlobalVariable at your
>> fixed address with the content of your blob.  If this makes sense, you may
>> want to check this function
>> <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648> and
>> addExternalObject perhaps as well.
>>
>> Thanks! This looks interesting, but I am a bit puzzled about how to go
> with this. Should I recompile KLEE to add support for my use case? I
> checked on the MemoryManager class and it seems like it just allocates
> stuff at whatever place is available.
>
>>
>> I apologise if you already know this!
>>
>>
> I did not know any of that :) This is the second time I am using KLEE, and
> the first one was a big failure :P
>
> Thanks!
> Marco
>
>
>
>>
>> Best regards,
>> Manuel.
>>
>> ------------------------------
>> *From:* klee-dev-bounces at imperial.ac.uk <klee-dev-bounces at imperial.ac.uk>
>> on behalf of Marco Vanotti <mvanotti at dc.uba.ar>
>> *Sent:* 16 June 2022 18:55
>> *To:* klee-dev <klee-dev at imperial.ac.uk>
>> *Subject:* [klee-dev] Working with fixed memory locations.
>>
>> Hi klee-dev!
>>
>> I am new to KLEE, and have a question about using it with one of my
>> programs.
>>
>> I have a program that when compiled, adds a program header that loads a
>> data blob into a fixed memory location.
>>
>> This means that my program has this fixed memory location hardcoded all
>> around the place (also this blob has references to itself).
>>
>> I would like to load my program in KLEE to get a better understanding of
>> how it works. The problem I am facing is that I have no idea how to make
>> KLEE understand that I need this blob mapped in that address.
>>
>> This are the things I've tried:
>>
>> * Using wllvm/gclang to get the full program linked together, following
>> my link script, then extracting the bc and running that with KLEE. This
>> didn't work. KLEE complains that the pointers are invalid.
>>
>> * Manually embedding the blob into my program as an array, then calling
>> `mmap` with `MAP_FIXED` to map the area that I want and copying over the
>> blob.
>>
>> The issue here is that MAP_FIXED returns EPERM because probably the
>> address range I am trying to map is already mapped.
>>
>>
>> * Setting the KLEE deterministic allocations to encompass the range that
>> I care about, then doing a big `malloc` and making sure that my range is
>> inside that malloc chunk.
>>
>> For this last one, I am using flags like:
>> --allocate-determ --allocate-determ-start-address=8404992
>> --allocate-determ-size=3145728
>>
>> One of the things that I see is that KLEE fails to mmap big chunks (in
>> the order of 100MiB). But even if I decrease the size, I still get failures
>> when I try to assert things like:
>>
>> uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
>> klee_assert(BASE_ADDR >= malloc_addr);
>> klee_assert(BASE_ADDR < malloc_addr + malloc_size);
>>
>> ------
>>
>> Something that might be relevant is that in reality I need two of these
>> blobs loaded into different regions of memory, but so far I can't even get
>> to load one. And they are not too far apart from each other, so if, for
>> example, the malloc approach works, I could just increase the size and make
>> the two allocations.
>>
>> One thing that might complicate things, is that these addresses might
>> collide with where KLEE tries to load the program. I don't know how to deal
>> with that either.
>>
>> Any advice on how to tune KLEE for this use case?
>>
>> Best Regards,
>> Marco
>> _______________________________________________
>> klee-dev mailing list
>> klee-dev at imperial.ac.uk
>> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>>
>>
>>
-------------- next part --------------
HTML attachment scrubbed and removed

From c.cadar at imperial.ac.uk  Fri Jun 17 10:53:40 2022
From: c.cadar at imperial.ac.uk (Cristian Cadar)
Date: Fri, 17 Jun 2022 10:53:40 +0100
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <CAO7cxQUcBFk=3g8_RqxE5-2D+Gci+fTeN6xEam0xUZt2yq6jZQ@mail.gmail.com>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
	<AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
	<48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>
	<CAO7cxQWLDT+2RE_1fTJ7M5SO6M69-VBs3JQ6OqevUXYUTUEcdw@mail.gmail.com>
	<CAO7cxQUcBFk=3g8_RqxE5-2D+Gci+fTeN6xEam0xUZt2yq6jZQ@mail.gmail.com>
Message-ID: <2b611f4a-b3ab-1fa5-4ba1-44a56dfa443c@imperial.ac.uk>

Hi Marco, you seem to be reaching an issue with the solver, which is 
having trouble reasoning about the huge symbolic array (requiring 
excessive time and memory).  You should try to shrink that array if 
possible.  You can also try --optimize-array=all, but it might not help 
in your case.

Best,
Cristian

On 17/06/2022 05:02, Marco Vanotti wrote:
> After?letting it run for a few hours I've observed that klee spawns a 
> subprocess that keeps growing on memory until it reaches ~100GiB and 
> then it stops and restarts again.
> Nothing is being printed indicating an error, but I'm not sure if the 
> behavior is normal. This is with KLEE from the docker container.
> 
> I've tried building KLEE from source, both with STP and Z3 support, and 
> running my program makes it crash with a segfault :(
> 
> Here is the backtrace for the crash with the STP solver: 
> https://pastebin.com/raw/xpf9D9VD <https://pastebin.com/raw/xpf9D9VD>
> 
> Best Regards,
> Marco
> 
> On Thu, Jun 16, 2022 at 3:48 PM Marco Vanotti <mvanotti at dc.uba.ar 
> <mailto:mvanotti at dc.uba.ar>> wrote:
> 
>     Hi Martin, Manuel,
> 
>     Thanks for your answer :) !
> 
>     On Thu, Jun 16, 2022 at 1:19 PM Nowack, Martin
>     <m.nowack at imperial.ac.uk <mailto:m.nowack at imperial.ac.uk>> wrote:
> 
>         Hi Marco,
> 
>         Maybe the following helps you:
>         https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
>         <https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c>
> 
> 
>     This seems to be what I am looking for,?thanks!. I tried using it
>     for small variables and it works. However, for a big object
>     (0x256000 bytes) it shows the following warning:
> 
>     *KLEE: WARNING ONCE*: flushing 2449408 bytes on read, may be slow
>     and/or crash: MO195[2449408] allocated at main(): ?call void
>     @klee_define_fixed_object(i8* inttoptr (i64 8404992 to i8*), i64
>     2449408), !dbg !171
>     KLEE is still running, so maybe it just means it is slow.
> 
>     I went with the approach of having my blob as a global variable, and
>     then `memcpy` it into the address after calling define_fixed_object.
> 
>         Best,
>         Martin
> 
>>         On 16. Jun 2022, at 20:43, Carrasco, Manuel G
>>         <m.carrasco at imperial.ac.uk <mailto:m.carrasco at imperial.ac.uk>>
>>         wrote:
>>
>>         Hi Marco!
>>
>>             I have a program that when compiled, adds a program header
>>             that loads a data blob into a fixed memory location.
>>
>>         I'm sorry to ask, but could you explain a bit more how this
>>         works? At first glance, I'd say that if any of this happens on
>>         a stage later than LLVM-IR, it may be hard to mimic in KLEE.
> 
>     I have a bunch of files that I add as .incbin into a section, and
>     then my linker scripts put them in a fixed address when it links the
>     program altogether. I think there is no way this would work with
>     LLVM IR.
> 
>>
>>         As far as I understand, when KLEEexecutes a LLVM-IR load
>>         instruction
>>         <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>,
>>         it will try tofind
>>         <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191>the
>>         MemoryObjects (more than one if it is a symbolic pointer) that
>>         contain the address. Conceptually, you want KLEE to somehow
>>         have a MemoryObject at the hardcoded address.
>>
>>         One way to go could be modelling this as a LLVM-IR
>>         GlobalVariable at your fixed address with the content of your
>>         blob.? If this makes sense, you may want to check thisfunction
>>         <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648>and
>>         addExternalObject perhaps as well.
> 
>     Thanks! This looks interesting, but I am a bit puzzled about how to
>     go with this. Should I recompile KLEE to add support for my use
>     case? I checked on the MemoryManager class and it seems like it just
>     allocates stuff at whatever place is available.
> 
>>
>>         I apologise if you already know this!
> 
> 
>     I did not know any of that :) This is the second time I am using
>     KLEE, and the first one was a big failure :P
> 
>     Thanks!
>     Marco
> 
>>
>>         Best regards,
>>         Manuel.
>>
>>         ------------------------------------------------------------------------
>>         *From:*klee-dev-bounces at imperial.ac.uk
>>         <mailto:klee-dev-bounces at imperial.ac.uk>
>>         <klee-dev-bounces at imperial.ac.uk
>>         <mailto:klee-dev-bounces at imperial.ac.uk>> on behalf of Marco
>>         Vanotti <mvanotti at dc.uba.ar <mailto:mvanotti at dc.uba.ar>>
>>         *Sent:*16 June 2022 18:55
>>         *To:*klee-dev <klee-dev at imperial.ac.uk
>>         <mailto:klee-dev at imperial.ac.uk>>
>>         *Subject:*[klee-dev] Working with fixed memory locations.
>>         Hi klee-dev!
>>
>>         I am new to KLEE, and have a question about using it with one
>>         of my programs.
>>
>>         I have a program that when compiled, adds a program header
>>         that loads a data blob into a fixed memory location.
>>
>>         This means that my program has this fixed memory location
>>         hardcoded all around the place (also this blob has references
>>         to itself).
>>
>>         I would like to load my program in KLEE to get a better
>>         understanding of how it works. The problem I am facing is that
>>         I have no idea how to make KLEE understand that I need this
>>         blob mapped in that address.
>>
>>         This are the things I've tried:
>>
>>         * Using wllvm/gclang to get the full program linked together,
>>         following my link script, then extracting the bc and running
>>         that with KLEE. This didn't work. KLEE complains that the
>>         pointers are invalid.
>>
>>         * Manually embedding the blob into my program as an array,
>>         then calling `mmap` with `MAP_FIXED` to map the area that I
>>         want and copying over the blob.
>>
>>         The issue here is that MAP_FIXED returns EPERM because
>>         probably the address range I am trying to map is already mapped.
>>
>>
>>         * Setting the KLEE deterministic allocations to encompass the
>>         range that I care about, then doing a big `malloc` and making
>>         sure that my range is inside that malloc chunk.
>>
>>         For this last one, I am using flags like:
>>         --allocate-determ --allocate-determ-start-address=8404992
>>         --allocate-determ-size=3145728
>>
>>         One of the things that I see is that KLEE fails to mmap big
>>         chunks (in the order of 100MiB). But even if I decrease the
>>         size, I still get failures when I try to assert things like:
>>
>>         uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
>>         klee_assert(BASE_ADDR >= malloc_addr);
>>         klee_assert(BASE_ADDR < malloc_addr?+ malloc_size);
>>
>>         ------
>>
>>         Something that might be relevant is that in reality I need two
>>         of these blobs loaded into different regions of memory, but so
>>         far I can't even get to load one. And they are not too far
>>         apart from each other, so if, for example, the malloc approach
>>         works, I could just increase the size and make the two
>>         allocations.
>>
>>         One thing that might complicate things, is that these
>>         addresses might collide with where KLEE tries to load the
>>         program. I don't know how to deal with that either.
>>
>>         Any advice on how to tune KLEE for this use case?
>>
>>         Best Regards,
>>         Marco
>>         _______________________________________________
>>         klee-dev mailing list
>>         klee-dev at imperial.ac.uk <mailto:klee-dev at imperial.ac.uk>
>>         https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>>         <https://mailman.ic.ac.uk/mailman/listinfo/klee-dev>
> 
> 
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev


From m.carrasco at imperial.ac.uk  Fri Jun 17 11:29:42 2022
From: m.carrasco at imperial.ac.uk (Carrasco, Manuel G)
Date: Fri, 17 Jun 2022 10:29:42 +0000
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <2b611f4a-b3ab-1fa5-4ba1-44a56dfa443c@imperial.ac.uk>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
	<AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
	<48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>
	<CAO7cxQWLDT+2RE_1fTJ7M5SO6M69-VBs3JQ6OqevUXYUTUEcdw@mail.gmail.com>
	<CAO7cxQUcBFk=3g8_RqxE5-2D+Gci+fTeN6xEam0xUZt2yq6jZQ@mail.gmail.com>
	<2b611f4a-b3ab-1fa5-4ba1-44a56dfa443c@imperial.ac.uk>
Message-ID: <AM0PR0602MB3681D974806742C9369CFA8BBEAF9@AM0PR0602MB3681.eurprd06.prod.outlook.com>

Hi Marco,

I wasn't aware of the klee_define_fixed_object intrinsic.

This is a question on my side regarding KLEE. If an array is always read/written using constant accesses,  are the "getArrayForUpdate" calls strictly necessary? However, I'm not sure if this description fits your blob. Is it a constant buffer after its initialization? Is it symbolically indexed? How is it initialized?

Best,
Manuel.
________________________________
From: klee-dev-bounces at imperial.ac.uk <klee-dev-bounces at imperial.ac.uk> on behalf of Cristian Cadar <c.cadar at imperial.ac.uk>
Sent: 17 June 2022 10:53
To: mvanotti at dc.uba.ar <mvanotti at dc.uba.ar>; Nowack, Martin <m.nowack at imperial.ac.uk>
Cc: klee-dev <klee-dev at imperial.ac.uk>
Subject: Re: [klee-dev] Working with fixed memory locations.

Hi Marco, you seem to be reaching an issue with the solver, which is
having trouble reasoning about the huge symbolic array (requiring
excessive time and memory).  You should try to shrink that array if
possible.  You can also try --optimize-array=all, but it might not help
in your case.

Best,
Cristian

On 17/06/2022 05:02, Marco Vanotti wrote:
> After letting it run for a few hours I've observed that klee spawns a
> subprocess that keeps growing on memory until it reaches ~100GiB and
> then it stops and restarts again.
> Nothing is being printed indicating an error, but I'm not sure if the
> behavior is normal. This is with KLEE from the docker container.
>
> I've tried building KLEE from source, both with STP and Z3 support, and
> running my program makes it crash with a segfault :(
>
> Here is the backtrace for the crash with the STP solver:
> https://pastebin.com/raw/xpf9D9VD <https://pastebin.com/raw/xpf9D9VD>
>
> Best Regards,
> Marco
>
> On Thu, Jun 16, 2022 at 3:48 PM Marco Vanotti <mvanotti at dc.uba.ar
> <mailto:mvanotti at dc.uba.ar>> wrote:
>
>     Hi Martin, Manuel,
>
>     Thanks for your answer :) !
>
>     On Thu, Jun 16, 2022 at 1:19 PM Nowack, Martin
>     <m.nowack at imperial.ac.uk <mailto:m.nowack at imperial.ac.uk>> wrote:
>
>         Hi Marco,
>
>         Maybe the following helps you:
>         https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
>         <https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c>
>
>
>     This seems to be what I am looking for, thanks!. I tried using it
>     for small variables and it works. However, for a big object
>     (0x256000 bytes) it shows the following warning:
>
>     *KLEE: WARNING ONCE*: flushing 2449408 bytes on read, may be slow
>     and/or crash: MO195[2449408] allocated at main():  call void
>     @klee_define_fixed_object(i8* inttoptr (i64 8404992 to i8*), i64
>     2449408), !dbg !171
>     KLEE is still running, so maybe it just means it is slow.
>
>     I went with the approach of having my blob as a global variable, and
>     then `memcpy` it into the address after calling define_fixed_object.
>
>         Best,
>         Martin
>
>>         On 16. Jun 2022, at 20:43, Carrasco, Manuel G
>>         <m.carrasco at imperial.ac.uk <mailto:m.carrasco at imperial.ac.uk>>
>>         wrote:
>>
>>         Hi Marco!
>>
>>             I have a program that when compiled, adds a program header
>>             that loads a data blob into a fixed memory location.
>>
>>         I'm sorry to ask, but could you explain a bit more how this
>>         works? At first glance, I'd say that if any of this happens on
>>         a stage later than LLVM-IR, it may be hard to mimic in KLEE.
>
>     I have a bunch of files that I add as .incbin into a section, and
>     then my linker scripts put them in a fixed address when it links the
>     program altogether. I think there is no way this would work with
>     LLVM IR.
>
>>
>>         As far as I understand, when KLEEexecutes a LLVM-IR load
>>         instruction
>>         <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>,
>>         it will try tofind
>>         <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191>the
>>         MemoryObjects (more than one if it is a symbolic pointer) that
>>         contain the address. Conceptually, you want KLEE to somehow
>>         have a MemoryObject at the hardcoded address.
>>
>>         One way to go could be modelling this as a LLVM-IR
>>         GlobalVariable at your fixed address with the content of your
>>         blob.  If this makes sense, you may want to check thisfunction
>>         <https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648>and
>>         addExternalObject perhaps as well.
>
>     Thanks! This looks interesting, but I am a bit puzzled about how to
>     go with this. Should I recompile KLEE to add support for my use
>     case? I checked on the MemoryManager class and it seems like it just
>     allocates stuff at whatever place is available.
>
>>
>>         I apologise if you already know this!
>
>
>     I did not know any of that :) This is the second time I am using
>     KLEE, and the first one was a big failure :P
>
>     Thanks!
>     Marco
>
>>
>>         Best regards,
>>         Manuel.
>>
>>         ------------------------------------------------------------------------
>>         *From:*klee-dev-bounces at imperial.ac.uk
>>         <mailto:klee-dev-bounces at imperial.ac.uk>
>>         <klee-dev-bounces at imperial.ac.uk
>>         <mailto:klee-dev-bounces at imperial.ac.uk>> on behalf of Marco
>>         Vanotti <mvanotti at dc.uba.ar <mailto:mvanotti at dc.uba.ar>>
>>         *Sent:*16 June 2022 18:55
>>         *To:*klee-dev <klee-dev at imperial.ac.uk
>>         <mailto:klee-dev at imperial.ac.uk>>
>>         *Subject:*[klee-dev] Working with fixed memory locations.
>>         Hi klee-dev!
>>
>>         I am new to KLEE, and have a question about using it with one
>>         of my programs.
>>
>>         I have a program that when compiled, adds a program header
>>         that loads a data blob into a fixed memory location.
>>
>>         This means that my program has this fixed memory location
>>         hardcoded all around the place (also this blob has references
>>         to itself).
>>
>>         I would like to load my program in KLEE to get a better
>>         understanding of how it works. The problem I am facing is that
>>         I have no idea how to make KLEE understand that I need this
>>         blob mapped in that address.
>>
>>         This are the things I've tried:
>>
>>         * Using wllvm/gclang to get the full program linked together,
>>         following my link script, then extracting the bc and running
>>         that with KLEE. This didn't work. KLEE complains that the
>>         pointers are invalid.
>>
>>         * Manually embedding the blob into my program as an array,
>>         then calling `mmap` with `MAP_FIXED` to map the area that I
>>         want and copying over the blob.
>>
>>         The issue here is that MAP_FIXED returns EPERM because
>>         probably the address range I am trying to map is already mapped.
>>
>>
>>         * Setting the KLEE deterministic allocations to encompass the
>>         range that I care about, then doing a big `malloc` and making
>>         sure that my range is inside that malloc chunk.
>>
>>         For this last one, I am using flags like:
>>         --allocate-determ --allocate-determ-start-address=8404992
>>         --allocate-determ-size=3145728
>>
>>         One of the things that I see is that KLEE fails to mmap big
>>         chunks (in the order of 100MiB). But even if I decrease the
>>         size, I still get failures when I try to assert things like:
>>
>>         uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
>>         klee_assert(BASE_ADDR >= malloc_addr);
>>         klee_assert(BASE_ADDR < malloc_addr + malloc_size);
>>
>>         ------
>>
>>         Something that might be relevant is that in reality I need two
>>         of these blobs loaded into different regions of memory, but so
>>         far I can't even get to load one. And they are not too far
>>         apart from each other, so if, for example, the malloc approach
>>         works, I could just increase the size and make the two
>>         allocations.
>>
>>         One thing that might complicate things, is that these
>>         addresses might collide with where KLEE tries to load the
>>         program. I don't know how to deal with that either.
>>
>>         Any advice on how to tune KLEE for this use case?
>>
>>         Best Regards,
>>         Marco
>>         _______________________________________________
>>         klee-dev mailing list
>>         klee-dev at imperial.ac.uk <mailto:klee-dev at imperial.ac.uk>
>>         https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>>         <https://mailman.ic.ac.uk/mailman/listinfo/klee-dev>
>
>
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev

_______________________________________________
klee-dev mailing list
klee-dev at imperial.ac.uk
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
-------------- next part --------------
HTML attachment scrubbed and removed

From mvanotti at dc.uba.ar  Sat Jun 18 01:12:31 2022
From: mvanotti at dc.uba.ar (Marco Vanotti)
Date: Fri, 17 Jun 2022 17:12:31 -0700
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <2b611f4a-b3ab-1fa5-4ba1-44a56dfa443c@imperial.ac.uk>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
	<AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
	<48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>
	<CAO7cxQWLDT+2RE_1fTJ7M5SO6M69-VBs3JQ6OqevUXYUTUEcdw@mail.gmail.com>
	<CAO7cxQUcBFk=3g8_RqxE5-2D+Gci+fTeN6xEam0xUZt2yq6jZQ@mail.gmail.com>
	<2b611f4a-b3ab-1fa5-4ba1-44a56dfa443c@imperial.ac.uk>
Message-ID: <CAO7cxQX+A5YkXGA621pYxt4t3x857AaoxmTPFDWSGvMjTj7Aqg@mail.gmail.com>

Hi Cristian,

Thanks for your answer. I have tried *--optimize-array=all*, but that
didn't fix the problem :(.

It would be a better user experience to get an error message instead of a
segfault. In any case, if this is stopping because it's running out of
memory, is there a way to remove that restriction? My server still had a
few GiB to spare ?.


On Fri, Jun 17, 2022 at 2:53 AM Cristian Cadar <c.cadar at imperial.ac.uk>
wrote:

> Hi Marco, you seem to be reaching an issue with the solver, which is
> having trouble reasoning about the huge symbolic array (requiring
> excessive time and memory).  You should try to shrink that array if
> possible.  You can also try --optimize-array=all, but it might not help
> in your case.
>
> Best,
> Cristian
>
> On 17/06/2022 05:02, Marco Vanotti wrote:
> > After letting it run for a few hours I've observed that klee spawns a
> > subprocess that keeps growing on memory until it reaches ~100GiB and
> > then it stops and restarts again.
> > Nothing is being printed indicating an error, but I'm not sure if the
> > behavior is normal. This is with KLEE from the docker container.
> >
> > I've tried building KLEE from source, both with STP and Z3 support, and
> > running my program makes it crash with a segfault :(
> >
> > Here is the backtrace for the crash with the STP solver:
> > https://pastebin.com/raw/xpf9D9VD <https://pastebin.com/raw/xpf9D9VD>
> >
> > Best Regards,
> > Marco
> >
> > On Thu, Jun 16, 2022 at 3:48 PM Marco Vanotti <mvanotti at dc.uba.ar
> > <mailto:mvanotti at dc.uba.ar>> wrote:
> >
> >     Hi Martin, Manuel,
> >
> >     Thanks for your answer :) !
> >
> >     On Thu, Jun 16, 2022 at 1:19 PM Nowack, Martin
> >     <m.nowack at imperial.ac.uk <mailto:m.nowack at imperial.ac.uk>> wrote:
> >
> >         Hi Marco,
> >
> >         Maybe the following helps you:
> >
> https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
> >         <
> https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
> >
> >
> >
> >     This seems to be what I am looking for, thanks!. I tried using it
> >     for small variables and it works. However, for a big object
> >     (0x256000 bytes) it shows the following warning:
> >
> >     *KLEE: WARNING ONCE*: flushing 2449408 bytes on read, may be slow
> >     and/or crash: MO195[2449408] allocated at main():  call void
> >     @klee_define_fixed_object(i8* inttoptr (i64 8404992 to i8*), i64
> >     2449408), !dbg !171
> >     KLEE is still running, so maybe it just means it is slow.
> >
> >     I went with the approach of having my blob as a global variable, and
> >     then `memcpy` it into the address after calling define_fixed_object.
> >
> >         Best,
> >         Martin
> >
> >>         On 16. Jun 2022, at 20:43, Carrasco, Manuel G
> >>         <m.carrasco at imperial.ac.uk <mailto:m.carrasco at imperial.ac.uk>>
> >>         wrote:
> >>
> >>         Hi Marco!
> >>
> >>             I have a program that when compiled, adds a program header
> >>             that loads a data blob into a fixed memory location.
> >>
> >>         I'm sorry to ask, but could you explain a bit more how this
> >>         works? At first glance, I'd say that if any of this happens on
> >>         a stage later than LLVM-IR, it may be hard to mimic in KLEE.
> >
> >     I have a bunch of files that I add as .incbin into a section, and
> >     then my linker scripts put them in a fixed address when it links the
> >     program altogether. I think there is no way this would work with
> >     LLVM IR.
> >
> >>
> >>         As far as I understand, when KLEEexecutes a LLVM-IR load
> >>         instruction
> >>         <
> https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>,
> >>         it will try tofind
> >>         <
> https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191>the
> >>         MemoryObjects (more than one if it is a symbolic pointer) that
> >>         contain the address. Conceptually, you want KLEE to somehow
> >>         have a MemoryObject at the hardcoded address.
> >>
> >>         One way to go could be modelling this as a LLVM-IR
> >>         GlobalVariable at your fixed address with the content of your
> >>         blob.  If this makes sense, you may want to check thisfunction
> >>         <
> https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648>and
> >>         addExternalObject perhaps as well.
> >
> >     Thanks! This looks interesting, but I am a bit puzzled about how to
> >     go with this. Should I recompile KLEE to add support for my use
> >     case? I checked on the MemoryManager class and it seems like it just
> >     allocates stuff at whatever place is available.
> >
> >>
> >>         I apologise if you already know this!
> >
> >
> >     I did not know any of that :) This is the second time I am using
> >     KLEE, and the first one was a big failure :P
> >
> >     Thanks!
> >     Marco
> >
> >>
> >>         Best regards,
> >>         Manuel.
> >>
> >>
>  ------------------------------------------------------------------------
> >>         *From:*klee-dev-bounces at imperial.ac.uk
> >>         <mailto:klee-dev-bounces at imperial.ac.uk>
> >>         <klee-dev-bounces at imperial.ac.uk
> >>         <mailto:klee-dev-bounces at imperial.ac.uk>> on behalf of Marco
> >>         Vanotti <mvanotti at dc.uba.ar <mailto:mvanotti at dc.uba.ar>>
> >>         *Sent:*16 June 2022 18:55
> >>         *To:*klee-dev <klee-dev at imperial.ac.uk
> >>         <mailto:klee-dev at imperial.ac.uk>>
> >>         *Subject:*[klee-dev] Working with fixed memory locations.
> >>         Hi klee-dev!
> >>
> >>         I am new to KLEE, and have a question about using it with one
> >>         of my programs.
> >>
> >>         I have a program that when compiled, adds a program header
> >>         that loads a data blob into a fixed memory location.
> >>
> >>         This means that my program has this fixed memory location
> >>         hardcoded all around the place (also this blob has references
> >>         to itself).
> >>
> >>         I would like to load my program in KLEE to get a better
> >>         understanding of how it works. The problem I am facing is that
> >>         I have no idea how to make KLEE understand that I need this
> >>         blob mapped in that address.
> >>
> >>         This are the things I've tried:
> >>
> >>         * Using wllvm/gclang to get the full program linked together,
> >>         following my link script, then extracting the bc and running
> >>         that with KLEE. This didn't work. KLEE complains that the
> >>         pointers are invalid.
> >>
> >>         * Manually embedding the blob into my program as an array,
> >>         then calling `mmap` with `MAP_FIXED` to map the area that I
> >>         want and copying over the blob.
> >>
> >>         The issue here is that MAP_FIXED returns EPERM because
> >>         probably the address range I am trying to map is already mapped.
> >>
> >>
> >>         * Setting the KLEE deterministic allocations to encompass the
> >>         range that I care about, then doing a big `malloc` and making
> >>         sure that my range is inside that malloc chunk.
> >>
> >>         For this last one, I am using flags like:
> >>         --allocate-determ --allocate-determ-start-address=8404992
> >>         --allocate-determ-size=3145728
> >>
> >>         One of the things that I see is that KLEE fails to mmap big
> >>         chunks (in the order of 100MiB). But even if I decrease the
> >>         size, I still get failures when I try to assert things like:
> >>
> >>         uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
> >>         klee_assert(BASE_ADDR >= malloc_addr);
> >>         klee_assert(BASE_ADDR < malloc_addr + malloc_size);
> >>
> >>         ------
> >>
> >>         Something that might be relevant is that in reality I need two
> >>         of these blobs loaded into different regions of memory, but so
> >>         far I can't even get to load one. And they are not too far
> >>         apart from each other, so if, for example, the malloc approach
> >>         works, I could just increase the size and make the two
> >>         allocations.
> >>
> >>         One thing that might complicate things, is that these
> >>         addresses might collide with where KLEE tries to load the
> >>         program. I don't know how to deal with that either.
> >>
> >>         Any advice on how to tune KLEE for this use case?
> >>
> >>         Best Regards,
> >>         Marco
> >>         _______________________________________________
> >>         klee-dev mailing list
> >>         klee-dev at imperial.ac.uk <mailto:klee-dev at imperial.ac.uk>
> >>         https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
> >>         <https://mailman.ic.ac.uk/mailman/listinfo/klee-dev>
> >
> >
> > _______________________________________________
> > klee-dev mailing list
> > klee-dev at imperial.ac.uk
> > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>
-------------- next part --------------
HTML attachment scrubbed and removed

From mvanotti at dc.uba.ar  Sat Jun 18 01:20:02 2022
From: mvanotti at dc.uba.ar (Marco Vanotti)
Date: Fri, 17 Jun 2022 17:20:02 -0700
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <AM0PR0602MB3681D974806742C9369CFA8BBEAF9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
	<AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
	<48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>
	<CAO7cxQWLDT+2RE_1fTJ7M5SO6M69-VBs3JQ6OqevUXYUTUEcdw@mail.gmail.com>
	<CAO7cxQUcBFk=3g8_RqxE5-2D+Gci+fTeN6xEam0xUZt2yq6jZQ@mail.gmail.com>
	<2b611f4a-b3ab-1fa5-4ba1-44a56dfa443c@imperial.ac.uk>
	<AM0PR0602MB3681D974806742C9369CFA8BBEAF9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
Message-ID: <CAO7cxQXp183YxF1Vm4uN6vW_s5qu5BXmTf2AjgWBJJCYQ_tMsA@mail.gmail.com>

Hi Manuel,

On Fri, Jun 17, 2022 at 3:29 AM Carrasco, Manuel G <
m.carrasco at imperial.ac.uk> wrote:

> Hi Marco,
>
> I wasn't aware of the klee_define_fixed_object intrinsic.
>
> This is a question on my side regarding KLEE. If an array is always
> read/written using constant accesses,  are the "getArrayForUpdate" calls
> strictly necessary? However, I'm not sure if this description fits your
> blob. Is it a constant buffer after its initialization? Is it symbolically
> indexed? How is it initialized?
>

No, the blob is not constant. It represents a virtual machine which holds
the instructions, memory and registers. My program is just an emulator. I
point it to the entry point inside the memory region and it starts
executing.

I've heard that KLEE, and symbolic execution in general, are not that great
in this scenario. However, the machine that I am interpreting is extremely
simple.

Best,
Marco


> Best,
> Manuel.
> ------------------------------
> *From:* klee-dev-bounces at imperial.ac.uk <klee-dev-bounces at imperial.ac.uk>
> on behalf of Cristian Cadar <c.cadar at imperial.ac.uk>
> *Sent:* 17 June 2022 10:53
> *To:* mvanotti at dc.uba.ar <mvanotti at dc.uba.ar>; Nowack, Martin <
> m.nowack at imperial.ac.uk>
> *Cc:* klee-dev <klee-dev at imperial.ac.uk>
> *Subject:* Re: [klee-dev] Working with fixed memory locations.
>
> Hi Marco, you seem to be reaching an issue with the solver, which is
> having trouble reasoning about the huge symbolic array (requiring
> excessive time and memory).  You should try to shrink that array if
> possible.  You can also try --optimize-array=all, but it might not help
> in your case.
>
> Best,
> Cristian
>
> On 17/06/2022 05:02, Marco Vanotti wrote:
> > After letting it run for a few hours I've observed that klee spawns a
> > subprocess that keeps growing on memory until it reaches ~100GiB and
> > then it stops and restarts again.
> > Nothing is being printed indicating an error, but I'm not sure if the
> > behavior is normal. This is with KLEE from the docker container.
> >
> > I've tried building KLEE from source, both with STP and Z3 support, and
> > running my program makes it crash with a segfault :(
> >
> > Here is the backtrace for the crash with the STP solver:
> > https://pastebin.com/raw/xpf9D9VD <https://pastebin.com/raw/xpf9D9VD>
> >
> > Best Regards,
> > Marco
> >
> > On Thu, Jun 16, 2022 at 3:48 PM Marco Vanotti <mvanotti at dc.uba.ar
> > <mailto:mvanotti at dc.uba.ar <mvanotti at dc.uba.ar>>> wrote:
> >
> >     Hi Martin, Manuel,
> >
> >     Thanks for your answer :) !
> >
> >     On Thu, Jun 16, 2022 at 1:19 PM Nowack, Martin
> >     <m.nowack at imperial.ac.uk <mailto:m.nowack at imperial.ac.uk
> <m.nowack at imperial.ac.uk>>> wrote:
> >
> >         Hi Marco,
> >
> >         Maybe the following helps you:
> >
> https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
> >         <
> https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
> >
> >
> >
> >     This seems to be what I am looking for, thanks!. I tried using it
> >     for small variables and it works. However, for a big object
> >     (0x256000 bytes) it shows the following warning:
> >
> >     *KLEE: WARNING ONCE*: flushing 2449408 bytes on read, may be slow
> >     and/or crash: MO195[2449408] allocated at main():  call void
> >     @klee_define_fixed_object(i8* inttoptr (i64 8404992 to i8*), i64
> >     2449408), !dbg !171
> >     KLEE is still running, so maybe it just means it is slow.
> >
> >     I went with the approach of having my blob as a global variable, and
> >     then `memcpy` it into the address after calling define_fixed_object.
> >
> >         Best,
> >         Martin
> >
> >>         On 16. Jun 2022, at 20:43, Carrasco, Manuel G
> >>         <m.carrasco at imperial.ac.uk <mailto:m.carrasco at imperial.ac.uk
> <m.carrasco at imperial.ac.uk>>>
> >>         wrote:
> >>
> >>         Hi Marco!
> >>
> >>             I have a program that when compiled, adds a program header
> >>             that loads a data blob into a fixed memory location.
> >>
> >>         I'm sorry to ask, but could you explain a bit more how this
> >>         works? At first glance, I'd say that if any of this happens on
> >>         a stage later than LLVM-IR, it may be hard to mimic in KLEE.
> >
> >     I have a bunch of files that I add as .incbin into a section, and
> >     then my linker scripts put them in a fixed address when it links the
> >     program altogether. I think there is no way this would work with
> >     LLVM IR.
> >
> >>
> >>         As far as I understand, when KLEEexecutes a LLVM-IR load
> >>         instruction
> >>         <
> https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>,
> >>         it will try tofind
> >>         <
> https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191>the
> >>         MemoryObjects (more than one if it is a symbolic pointer) that
> >>         contain the address. Conceptually, you want KLEE to somehow
> >>         have a MemoryObject at the hardcoded address.
> >>
> >>         One way to go could be modelling this as a LLVM-IR
> >>         GlobalVariable at your fixed address with the content of your
> >>         blob.  If this makes sense, you may want to check thisfunction
> >>         <
> https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648>and
> >>         addExternalObject perhaps as well.
> >
> >     Thanks! This looks interesting, but I am a bit puzzled about how to
> >     go with this. Should I recompile KLEE to add support for my use
> >     case? I checked on the MemoryManager class and it seems like it just
> >     allocates stuff at whatever place is available.
> >
> >>
> >>         I apologise if you already know this!
> >
> >
> >     I did not know any of that :) This is the second time I am using
> >     KLEE, and the first one was a big failure :P
> >
> >     Thanks!
> >     Marco
> >
> >>
> >>         Best regards,
> >>         Manuel.
> >>
> >>
> ------------------------------------------------------------------------
> >>         *From:*klee-dev-bounces at imperial.ac.uk
> >>         <mailto:klee-dev-bounces at imperial.ac.uk
> <klee-dev-bounces at imperial.ac.uk>>
> >>         <klee-dev-bounces at imperial.ac.uk
> >>         <mailto:klee-dev-bounces at imperial.ac.uk
> <klee-dev-bounces at imperial.ac.uk>>> on behalf of Marco
> >>         Vanotti <mvanotti at dc.uba.ar <mailto:mvanotti at dc.uba.ar
> <mvanotti at dc.uba.ar>>>
> >>         *Sent:*16 June 2022 18:55
> >>         *To:*klee-dev <klee-dev at imperial.ac.uk
> >>         <mailto:klee-dev at imperial.ac.uk <klee-dev at imperial.ac.uk>>>
> >>         *Subject:*[klee-dev] Working with fixed memory locations.
> >>         Hi klee-dev!
> >>
> >>         I am new to KLEE, and have a question about using it with one
> >>         of my programs.
> >>
> >>         I have a program that when compiled, adds a program header
> >>         that loads a data blob into a fixed memory location.
> >>
> >>         This means that my program has this fixed memory location
> >>         hardcoded all around the place (also this blob has references
> >>         to itself).
> >>
> >>         I would like to load my program in KLEE to get a better
> >>         understanding of how it works. The problem I am facing is that
> >>         I have no idea how to make KLEE understand that I need this
> >>         blob mapped in that address.
> >>
> >>         This are the things I've tried:
> >>
> >>         * Using wllvm/gclang to get the full program linked together,
> >>         following my link script, then extracting the bc and running
> >>         that with KLEE. This didn't work. KLEE complains that the
> >>         pointers are invalid.
> >>
> >>         * Manually embedding the blob into my program as an array,
> >>         then calling `mmap` with `MAP_FIXED` to map the area that I
> >>         want and copying over the blob.
> >>
> >>         The issue here is that MAP_FIXED returns EPERM because
> >>         probably the address range I am trying to map is already mapped.
> >>
> >>
> >>         * Setting the KLEE deterministic allocations to encompass the
> >>         range that I care about, then doing a big `malloc` and making
> >>         sure that my range is inside that malloc chunk.
> >>
> >>         For this last one, I am using flags like:
> >>         --allocate-determ --allocate-determ-start-address=8404992
> >>         --allocate-determ-size=3145728
> >>
> >>         One of the things that I see is that KLEE fails to mmap big
> >>         chunks (in the order of 100MiB). But even if I decrease the
> >>         size, I still get failures when I try to assert things like:
> >>
> >>         uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
> >>         klee_assert(BASE_ADDR >= malloc_addr);
> >>         klee_assert(BASE_ADDR < malloc_addr + malloc_size);
> >>
> >>         ------
> >>
> >>         Something that might be relevant is that in reality I need two
> >>         of these blobs loaded into different regions of memory, but so
> >>         far I can't even get to load one. And they are not too far
> >>         apart from each other, so if, for example, the malloc approach
> >>         works, I could just increase the size and make the two
> >>         allocations.
> >>
> >>         One thing that might complicate things, is that these
> >>         addresses might collide with where KLEE tries to load the
> >>         program. I don't know how to deal with that either.
> >>
> >>         Any advice on how to tune KLEE for this use case?
> >>
> >>         Best Regards,
> >>         Marco
> >>         _______________________________________________
> >>         klee-dev mailing list
> >>         klee-dev at imperial.ac.uk <mailto:klee-dev at imperial.ac.uk
> <klee-dev at imperial.ac.uk>>
> >>         https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
> >>         <https://mailman.ic.ac.uk/mailman/listinfo/klee-dev>
> >
> >
> > _______________________________________________
> > klee-dev mailing list
> > klee-dev at imperial.ac.uk
> > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>
-------------- next part --------------
HTML attachment scrubbed and removed

From d.schemmel at imperial.ac.uk  Sun Jun 19 19:04:09 2022
From: d.schemmel at imperial.ac.uk (Daniel Schemmel)
Date: Sun, 19 Jun 2022 19:04:09 +0100
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <CAO7cxQX+A5YkXGA621pYxt4t3x857AaoxmTPFDWSGvMjTj7Aqg@mail.gmail.com>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
	<AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
	<48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>
	<CAO7cxQWLDT+2RE_1fTJ7M5SO6M69-VBs3JQ6OqevUXYUTUEcdw@mail.gmail.com>
	<CAO7cxQUcBFk=3g8_RqxE5-2D+Gci+fTeN6xEam0xUZt2yq6jZQ@mail.gmail.com>
	<2b611f4a-b3ab-1fa5-4ba1-44a56dfa443c@imperial.ac.uk>
	<CAO7cxQX+A5YkXGA621pYxt4t3x857AaoxmTPFDWSGvMjTj7Aqg@mail.gmail.com>
Message-ID: <27b9064b-c033-a822-f90a-143a698165fe@imperial.ac.uk>

Hi Marco,

I had a look at your stack trace, and the crash might have been caused 
by KLEE when building the solver query before passing it to the actual 
solver. Could you check out https://github.com/klee/klee/pull/1523 and 
see if that changes anything for you?

Best,
Daniel

On 2022-06-18 01:12, Marco Vanotti wrote:
> Hi Cristian,
>
> Thanks for your answer. I have tried *--optimize-array=all*, but that 
> didn't fix the problem :(.
>
> It would be a better?user experience to get an error message instead 
> of a segfault. In any case, if this is stopping because it's running 
> out of memory, is there a way to remove that restriction? My server 
> still had a few GiB to spare??.
>
>
> On Fri, Jun 17, 2022 at 2:53 AM Cristian Cadar 
> <c.cadar at imperial.ac.uk> wrote:
>
>     Hi Marco, you seem to be reaching an issue with the solver, which is
>     having trouble reasoning about the huge symbolic array (requiring
>     excessive time and memory).? You should try to shrink that array if
>     possible.? You can also try --optimize-array=all, but it might not
>     help
>     in your case.
>
>     Best,
>     Cristian
>
>     On 17/06/2022 05:02, Marco Vanotti wrote:
>     > After?letting it run for a few hours I've observed that klee
>     spawns a
>     > subprocess that keeps growing on memory until it reaches ~100GiB
>     and
>     > then it stops and restarts again.
>     > Nothing is being printed indicating an error, but I'm not sure
>     if the
>     > behavior is normal. This is with KLEE from the docker container.
>     >
>     > I've tried building KLEE from source, both with STP and Z3
>     support, and
>     > running my program makes it crash with a segfault :(
>     >
>     > Here is the backtrace for the crash with the STP solver:
>     > https://pastebin.com/raw/xpf9D9VD
>     <https://pastebin.com/raw/xpf9D9VD>
>     >
>     > Best Regards,
>     > Marco
>     >
>     > On Thu, Jun 16, 2022 at 3:48 PM Marco Vanotti <mvanotti at dc.uba.ar
>     > <mailto:mvanotti at dc.uba.ar>> wrote:
>     >
>     >? ? ?Hi Martin, Manuel,
>     >
>     >? ? ?Thanks for your answer :) !
>     >
>     >? ? ?On Thu, Jun 16, 2022 at 1:19 PM Nowack, Martin
>     >? ? ?<m.nowack at imperial.ac.uk <mailto:m.nowack at imperial.ac.uk>>
>     wrote:
>     >
>     >? ? ? ? ?Hi Marco,
>     >
>     >? ? ? ? ?Maybe the following helps you:
>     >
>     https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
>     >? ? ? ?
>     ?<https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c>
>     >
>     >
>     >? ? ?This seems to be what I am looking for,?thanks!. I tried
>     using it
>     >? ? ?for small variables and it works. However, for a big object
>     >? ? ?(0x256000 bytes) it shows the following warning:
>     >
>     >? ? ?*KLEE: WARNING ONCE*: flushing 2449408 bytes on read, may be
>     slow
>     >? ? ?and/or crash: MO195[2449408] allocated at main(): ?call void
>     >? ? ?@klee_define_fixed_object(i8* inttoptr (i64 8404992 to i8*), i64
>     >? ? ?2449408), !dbg !171
>     >? ? ?KLEE is still running, so maybe it just means it is slow.
>     >
>     >? ? ?I went with the approach of having my blob as a global
>     variable, and
>     >? ? ?then `memcpy` it into the address after calling
>     define_fixed_object.
>     >
>     >? ? ? ? ?Best,
>     >? ? ? ? ?Martin
>     >
>     >>? ? ? ? ?On 16. Jun 2022, at 20:43, Carrasco, Manuel G
>     >>? ? ? ? ?<m.carrasco at imperial.ac.uk
>     <mailto:m.carrasco at imperial.ac.uk>>
>     >>? ? ? ? ?wrote:
>     >>
>     >>? ? ? ? ?Hi Marco!
>     >>
>     >>? ? ? ? ? ? ?I have a program that when compiled, adds a program
>     header
>     >>? ? ? ? ? ? ?that loads a data blob into a fixed memory location.
>     >>
>     >>? ? ? ? ?I'm sorry to ask, but could you explain a bit more how this
>     >>? ? ? ? ?works? At first glance, I'd say that if any of this
>     happens on
>     >>? ? ? ? ?a stage later than LLVM-IR, it may be hard to mimic in
>     KLEE.
>     >
>     >? ? ?I have a bunch of files that I add as .incbin into a
>     section, and
>     >? ? ?then my linker scripts put them in a fixed address when it
>     links the
>     >? ? ?program altogether. I think there is no way this would work with
>     >? ? ?LLVM IR.
>     >
>     >>
>     >>? ? ? ? ?As far as I understand, when KLEEexecutes a LLVM-IR load
>     >>? ? ? ? ?instruction
>     >>? ? ? ?
>     ?<https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>,
>     >>? ? ? ? ?it will try tofind
>     >>? ? ? ?
>     ?<https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191>the
>     >>? ? ? ? ?MemoryObjects (more than one if it is a symbolic
>     pointer) that
>     >>? ? ? ? ?contain the address. Conceptually, you want KLEE to somehow
>     >>? ? ? ? ?have a MemoryObject at the hardcoded address.
>     >>
>     >>? ? ? ? ?One way to go could be modelling this as a LLVM-IR
>     >>? ? ? ? ?GlobalVariable at your fixed address with the content
>     of your
>     >>? ? ? ? ?blob.? If this makes sense, you may want to check
>     thisfunction
>     >>? ? ? ?
>     ?<https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648>and
>     >>? ? ? ? ?addExternalObject perhaps as well.
>     >
>     >? ? ?Thanks! This looks interesting, but I am a bit puzzled about
>     how to
>     >? ? ?go with this. Should I recompile KLEE to add support for my use
>     >? ? ?case? I checked on the MemoryManager class and it seems like
>     it just
>     >? ? ?allocates stuff at whatever place is available.
>     >
>     >>
>     >>? ? ? ? ?I apologise if you already know this!
>     >
>     >
>     >? ? ?I did not know any of that :) This is the second time I am using
>     >? ? ?KLEE, and the first one was a big failure :P
>     >
>     >? ? ?Thanks!
>     >? ? ?Marco
>     >
>     >>
>     >>? ? ? ? ?Best regards,
>     >>? ? ? ? ?Manuel.
>     >>
>     >>
>     ?------------------------------------------------------------------------
>     >>? ? ? ? ?*From:*klee-dev-bounces at imperial.ac.uk
>     >>? ? ? ? ?<mailto:klee-dev-bounces at imperial.ac.uk>
>     >>? ? ? ? ?<klee-dev-bounces at imperial.ac.uk
>     >>? ? ? ? ?<mailto:klee-dev-bounces at imperial.ac.uk>> on behalf of
>     Marco
>     >>? ? ? ? ?Vanotti <mvanotti at dc.uba.ar <mailto:mvanotti at dc.uba.ar>>
>     >>? ? ? ? ?*Sent:*16 June 2022 18:55
>     >>? ? ? ? ?*To:*klee-dev <klee-dev at imperial.ac.uk
>     >>? ? ? ? ?<mailto:klee-dev at imperial.ac.uk>>
>     >>? ? ? ? ?*Subject:*[klee-dev] Working with fixed memory locations.
>     >>? ? ? ? ?Hi klee-dev!
>     >>
>     >>? ? ? ? ?I am new to KLEE, and have a question about using it
>     with one
>     >>? ? ? ? ?of my programs.
>     >>
>     >>? ? ? ? ?I have a program that when compiled, adds a program header
>     >>? ? ? ? ?that loads a data blob into a fixed memory location.
>     >>
>     >>? ? ? ? ?This means that my program has this fixed memory location
>     >>? ? ? ? ?hardcoded all around the place (also this blob has
>     references
>     >>? ? ? ? ?to itself).
>     >>
>     >>? ? ? ? ?I would like to load my program in KLEE to get a better
>     >>? ? ? ? ?understanding of how it works. The problem I am facing
>     is that
>     >>? ? ? ? ?I have no idea how to make KLEE understand that I need this
>     >>? ? ? ? ?blob mapped in that address.
>     >>
>     >>? ? ? ? ?This are the things I've tried:
>     >>
>     >>? ? ? ? ?* Using wllvm/gclang to get the full program linked
>     together,
>     >>? ? ? ? ?following my link script, then extracting the bc and
>     running
>     >>? ? ? ? ?that with KLEE. This didn't work. KLEE complains that the
>     >>? ? ? ? ?pointers are invalid.
>     >>
>     >>? ? ? ? ?* Manually embedding the blob into my program as an array,
>     >>? ? ? ? ?then calling `mmap` with `MAP_FIXED` to map the area that I
>     >>? ? ? ? ?want and copying over the blob.
>     >>
>     >>? ? ? ? ?The issue here is that MAP_FIXED returns EPERM because
>     >>? ? ? ? ?probably the address range I am trying to map is
>     already mapped.
>     >>
>     >>
>     >>? ? ? ? ?* Setting the KLEE deterministic allocations to
>     encompass the
>     >>? ? ? ? ?range that I care about, then doing a big `malloc` and
>     making
>     >>? ? ? ? ?sure that my range is inside that malloc chunk.
>     >>
>     >>? ? ? ? ?For this last one, I am using flags like:
>     >>? ? ? ? ?--allocate-determ --allocate-determ-start-address=8404992
>     >>? ? ? ? ?--allocate-determ-size=3145728
>     >>
>     >>? ? ? ? ?One of the things that I see is that KLEE fails to mmap big
>     >>? ? ? ? ?chunks (in the order of 100MiB). But even if I decrease the
>     >>? ? ? ? ?size, I still get failures when I try to assert things
>     like:
>     >>
>     >>? ? ? ? ?uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
>     >>? ? ? ? ?klee_assert(BASE_ADDR >= malloc_addr);
>     >>? ? ? ? ?klee_assert(BASE_ADDR < malloc_addr?+ malloc_size);
>     >>
>     >>? ? ? ? ?------
>     >>
>     >>? ? ? ? ?Something that might be relevant is that in reality I
>     need two
>     >>? ? ? ? ?of these blobs loaded into different regions of memory,
>     but so
>     >>? ? ? ? ?far I can't even get to load one. And they are not too far
>     >>? ? ? ? ?apart from each other, so if, for example, the malloc
>     approach
>     >>? ? ? ? ?works, I could just increase the size and make the two
>     >>? ? ? ? ?allocations.
>     >>
>     >>? ? ? ? ?One thing that might complicate things, is that these
>     >>? ? ? ? ?addresses might collide with where KLEE tries to load the
>     >>? ? ? ? ?program. I don't know how to deal with that either.
>     >>
>     >>? ? ? ? ?Any advice on how to tune KLEE for this use case?
>     >>
>     >>? ? ? ? ?Best Regards,
>     >>? ? ? ? ?Marco
>     >> ?_______________________________________________
>     >>? ? ? ? ?klee-dev mailing list
>     >> klee-dev at imperial.ac.uk <mailto:klee-dev at imperial.ac.uk>
>     >> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>     >>? ? ? ? ?<https://mailman.ic.ac.uk/mailman/listinfo/klee-dev>
>     >
>     >
>     > _______________________________________________
>     > klee-dev mailing list
>     > klee-dev at imperial.ac.uk
>     > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>
>
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
-------------- next part --------------
HTML attachment scrubbed and removed

From mgarcp13 at gmail.com  Mon Jun 20 18:44:11 2022
From: mgarcp13 at gmail.com (=?UTF-8?B?TWFyaW8gR2FyY8OtYSBQw6lyZXo=?=)
Date: Mon, 20 Jun 2022 19:44:11 +0200
Subject: [klee-dev] Disallow errors on external calls
Message-ID: <CAKPnLs9qCA3EAMN36+wJPjVfZxNRopme_=7P3sOA4AO8cB8bxA@mail.gmail.com>

Hi,

I'm using klee with gnat-llvm generated bytecodes (to execute symbolically
Ada programs) and I have some problems.

When executing the program there are done some runtime checks, that are
done by calling to GNAT external functions, such as
__gnat_rcheck_CE_Overflow_Check. By running klee with option
--external-calls=none the call to external functions are disallowed but an
error is raised which caused that the path is not completed:

KLEE: output directory is
"/home/mario/automatic_ada_symbolic_execution/klee-out-15"
KLEE: Using STP solver backend
KLEE: WARNING: undefined reference to function:
__gnat_rcheck_CE_Overflow_Check
KLEE: WARNING ONCE: String not terminated by \0 passed to one of the klee_
functions
KLEE: WARNING: Disallowed call to external function:
__gnat_rcheck_CE_Overflow_Check



*KLEE: ERROR: (location information missing) external calls disallowedKLEE:
NOTE: now ignoring this error at this locationKLEE: WARNING: Disallowed
call to external function: __gnat_rcheck_CE_Overflow_Check*

KLEE: ERROR: (location information missing) external calls disallowed
KLEE: NOTE: now ignoring this error at this location
KLEE: WARNING: Disallowed call to external function:
__gnat_rcheck_CE_Overflow_Check

KLEE: ERROR: (location information missing) external calls disallowed
KLEE: NOTE: now ignoring this error at this location
KLEE: WARNING: Disallowed call to external function:
__gnat_rcheck_CE_Overflow_Check


KLEE: done: total instructions = 129
KLEE: done: completed paths = 4
*KLEE: done: partially completed paths = 4*
KLEE: done: generated tests = 7

There are any option to skip this error and complete the path?

In addition, I have a bytecode with all the gnat libraries, but linking
with it gives some errors while executing some instructions (the module is
broken, so I have to switch the option --disable-verify=true):

*klee: /home/mario/klee/include/klee/ADT/Bits.h:79: uint64_t
klee::bits64::truncateToNBits(uint64_t, unsigned int): Assertion `N > 0 &&
N <= 64' failed.*
 #0 0x00000000028dd261 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/mario/llvm-project-13.0.0.src/llvm/lib/Support/Unix/Signals.inc:565:22
 #1 0x00000000028dd324 PrintStackTraceSignalHandler(void*)
/home/mario/llvm-project-13.0.0.src/llvm/lib/Support/Unix/Signals.inc:632:1
 #2 0x00000000028db1ba llvm::sys::RunSignalHandlers()
/home/mario/llvm-project-13.0.0.src/llvm/lib/Support/Signals.cpp:97:20
 #3 0x00000000028dcc99 SignalHandler(int)
/home/mario/llvm-project-13.0.0.src/llvm/lib/Support/Unix/Signals.inc:407:1
 #4 0x00007f24b69b2140 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
 #5 0x00007f24b647bce1 raise (/lib/x86_64-linux-gnu/libc.so.6+0x3bce1)
 #6 0x00007f24b6465537 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25537)
 #7 0x00007f24b646540f (/lib/x86_64-linux-gnu/libc.so.6+0x2540f)
 #8 0x00007f24b6474662 (/lib/x86_64-linux-gnu/libc.so.6+0x34662)
 #9 0x0000000000429f8d /home/mario/klee/include/klee/ADT/Bits.h:79:7
#10 0x000000000044d389 klee::ConstantExpr::create(unsigned long, unsigned
int) /home/mario/klee/include/klee/ADT/Ref.h:93:7
#11 0x00000000004554f7 klee::Executor::evalConstant(llvm::Constant const*,
klee::KInstruction const*) /home/mario/klee/lib/Core/ExecutorUtil.cpp:63:73
#12 0x0000000000455752 llvm::StructLayout::getElementOffset(unsigned int)
const /usr/local/include/llvm/IR/DataLayout.h:635:5
#13 0x0000000000455752 llvm::StructLayout::getElementOffsetInBits(unsigned
int) const /usr/local/include/llvm/IR/DataLayout.h:640:28
#14 0x0000000000455752 klee::Executor::evalConstant(llvm::Constant const*,
klee::KInstruction const*) /home/mario/klee/lib/Core/ExecutorUtil.cpp:84:59
#15 0x000000000043985e klee::ref<klee::Expr>&
klee::ref<klee::Expr>::operator=<klee::ConstantExpr>(klee::ref<klee::ConstantExpr>&&)
/home/mario/klee/include/klee/ADT/Ref.h:188:5
#16 0x000000000043985e klee::Executor::bindModuleConstants()
/home/mario/klee/lib/Core/Executor.cpp:3384:49
#17 0x0000000000449efc klee::Executor::run(klee::ExecutionState&)
/home/mario/klee/lib/Core/Executor.cpp:3446:15
#18 0x000000000044b048 std::__uniq_ptr_impl<klee::PTree,
std::default_delete<klee::PTree> >::reset(klee::PTree*)
/usr/local/include/c++/12.0.1/bits/unique_ptr.h:179:16
#19 0x000000000044b048 std::unique_ptr<klee::PTree,
std::default_delete<klee::PTree> >::reset(klee::PTree*)
/usr/local/include/c++/12.0.1/bits/unique_ptr.h:460:12
#20 0x000000000044b048 std::unique_ptr<klee::PTree,
std::default_delete<klee::PTree> >::operator=(std::nullptr_t)
/usr/local/include/c++/12.0.1/bits/unique_ptr.h:401:7
#21 0x000000000044b048 klee::Executor::runFunctionAsMain(llvm::Function*,
int, char**, char**) /home/mario/klee/lib/Core/Executor.cpp:4437:17
#22 0x0000000000414be7 main /home/mario/klee/tools/klee/main.cpp:1532:5
#23 0x00007f24b6466d0a __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x26d0a)
#24 0x0000000000421d6a _start (/usr/local/bin/klee+0x421d6a)
Aborted (core dumped)

Why is this error due to? Is a problem with the bytecode or it can be
solved any way?

Thank you in advance.

Regards.
-------------- next part --------------
HTML attachment scrubbed and removed

From m.nowack at imperial.ac.uk  Mon Jun 20 21:03:45 2022
From: m.nowack at imperial.ac.uk (Nowack, Martin)
Date: Mon, 20 Jun 2022 20:03:45 +0000
Subject: [klee-dev] Disallow errors on external calls
In-Reply-To: <CAKPnLs9qCA3EAMN36+wJPjVfZxNRopme_=7P3sOA4AO8cB8bxA@mail.gmail.com>
References: <CAKPnLs9qCA3EAMN36+wJPjVfZxNRopme_=7P3sOA4AO8cB8bxA@mail.gmail.com>
Message-ID: <D6004F38-1DFC-4D86-A1A6-1667A103D3C2@imperial.ac.uk>

Hi Mario,

On 20. Jun 2022, at 18:44, Mario Garc?a P?rez <mgarcp13 at gmail.com<mailto:mgarcp13 at gmail.com>> wrote:

Hi,

I'm using klee with gnat-llvm generated bytecodes (to execute symbolically Ada programs) and I have some problems.

When executing the program there are done some runtime checks, that are done by calling to GNAT external functions, such as __gnat_rcheck_CE_Overflow_Check. By running klee with option --external-calls=none the call to external functions are disallowed but an error is raised which caused that the path is not completed:

KLEE: output directory is "/home/mario/automatic_ada_symbolic_execution/klee-out-15"
KLEE: Using STP solver backend
KLEE: WARNING: undefined reference to function: __gnat_rcheck_CE_Overflow_Check
KLEE: WARNING ONCE: String not terminated by \0 passed to one of the klee_ functions
KLEE: WARNING: Disallowed call to external function: __gnat_rcheck_CE_Overflow_Check

KLEE: ERROR: (location information missing) external calls disallowed
KLEE: NOTE: now ignoring this error at this location
KLEE: WARNING: Disallowed call to external function: __gnat_rcheck_CE_Overflow_Check

KLEE: ERROR: (location information missing) external calls disallowed
KLEE: NOTE: now ignoring this error at this location
KLEE: WARNING: Disallowed call to external function: __gnat_rcheck_CE_Overflow_Check

KLEE: ERROR: (location information missing) external calls disallowed
KLEE: NOTE: now ignoring this error at this location
KLEE: WARNING: Disallowed call to external function: __gnat_rcheck_CE_Overflow_Check


KLEE: done: total instructions = 129
KLEE: done: completed paths = 4
KLEE: done: partially completed paths = 4
KLEE: done: generated tests = 7

There are any option to skip this error and complete the path?

One way would be to remove the calls to those functions. Use an external LLVM opt pass or add this feature to KLEE, i.e. have a look here: https://github.com/klee/klee/tree/master/lib/Module to give you an idea.



In addition, I have a bytecode with all the gnat libraries, but linking with it gives some errors while executing some instructions (the module is broken, so I have to switch the option --disable-verify=true):

klee: /home/mario/klee/include/klee/ADT/Bits.h:79: uint64_t klee::bits64::truncateToNBits(uint64_t, unsigned int): Assertion `N > 0 && N <= 64' failed.
 #0 0x00000000028dd261 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/mario/llvm-project-13.0.0.src/llvm/lib/Support/Unix/Signals.inc:565:22
 #1 0x00000000028dd324 PrintStackTraceSignalHandler(void*) /home/mario/llvm-project-13.0.0.src/llvm/lib/Support/Unix/Signals.inc:632:1
 #2 0x00000000028db1ba llvm::sys::RunSignalHandlers() /home/mario/llvm-project-13.0.0.src/llvm/lib/Support/Signals.cpp:97:20
 #3 0x00000000028dcc99 SignalHandler(int) /home/mario/llvm-project-13.0.0.src/llvm/lib/Support/Unix/Signals.inc:407:1
 #4 0x00007f24b69b2140 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
 #5 0x00007f24b647bce1 raise (/lib/x86_64-linux-gnu/libc.so.6+0x3bce1)
 #6 0x00007f24b6465537 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25537)
 #7 0x00007f24b646540f (/lib/x86_64-linux-gnu/libc.so.6+0x2540f)
 #8 0x00007f24b6474662 (/lib/x86_64-linux-gnu/libc.so.6+0x34662)
 #9 0x0000000000429f8d /home/mario/klee/include/klee/ADT/Bits.h:79:7
#10 0x000000000044d389 klee::ConstantExpr::create(unsigned long, unsigned int) /home/mario/klee/include/klee/ADT/Ref.h:93:7
#11 0x00000000004554f7 klee::Executor::evalConstant(llvm::Constant const*, klee::KInstruction const*) /home/mario/klee/lib/Core/ExecutorUtil.cpp:63:73
#12 0x0000000000455752 llvm::StructLayout::getElementOffset(unsigned int) const /usr/local/include/llvm/IR/DataLayout.h:635:5
#13 0x0000000000455752 llvm::StructLayout::getElementOffsetInBits(unsigned int) const /usr/local/include/llvm/IR/DataLayout.h:640:28
#14 0x0000000000455752 klee::Executor::evalConstant(llvm::Constant const*, klee::KInstruction const*) /home/mario/klee/lib/Core/ExecutorUtil.cpp:84:59
#15 0x000000000043985e klee::ref<klee::Expr>& klee::ref<klee::Expr>::operator=<klee::ConstantExpr>(klee::ref<klee::ConstantExpr>&&) /home/mario/klee/include/klee/ADT/Ref.h:188:5
#16 0x000000000043985e klee::Executor::bindModuleConstants() /home/mario/klee/lib/Core/Executor.cpp:3384:49
#17 0x0000000000449efc klee::Executor::run(klee::ExecutionState&) /home/mario/klee/lib/Core/Executor.cpp:3446:15
#18 0x000000000044b048 std::__uniq_ptr_impl<klee::PTree, std::default_delete<klee::PTree> >::reset(klee::PTree*) /usr/local/include/c++/12.0.1/bits/unique_ptr.h:179:16
#19 0x000000000044b048 std::unique_ptr<klee::PTree, std::default_delete<klee::PTree> >::reset(klee::PTree*) /usr/local/include/c++/12.0.1/bits/unique_ptr.h:460:12
#20 0x000000000044b048 std::unique_ptr<klee::PTree, std::default_delete<klee::PTree> >::operator=(std::nullptr_t) /usr/local/include/c++/12.0.1/bits/unique_ptr.h:401:7
#21 0x000000000044b048 klee::Executor::runFunctionAsMain(llvm::Function*, int, char**, char**) /home/mario/klee/lib/Core/Executor.cpp:4437:17
#22 0x0000000000414be7 main /home/mario/klee/tools/klee/main.cpp:1532:5
#23 0x00007f24b6466d0a __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26d0a)
#24 0x0000000000421d6a _start (/usr/local/bin/klee+0x421d6a)
Aborted (core dumped)

Why is this error due to? Is a problem with the bytecode or it can be solved any way?

According to the stack trace, there is a constant generated that is larger than 64bit for an structure access.
Unfortunately, I cannot tell you anything more without bitcode.


Best,
Martin


-------------- next part --------------
HTML attachment scrubbed and removed

From mvanotti at dc.uba.ar  Tue Jun 21 01:41:02 2022
From: mvanotti at dc.uba.ar (Marco Vanotti)
Date: Mon, 20 Jun 2022 17:41:02 -0700
Subject: [klee-dev] Working with fixed memory locations.
In-Reply-To: <27b9064b-c033-a822-f90a-143a698165fe@imperial.ac.uk>
References: <CAO7cxQURxdLJPWQSkfs_16cqLxQ_-4krfqBJd1FAKxz7R5Hnyw@mail.gmail.com>
	<AM0PR0602MB3681E700FC8F505C72BE6297BEAC9@AM0PR0602MB3681.eurprd06.prod.outlook.com>
	<48B675F8-12C5-46F1-9EA0-2AFD1424EBE5@imperial.ac.uk>
	<CAO7cxQWLDT+2RE_1fTJ7M5SO6M69-VBs3JQ6OqevUXYUTUEcdw@mail.gmail.com>
	<CAO7cxQUcBFk=3g8_RqxE5-2D+Gci+fTeN6xEam0xUZt2yq6jZQ@mail.gmail.com>
	<2b611f4a-b3ab-1fa5-4ba1-44a56dfa443c@imperial.ac.uk>
	<CAO7cxQX+A5YkXGA621pYxt4t3x857AaoxmTPFDWSGvMjTj7Aqg@mail.gmail.com>
	<27b9064b-c033-a822-f90a-143a698165fe@imperial.ac.uk>
Message-ID: <CAO7cxQWRnMBONarqS+G3uz4=oUNJ_PofhkWa7yL4GvJhDWe=8A@mail.gmail.com>

Hi Daniel,

Thanks a lot for your suggestion. I've tried it and it solved the issue.
However, it moved it down to the solvers. Now it is STP and Z3 who get
their stacks blown up. See the backtrace here:
https://pastebin.com/raw/WE2M0bJf

I also set `ulimit -s unlimited` and now they all seem to be running.
This is what I am observing:

For the Z3 solver, KLEE has been running for ~25hs now and kept a steady
memory usage of ~35GiB. I don't know if it's making progress or if it is
stuck. Launch params: *--optimize-array=all --simplify-sym-indices
--solver-backend=z3*

For the STP solver, KLEE has been running for ~22hs (launch params:
*--optimize-array=all
--solver-backend=stp*), and I now realize that the behavior I described in
the previous email was due to the *-use-forked-server *default option. What
I am seeing is that new processes get spawned and consume progressively
more memory. Right now the child process runs for 50 minutes and consumes
155GiB of memory.

Here are some questions:

(1) Does it make sense to disable the forked server that wouldn't change
anything (in terms of speed and resource usage).

(2) Is there a way to see how these solvers are making progress?

(3) I ran the same experiment, but with *klee_assume(input[0] == 'x'),
input[i] = solution[i]* (i.e: setting an assumption on one byte of the
input and making the rest concrete). I expected this to finish sooner with
an answer, but it seems like it doesn't. Does this indicate that there's
something else symbolic besides my *klee_make_symbolic* call?

Best Regards,
Marco

On Sun, Jun 19, 2022 at 11:04 AM Daniel Schemmel <d.schemmel at imperial.ac.uk>
wrote:

> Hi Marco,
>
> I had a look at your stack trace, and the crash might have been caused by
> KLEE when building the solver query before passing it to the actual solver.
> Could you check out https://github.com/klee/klee/pull/1523 and see if
> that changes anything for you?
>
> Best,
> Daniel
> On 2022-06-18 01:12, Marco Vanotti wrote:
>
> Hi Cristian,
>
> Thanks for your answer. I have tried *--optimize-array=all*, but that
> didn't fix the problem :(.
>
> It would be a better user experience to get an error message instead of a
> segfault. In any case, if this is stopping because it's running out of
> memory, is there a way to remove that restriction? My server still had a
> few GiB to spare ?.
>
>
> On Fri, Jun 17, 2022 at 2:53 AM Cristian Cadar <c.cadar at imperial.ac.uk>
> wrote:
>
>> Hi Marco, you seem to be reaching an issue with the solver, which is
>> having trouble reasoning about the huge symbolic array (requiring
>> excessive time and memory).  You should try to shrink that array if
>> possible.  You can also try --optimize-array=all, but it might not help
>> in your case.
>>
>> Best,
>> Cristian
>>
>> On 17/06/2022 05:02, Marco Vanotti wrote:
>> > After letting it run for a few hours I've observed that klee spawns a
>> > subprocess that keeps growing on memory until it reaches ~100GiB and
>> > then it stops and restarts again.
>> > Nothing is being printed indicating an error, but I'm not sure if the
>> > behavior is normal. This is with KLEE from the docker container.
>> >
>> > I've tried building KLEE from source, both with STP and Z3 support, and
>> > running my program makes it crash with a segfault :(
>> >
>> > Here is the backtrace for the crash with the STP solver:
>> > https://pastebin.com/raw/xpf9D9VD <https://pastebin.com/raw/xpf9D9VD>
>> >
>> > Best Regards,
>> > Marco
>> >
>> > On Thu, Jun 16, 2022 at 3:48 PM Marco Vanotti <mvanotti at dc.uba.ar
>> > <mailto:mvanotti at dc.uba.ar>> wrote:
>> >
>> >     Hi Martin, Manuel,
>> >
>> >     Thanks for your answer :) !
>> >
>> >     On Thu, Jun 16, 2022 at 1:19 PM Nowack, Martin
>> >     <m.nowack at imperial.ac.uk <mailto:m.nowack at imperial.ac.uk>> wrote:
>> >
>> >         Hi Marco,
>> >
>> >         Maybe the following helps you:
>> >
>> https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
>> >         <
>> https://github.com/klee/klee/blob/292600cf54d5fd73278f67a4f98c2f955cbdaa10/test/Feature/DefineFixedObject.c
>> >
>> >
>> >
>> >     This seems to be what I am looking for, thanks!. I tried using it
>> >     for small variables and it works. However, for a big object
>> >     (0x256000 bytes) it shows the following warning:
>> >
>> >     *KLEE: WARNING ONCE*: flushing 2449408 bytes on read, may be slow
>> >     and/or crash: MO195[2449408] allocated at main():  call void
>> >     @klee_define_fixed_object(i8* inttoptr (i64 8404992 to i8*), i64
>> >     2449408), !dbg !171
>> >     KLEE is still running, so maybe it just means it is slow.
>> >
>> >     I went with the approach of having my blob as a global variable, and
>> >     then `memcpy` it into the address after calling define_fixed_object.
>> >
>> >         Best,
>> >         Martin
>> >
>> >>         On 16. Jun 2022, at 20:43, Carrasco, Manuel G
>> >>         <m.carrasco at imperial.ac.uk <mailto:m.carrasco at imperial.ac.uk>>
>> >>         wrote:
>> >>
>> >>         Hi Marco!
>> >>
>> >>             I have a program that when compiled, adds a program header
>> >>             that loads a data blob into a fixed memory location.
>> >>
>> >>         I'm sorry to ask, but could you explain a bit more how this
>> >>         works? At first glance, I'd say that if any of this happens on
>> >>         a stage later than LLVM-IR, it may be hard to mimic in KLEE.
>> >
>> >     I have a bunch of files that I add as .incbin into a section, and
>> >     then my linker scripts put them in a fixed address when it links the
>> >     program altogether. I think there is no way this would work with
>> >     LLVM IR.
>> >
>> >>
>> >>         As far as I understand, when KLEEexecutes a LLVM-IR load
>> >>         instruction
>> >>         <
>> https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L2722>,
>> >>         it will try tofind
>> >>         <
>> https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L4191>the
>> >>         MemoryObjects (more than one if it is a symbolic pointer) that
>> >>         contain the address. Conceptually, you want KLEE to somehow
>> >>         have a MemoryObject at the hardcoded address.
>> >>
>> >>         One way to go could be modelling this as a LLVM-IR
>> >>         GlobalVariable at your fixed address with the content of your
>> >>         blob.  If this makes sense, you may want to check thisfunction
>> >>         <
>> https://github.com/klee/klee/blob/master/lib/Core/Executor.cpp#L648>and
>> >>         addExternalObject perhaps as well.
>> >
>> >     Thanks! This looks interesting, but I am a bit puzzled about how to
>> >     go with this. Should I recompile KLEE to add support for my use
>> >     case? I checked on the MemoryManager class and it seems like it just
>> >     allocates stuff at whatever place is available.
>> >
>> >>
>> >>         I apologise if you already know this!
>> >
>> >
>> >     I did not know any of that :) This is the second time I am using
>> >     KLEE, and the first one was a big failure :P
>> >
>> >     Thanks!
>> >     Marco
>> >
>> >>
>> >>         Best regards,
>> >>         Manuel.
>> >>
>> >>
>>  ------------------------------------------------------------------------
>> >>         *From:*klee-dev-bounces at imperial.ac.uk
>> >>         <mailto:klee-dev-bounces at imperial.ac.uk>
>> >>         <klee-dev-bounces at imperial.ac.uk
>> >>         <mailto:klee-dev-bounces at imperial.ac.uk>> on behalf of Marco
>> >>         Vanotti <mvanotti at dc.uba.ar <mailto:mvanotti at dc.uba.ar>>
>> >>         *Sent:*16 June 2022 18:55
>> >>         *To:*klee-dev <klee-dev at imperial.ac.uk
>> >>         <mailto:klee-dev at imperial.ac.uk>>
>> >>         *Subject:*[klee-dev] Working with fixed memory locations.
>> >>         Hi klee-dev!
>> >>
>> >>         I am new to KLEE, and have a question about using it with one
>> >>         of my programs.
>> >>
>> >>         I have a program that when compiled, adds a program header
>> >>         that loads a data blob into a fixed memory location.
>> >>
>> >>         This means that my program has this fixed memory location
>> >>         hardcoded all around the place (also this blob has references
>> >>         to itself).
>> >>
>> >>         I would like to load my program in KLEE to get a better
>> >>         understanding of how it works. The problem I am facing is that
>> >>         I have no idea how to make KLEE understand that I need this
>> >>         blob mapped in that address.
>> >>
>> >>         This are the things I've tried:
>> >>
>> >>         * Using wllvm/gclang to get the full program linked together,
>> >>         following my link script, then extracting the bc and running
>> >>         that with KLEE. This didn't work. KLEE complains that the
>> >>         pointers are invalid.
>> >>
>> >>         * Manually embedding the blob into my program as an array,
>> >>         then calling `mmap` with `MAP_FIXED` to map the area that I
>> >>         want and copying over the blob.
>> >>
>> >>         The issue here is that MAP_FIXED returns EPERM because
>> >>         probably the address range I am trying to map is already
>> mapped.
>> >>
>> >>
>> >>         * Setting the KLEE deterministic allocations to encompass the
>> >>         range that I care about, then doing a big `malloc` and making
>> >>         sure that my range is inside that malloc chunk.
>> >>
>> >>         For this last one, I am using flags like:
>> >>         --allocate-determ --allocate-determ-start-address=8404992
>> >>         --allocate-determ-size=3145728
>> >>
>> >>         One of the things that I see is that KLEE fails to mmap big
>> >>         chunks (in the order of 100MiB). But even if I decrease the
>> >>         size, I still get failures when I try to assert things like:
>> >>
>> >>         uintptr_t malloc_addr = (uintptr_t) malloc(malloc_size);
>> >>         klee_assert(BASE_ADDR >= malloc_addr);
>> >>         klee_assert(BASE_ADDR < malloc_addr + malloc_size);
>> >>
>> >>         ------
>> >>
>> >>         Something that might be relevant is that in reality I need two
>> >>         of these blobs loaded into different regions of memory, but so
>> >>         far I can't even get to load one. And they are not too far
>> >>         apart from each other, so if, for example, the malloc approach
>> >>         works, I could just increase the size and make the two
>> >>         allocations.
>> >>
>> >>         One thing that might complicate things, is that these
>> >>         addresses might collide with where KLEE tries to load the
>> >>         program. I don't know how to deal with that either.
>> >>
>> >>         Any advice on how to tune KLEE for this use case?
>> >>
>> >>         Best Regards,
>> >>         Marco
>> >>         _______________________________________________
>> >>         klee-dev mailing list
>> >>         klee-dev at imperial.ac.uk <mailto:klee-dev at imperial.ac.uk>
>> >>         https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>> >>         <https://mailman.ic.ac.uk/mailman/listinfo/klee-dev>
>> >
>> >
>> > _______________________________________________
>> > klee-dev mailing list
>> > klee-dev at imperial.ac.uk
>> > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>>
>
> _______________________________________________
> klee-dev mailing listklee-dev at imperial.ac.ukhttps://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>
-------------- next part --------------
HTML attachment scrubbed and removed

From 1106929795 at qq.com  Tue Jun 21 15:05:43 2022
From: 1106929795 at qq.com (=?gb18030?B?t7+6z777?=)
Date: Tue, 21 Jun 2022 22:05:43 +0800
Subject: [klee-dev] Unable to load symbol(_ZTVNSt3__18ios_baseE) while
	initializing globals
Message-ID: <tencent_8CCA5D4031C530F225909D45CB9FC860BB0A@qq.com>

##### **An error "Unable to load symbol(_ZTVNSt3_18ios_baseE)while initializing globals" occurred when running in klee.**

**1.After I use the wllvm tool to compile the packJPG project into an executable file??packJPG, I use its script to convert the packJPG executable file into a bitcode file??packJPG.bc**

```
To ensure that the functionality of the executables obtained by wllvm is not compromised, and consistent with the executables obtained using the project's own build method, I ran them with the same test case and got the same compression ratio.

wllvm compile command:

$ export LLVM_COMPILER=clang
$ export WLLVM_OUPUT=DEBUG
$ export CC=/usr/local/bin/wllvm
$ export CXX=/usr/local/bin/wllvm++
$ export CFLAGS="-g -O1 -Xclang -disable-llvm-passes -D__NO_STRING_INLINES &nbsp;-D_FORTIFY_SOURCE=0 -U__OPTIMIZE__"

$ wllvm++ -c -o bitops.o bitops.cpp -stdlib=libc++
$ wllvm++ -c -o aricoder.o aricoder.cpp -stdlib=libc++
$ wllvm++ -c -o packjpg.o packjpg.cpp -stdlib=libc++
$ wllvm++ -o packJPG bitops.o aricoder.o packjpg.o -stdlib=libc++ -lc++experimental

$ export LLVM_LINK_NAME=llvm-link-11
$ export LLVM_AR_NAME=llvm-ar-11
$ extract-bc packJPG
```

**2?When running this bitcode file with klee, the following error occurred?**

```
KLEE:ERROR:Unable to load symbol(_ZTVNSt3_18ios_baseE)while initializing globals
```

I found this symbol in the symbol table of the libc++.so library that the packJPG project depends on.

**3?I have tried several methods to solve this error.**

```
(1)Add a parameter of klee to the running command: -link-llvm-lib.But it didn't solve my problem, because turning the system library into a bitcode file is still an expensive method.
(2)It is found that the compiler set in the original Makefile of the packJPG project is gcc and the dependent libraries are set to be statically linked. Now I don't know how to migrate the static dependency library (-static-libgcc -static-libstdc++) of the gcc compiler to the static library of the corresponding clang compiler.
I tried -static-libc++ but it doesn't seem to work
```

Has anyone encountered this error? Or is there any possible workaround?
Expecting a reply!
-------------- next part --------------
HTML attachment scrubbed and removed

From m.nowack at imperial.ac.uk  Tue Jun 21 16:09:06 2022
From: m.nowack at imperial.ac.uk (Nowack, Martin)
Date: Tue, 21 Jun 2022 15:09:06 +0000
Subject: [klee-dev] Unable to load symbol(_ZTVNSt3__18ios_baseE)
	while	initializing globals
In-Reply-To: <tencent_8CCA5D4031C530F225909D45CB9FC860BB0A@qq.com>
References: <tencent_8CCA5D4031C530F225909D45CB9FC860BB0A@qq.com>
Message-ID: <38865431-3BFF-4ED6-B295-1101827B19BA@imperial.ac.uk>

Hi,

One issue could be that during compilation the wrong include files are used.
Make sure you use the include files provided with libc++ implementation you use for KLEE.

Please refer to the following documentation to get further information:

https://libcxx.llvm.org/UsingLibcxx.html#using-a-custom-built-libc


Best,
Martin


On 21. Jun 2022, at 15:05, ??? <1106929795 at qq.com<mailto:1106929795 at qq.com>> wrote:

##### **An error "Unable to load symbol(_ZTVNSt3_18ios_baseE)while initializing globals" occurred when running in klee.**

**1.After I use the wllvm tool to compile the packJPG project into an executable file??packJPG, I use its script to convert the packJPG executable file into a bitcode file??packJPG.bc**

```
To ensure that the functionality of the executables obtained by wllvm is not compromised, and consistent with the executables obtained using the project's own build method, I ran them with the same test case and got the same compression ratio.

wllvm compile command:

$ export LLVM_COMPILER=clang
$ export WLLVM_OUPUT=DEBUG
$ export CC=/usr/local/bin/wllvm
$ export CXX=/usr/local/bin/wllvm++
$ export CFLAGS="-g -O1 -Xclang -disable-llvm-passes -D__NO_STRING_INLINES  -D_FORTIFY_SOURCE=0 -U__OPTIMIZE__"

$ wllvm++ -c -o bitops.o bitops.cpp -stdlib=libc++
$ wllvm++ -c -o aricoder.o aricoder.cpp -stdlib=libc++
$ wllvm++ -c -o packjpg.o packjpg.cpp -stdlib=libc++
$ wllvm++ -o packJPG bitops.o aricoder.o packjpg.o -stdlib=libc++ -lc++experimental

$ export LLVM_LINK_NAME=llvm-link-11
$ export LLVM_AR_NAME=llvm-ar-11
$ extract-bc packJPG
```

**2?When running this bitcode file with klee, the following error occurred?**

```
KLEE:ERROR:Unable to load symbol(_ZTVNSt3_18ios_baseE)while initializing globals
```

I found this symbol in the symbol table of the libc++.so library that the packJPG project depends on.

**3?I have tried several methods to solve this error.**

```
(1)Add a parameter of klee to the running command: -link-llvm-lib.But it didn't solve my problem, because turning the system library into a bitcode file is still an expensive method.
(2)It is found that the compiler set in the original Makefile of the packJPG project is gcc and the dependent libraries are set to be statically linked. Now I don't know how to migrate the static dependency library (-static-libgcc -static-libstdc++) of the gcc compiler to the static library of the corresponding clang compiler.
I tried -static-libc++ but it doesn't seem to work
```

Has anyone encountered this error? Or is there any possible workaround?
Expecting a reply!


_______________________________________________
klee-dev mailing list
klee-dev at imperial.ac.uk<mailto:klee-dev at imperial.ac.uk>
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev

-------------- next part --------------
HTML attachment scrubbed and removed

From prncoprs at 163.com  Sat Jun 25 18:40:57 2022
From: prncoprs at 163.com (prncoprs at 163.com)
Date: Sat, 25 Jun 2022 17:40:57 +0000
Subject: [klee-dev]  How can I use shared memory correctly in KLEE?
Message-ID: <TYCP286MB1561983567EF73F70B158C48FAB79@TYCP286MB1561.JPNP286.PROD.OUTLOOK.COM>

Dear all,

I want to use shared memory in klee, so that I can expose some info of the klee to other processes in the same operate system.

I use the POSIX `shm_open()` to get a shared memory fd `shm_fd`, after I use `ftruncate()` to set the size, then I use `mmap()` to get the shared memory address `(int *)shm_region` in the klee program. However, I find that the value and content of `(int *)shm_region` changes. For example, when I first got the value of `shm_region`, it is 0x7f8892da0000, and I set the content of the `shm_region` to 0. But after a while, I found the value of `shm_region` was changed to 0x55658e481eb4, the content of `shm_region[0]` is 267633609, without any my manually modified.

After I checked the mailing list, I found that klee did not support multi-processes. However, I think this is just an inter-processes communication issue rather the multi-processes. Could someone tell me why the shared memory address changes in klee?

I also tried other IPC methods, like shared files and PIPE, and they work correctly. Does this mean that I cannot use shared memory in klee to do the IPC?

Thanks!

Best wishes,
Chaoqi
-------------- next part --------------
HTML attachment scrubbed and removed

From m.nowack at imperial.ac.uk  Mon Jun 27 15:19:34 2022
From: m.nowack at imperial.ac.uk (Nowack, Martin)
Date: Mon, 27 Jun 2022 14:19:34 +0000
Subject: [klee-dev] How can I use shared memory correctly in KLEE?
In-Reply-To: <TYCP286MB1561983567EF73F70B158C48FAB79@TYCP286MB1561.JPNP286.PROD.OUTLOOK.COM>
References: <TYCP286MB1561983567EF73F70B158C48FAB79@TYCP286MB1561.JPNP286.PROD.OUTLOOK.COM>
Message-ID: <55706CA4-AF67-4CCE-ADD1-ED450CC01C74@imperial.ac.uk>

Hi Chaoqi,

Can you clarify: Do you want to test software that uses `shm_*` or do you want communicate with the KLEE process itself?

KLEE should not modify any `shm` allocated objects.

The only unintended modification that could happen is if your tested application uses external function calls that somehow manipulate that memory.

Best,
Martin

On 25. Jun 2022, at 18:40, prncoprs at 163.com<mailto:prncoprs at 163.com> wrote:

Dear all,

I want to use shared memory in klee, so that I can expose some info of the klee to other processes in the same operate system.

I use the POSIX `shm_open()` to get a shared memory fd `shm_fd`, after I use `ftruncate()` to set the size, then I use `mmap()` to get the shared memory address `(int *)shm_region` in the klee program. However, I find that the value and content of `(int *)shm_region` changes. For example, when I first got the value of `shm_region`, it is 0x7f8892da0000, and I set the content of the `shm_region` to 0. But after a while, I found the value of `shm_region` was changed to 0x55658e481eb4, the content of `shm_region[0]` is 267633609, without any my manually modified.

After I checked the mailing list, I found that klee did not support multi-processes. However, I think this is just an inter-processes communication issue rather the multi-processes. Could someone tell me why the shared memory address changes in klee?

I also tried other IPC methods, like shared files and PIPE, and they work correctly. Does this mean that I cannot use shared memory in klee to do the IPC?

Thanks!

Best wishes,
Chaoqi
_______________________________________________
klee-dev mailing list
klee-dev at imperial.ac.uk<mailto:klee-dev at imperial.ac.uk>
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev

-------------- next part --------------
HTML attachment scrubbed and removed

From prncoprs at 163.com  Mon Jun 27 15:53:31 2022
From: prncoprs at 163.com (Chaoqi Zhang)
Date: Mon, 27 Jun 2022 22:53:31 +0800
Subject: [klee-dev] How can I use shared memory correctly in KLEE?
In-Reply-To: <55706CA4-AF67-4CCE-ADD1-ED450CC01C74@imperial.ac.uk>
References: <TYCP286MB1561983567EF73F70B158C48FAB79@TYCP286MB1561.JPNP286.PROD.OUTLOOK.COM>
	<55706CA4-AF67-4CCE-ADD1-ED450CC01C74@imperial.ac.uk>
Message-ID: <F660F310-3A25-42CC-A2C3-C7816B3322DB@163.com>

Dear Martin,

Really thanks for your reply!

I want to communicate with the KLEE process itself, not the tested software. 

I insert the `shm_*` code into the executor.cpp, so that the Executor in KLEE can communicate with other process.

Best wishes,
Chaoqi

> On Jun 27, 2022, at 22:19, Nowack, Martin <m.nowack at imperial.ac.uk> wrote:
> 
> Hi Chaoqi,
> 
> Can you clarify: Do you want to test software that uses `shm_*` or do you want communicate with the KLEE process itself?
> 
> KLEE should not modify any `shm` allocated objects.
> 
> The only unintended modification that could happen is if your tested application uses external function calls that somehow manipulate that memory.
> 
> Best,
> Martin
> 
>> On 25. Jun 2022, at 18:40, prncoprs at 163.com <mailto:prncoprs at 163.com> wrote:
>> 
>> Dear all,
>>  
>> I want to use shared memory in klee, so that I can expose some info of the klee to other processes in the same operate system.
>>  
>> I use the POSIX `shm_open()` to get a shared memory fd `shm_fd`, after I use `ftruncate()` to set the size, then I use `mmap()` to get the shared memory address `(int *)shm_region` in the klee program. However, I find that the value and content of `(int *)shm_region` changes. For example, when I first got the value of `shm_region`, it is 0x7f8892da0000, and I set the content of the `shm_region` to 0. But after a while, I found the value of `shm_region` was changed to 0x55658e481eb4, the content of `shm_region[0]` is 267633609, without any my manually modified.
>>  
>> After I checked the mailing list, I found that klee did not support multi-processes. However, I think this is just an inter-processes communication issue rather the multi-processes. Could someone tell me why the shared memory address changes in klee? 
>>  
>> I also tried other IPC methods, like shared files and PIPE, and they work correctly. Does this mean that I cannot use shared memory in klee to do the IPC?
>>  
>> Thanks!
>>  
>> Best wishes,
>> Chaoqi
>> _______________________________________________
>> klee-dev mailing list
>> klee-dev at imperial.ac.uk <mailto:klee-dev at imperial.ac.uk>
>> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev <https://mailman.ic.ac.uk/mailman/listinfo/klee-dev>

-------------- next part --------------
HTML attachment scrubbed and removed

From m.nowack at imperial.ac.uk  Mon Jun 27 21:22:06 2022
From: m.nowack at imperial.ac.uk (Nowack, Martin)
Date: Mon, 27 Jun 2022 20:22:06 +0000
Subject: [klee-dev] How can I use shared memory correctly in KLEE?
In-Reply-To: <F660F310-3A25-42CC-A2C3-C7816B3322DB@163.com>
References: <TYCP286MB1561983567EF73F70B158C48FAB79@TYCP286MB1561.JPNP286.PROD.OUTLOOK.COM>
	<55706CA4-AF67-4CCE-ADD1-ED450CC01C74@imperial.ac.uk>
	<F660F310-3A25-42CC-A2C3-C7816B3322DB@163.com>
Message-ID: <684D0F34-4329-4E0C-854D-8F0C0FC83FA7@imperial.ac.uk>

Hi Chaoqi,



On 27. Jun 2022, at 15:53, Chaoqi Zhang <prncoprs at 163.com<mailto:prncoprs at 163.com>> wrote:

I want to communicate with the KLEE process itself, not the tested software.

I insert the `shm_*` code into the executor.cpp, so that the Executor in KLEE can communicate with other process.

Just a guess. Depending on where exactly you insert the call,  by any chance is the call executed multiple times?
(Maybe cross-check it with a dirty but useful `llvm::errs() << ?shm_open has been called\n?;` or `klee_warning(?...")`)

Best,
Martin



Best wishes,
Chaoqi

On Jun 27, 2022, at 22:19, Nowack, Martin <m.nowack at imperial.ac.uk<mailto:m.nowack at imperial.ac.uk>> wrote:

Hi Chaoqi,

Can you clarify: Do you want to test software that uses `shm_*` or do you want communicate with the KLEE process itself?

KLEE should not modify any `shm` allocated objects.

The only unintended modification that could happen is if your tested application uses external function calls that somehow manipulate that memory.

Best,
Martin

On 25. Jun 2022, at 18:40, prncoprs at 163.com<mailto:prncoprs at 163.com> wrote:

Dear all,

I want to use shared memory in klee, so that I can expose some info of the klee to other processes in the same operate system.

I use the POSIX `shm_open()` to get a shared memory fd `shm_fd`, after I use `ftruncate()` to set the size, then I use `mmap()` to get the shared memory address `(int *)shm_region` in the klee program. However, I find that the value and content of `(int *)shm_region` changes. For example, when I first got the value of `shm_region`, it is 0x7f8892da0000, and I set the content of the `shm_region` to 0. But after a while, I found the value of `shm_region` was changed to 0x55658e481eb4, the content of `shm_region[0]` is 267633609, without any my manually modified.

After I checked the mailing list, I found that klee did not support multi-processes. However, I think this is just an inter-processes communication issue rather the multi-processes. Could someone tell me why the shared memory address changes in klee?

I also tried other IPC methods, like shared files and PIPE, and they work correctly. Does this mean that I cannot use shared memory in klee to do the IPC?

Thanks!

Best wishes,
Chaoqi
_______________________________________________
klee-dev mailing list
klee-dev at imperial.ac.uk<mailto:klee-dev at imperial.ac.uk>
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev



-------------- next part --------------
HTML attachment scrubbed and removed

From m.nowack at imperial.ac.uk  Wed Jun 29 10:02:43 2022
From: m.nowack at imperial.ac.uk (Nowack, Martin)
Date: Wed, 29 Jun 2022 09:02:43 +0000
Subject: [klee-dev] Unable to load symbol(_ZTVNSt3__18ios_baseE) while
 initializing globals
In-Reply-To: <tencent_408CEA09796734F29632F3AE0317504C8B08@qq.com>
References: <tencent_8CCA5D4031C530F225909D45CB9FC860BB0A@qq.com>
	<38865431-3BFF-4ED6-B295-1101827B19BA@imperial.ac.uk>
	<tencent_408CEA09796734F29632F3AE0317504C8B08@qq.com>
Message-ID: <25F25604-83CA-4139-8FEB-60BF7DE52647@imperial.ac.uk>

Hi,

It?s a bit complicated, in a nutshell, you *don?t* want to use the system library and paths:

```
clang++ -nostdinc++ -nostdlib++   -isystem <install>/include/c++/v  test.cpp -c -emit-llvm -o test.bc
```

`<install>` refers to your installation path of your KLEE libc++ installation.

Best,
Martin



> On 29. Jun 2022, at 09:55, ??? <1106929795 at qq.com> wrote:
> 
> 
> Thank you for your reply! 
> 
> I used the -stdlib=libc++ parameter on the command line, and in the final executable file I can use the ldd command to see that the dynamic library it depends on includes libc++, I am not sure if this proves that I am using this library correctly?
> 
> ------------------ ???? ------------------
> ???: "Nowack, Martin" <m.nowack at imperial.ac.uk>;
> ????: 2022?6?21?(???) ??11:09
> ???: "???"<1106929795 at qq.com>;
> ??: "klee-dev"<klee-dev at imperial.ac.uk>;
> ??: Re: [klee-dev] Unable to load symbol(_ZTVNSt3__18ios_baseE) while initializing globals
> 
> Hi,
> 
> One issue could be that during compilation the wrong include files are used.
> Make sure you use the include files provided with libc++ implementation you use for KLEE.
> 
> Please refer to the following documentation to get further information:
> 
> https://libcxx.llvm.org/UsingLibcxx.html#using-a-custom-built-libc
> 
> 
> Best,
> Martin
> 
> 
>> On 21. Jun 2022, at 15:05, ??? <1106929795 at qq.com> wrote:
>> 
>> 
>> ##### **An error "Unable to load symbol(_ZTVNSt3_18ios_baseE)while initializing globals" occurred when running in klee.**
>> 
>> 
>> 
>> **1.After I use the wllvm tool to compile the packJPG project into an executable file??packJPG, I use its script to convert the packJPG executable file into a bitcode file??packJPG.bc**
>> 
>> 
>> 
>> ```
>> 
>> To ensure that the functionality of the executables obtained by wllvm is not compromised, and consistent with the executables obtained using the project's own build method, I ran them with the same test case
>>  and got the same compression ratio.
>> 
>> 
>> 
>> 
>> wllvm compile command:
>> 
>> 
>> 
>> $ export LLVM_COMPILER=clang
>> 
>> $ export WLLVM_OUPUT=DEBUG
>> 
>> $ export CC=/usr/local/bin/wllvm
>> 
>> $ export CXX=/usr/local/bin/wllvm++
>> 
>> $ export CFLAGS="-g -O1 -Xclang -disable-llvm-passes -D__NO_STRING_INLINES  -D_FORTIFY_SOURCE=0 -U__OPTIMIZE__"
>> 
>> 
>> 
>> $ wllvm++ -c -o bitops.o bitops.cpp -stdlib=libc++
>> 
>> $ wllvm++ -c -o aricoder.o aricoder.cpp -stdlib=libc++
>> 
>> $ wllvm++ -c -o packjpg.o packjpg.cpp -stdlib=libc++
>> 
>> $ wllvm++ -o packJPG bitops.o aricoder.o packjpg.o -stdlib=libc++ -lc++experimental
>> 
>> 
>> 
>> $ export LLVM_LINK_NAME=llvm-link-11
>> 
>> $ export LLVM_AR_NAME=llvm-ar-11
>> 
>> $ extract-bc packJPG
>> 
>> ```
>> 
>> 
>> 
>> **2?When running this bitcode file with klee, the following error occurred?**
>> 
>> 
>> 
>> ```
>> 
>> KLEE:ERROR:Unable to load symbol(_ZTVNSt3_18ios_baseE)while initializing globals
>> 
>> ```
>> 
>> 
>> 
>> I found this symbol in the symbol table of the libc++.so library that the packJPG project depends on.
>> 
>> 
>> 
>> **3?I have tried several methods to solve this error.**
>> 
>> 
>> 
>> ```
>> 
>> (1)Add a parameter of klee to the running command: -link-llvm-lib.But it didn't solve my problem, because turning the system library into a bitcode file is still an expensive method.
>> 
>> (2)It is found that the compiler set in the original Makefile of the packJPG project is gcc and the dependent libraries are set to be statically linked. Now I don't know how to migrate the static dependency
>>  library (-static-libgcc -static-libstdc++) of the gcc compiler to the static library of the corresponding clang compiler.
>> 
>> 
>> I tried -static-libc++ but it doesn't seem to work
>> 
>> ```
>> 
>> 
>> 
>> Has anyone encountered this error? Or is there any possible workaround?
>> 
>> Expecting a reply!
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> klee-dev mailing list
>> klee-dev at imperial.ac.uk
>> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
>