[PHP-DEV] Re: non-PIC build broken on oss-fuzz

[Stanislav Malyshev]

Hi!

On 9/9/19 2:16 AM, Dmitry Stogov wrote:
> I've just rechecked, when PHP configured with "--with-pic", libtool
> generates only PIC object files and there is no difference between *.lo
> to *.o files.

Sorry, you were right, --with-pic works, it was my mistake.


-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] non-PIC build broken on oss-fuzz

[M. W. Moe]

ok got thru the link: I think it's written in plain sight `recompile with
-fPIE and relink with -pie`.

On Mon, Sep 9, 2019 at 10:42 AM M. W. Moe  wrote:

> You try to mix static and dynamic linkage; there is something wrong
> regarding the setup of target platform;
> enumerate details about flavors.
>
>
> On Sun, Sep 8, 2019 at 10:13 PM Stanislav Malyshev 
> wrote:
>
>> Hi!
>>
>> Looks like commit eef85229d0fe9f69d325aa0231e592f35c468afb broke
>> oss-fuzz builds:
>>
>> https://oss-fuzz-build-logs.storage.googleapis.com/log-66ab74a7-4ece-4e14-b21b-f60527dd7244.txt
>>
>> The error message is:
>>
>> Step #4: /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `php_stripslashes'
>> with pointer equality in `ext/standard/string.o' can not be used when
>> making an executable; recompile with -fPIE and relink with -pie
>> Step #4: clang-10: error: linker command failed with exit code 1 (use -v
>> to see invocation)
>> Step #4: make: *** [sapi/cli/php] Error 1
>> Step #4: Makefile:264: recipe for target 'sapi/cli/php' failed
>>
>> I'm not sure I understand what's going on here - I suspect the non-PIC
>> build somehow conflicts with stripslashes optimizations, but I don't
>> know the details. May be specific to clan builds...
>> --
>> Stas Malyshev
>> smalys...@gmail.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] non-PIC build broken on oss-fuzz

[M. W. Moe]

You try to mix static and dynamic linkage; there is something wrong
regarding the setup of target platform;
enumerate details about flavors.


On Sun, Sep 8, 2019 at 10:13 PM Stanislav Malyshev 
wrote:

> Hi!
>
> Looks like commit eef85229d0fe9f69d325aa0231e592f35c468afb broke
> oss-fuzz builds:
>
> https://oss-fuzz-build-logs.storage.googleapis.com/log-66ab74a7-4ece-4e14-b21b-f60527dd7244.txt
>
> The error message is:
>
> Step #4: /usr/bin/ld: dynamic STT_GNU_IFUNC symbol `php_stripslashes'
> with pointer equality in `ext/standard/string.o' can not be used when
> making an executable; recompile with -fPIE and relink with -pie
> Step #4: clang-10: error: linker command failed with exit code 1 (use -v
> to see invocation)
> Step #4: make: *** [sapi/cli/php] Error 1
> Step #4: Makefile:264: recipe for target 'sapi/cli/php' failed
>
> I'm not sure I understand what's going on here - I suspect the non-PIC
> build somehow conflicts with stripslashes optimizations, but I don't
> know the details. May be specific to clan builds...
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Re: FFI extension / NULL-Checks

[Christoph M. Becker]

On 09.09.2019 at 08:03, Philip Hofstetter wrote:

> (I'm writing to the internals list because I don't think that at this
> point, FFI usage is wide-spread enough to get an opinion on other venues)
>
> maybe I'm just stupid, but I think there has been a slight oversight in the
> API design for the FFI interface.
>
> My problem is with functions that return a pointer to a struct as an out
> parameter.
>
> So in C, it would look like this:
>
> Error* err;
> func();
>
> if (err != NULL){
>do_error_handling();
> }
>
> If I translate this to PHP FFI, I would do
>
> $err = $ffi->new("Error*");
> $ffi->func(FFI::addr($err));
>
> if I `var_dump` $err, I do see a public {0} property be set to NULL or to
> actual error data.
>
> My issue is though: How do I check whether err* as been assgined to?

You could check FFI::addr($err)[0]:

  $err = $ffi->new("Error*");
  $perr = FFI::addr($err);
  $ffi->func($perr);
  var_dump(is_null($perr[0]));
  FFI::free($perr);

Not sure if it's supposed to require this indirection, though.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: FFI extension / NULL-Checks

[Philip Hofstetter]

In response to these findings so far, I have now submitted

https://github.com/php/php-src/pull/4691

that adds an FFI::isNull() method that returns true if the passed CData
instance points to NULL.

If you agree that something like this is indeed needed, I will gladly
update the PR and add unit tests.

Philip

On Mon, Sep 9, 2019 at 8:03 AM Philip Hofstetter 
wrote:

> Hello,
>
> (I'm writing to the internals list because I don't think that at this
> point, FFI usage is wide-spread enough to get an opinion on other venues)
>
> maybe I'm just stupid, but I think there has been a slight oversight in
> the API design for the FFI interface.
>
> My problem is with functions that return a pointer to a struct as an out
> parameter.
>
> So in C, it would look like this:
>
> Error* err;
> func();
>
> if (err != NULL){
>do_error_handling();
> }
>
> If I translate this to PHP FFI, I would do
>
> $err = $ffi->new("Error*");
> $ffi->func(FFI::addr($err));
>
> if I `var_dump` $err, I do see a public {0} property be set to NULL or to
> actual error data.
>
> My issue is though: How do I check whether err* as been assgined to?
>
> isset($err)
> $err[0] != null
> -> is always true, regardless of whether func as assigned an error or not
>
> isset($err->{0})
> isset($err[0])
> -> Cannot use object of type FFI\CData as array
>
> $err->{0} != NULL;
> -> FFI\Exception: NULL pointer dereference
>
> $err[0];
> -> segfault
>
> I'm sure I must be doing something wrong, but I don't know what. Also, the
> documentation could do with an example on how to achieve the desired result
> and, TBH, I think some of the various attempts produce a somewhat
> unexpected output.
>
> Any comments?
>
> Philip
>
>
> var_dump(isset($r->{0}));
> -> Error:  Cannot use object of type FFI\CData as array
>
> $a = '{0}';
> var_dump(isset($r->$a));
> -> Error:  Cannot use object of type FFI\CData as array
>
>
> var_dump(isset($r[0]));
> var_dump($r[0]);
>
>
>

-- 
Sensational AG
Giesshübelstrasse 62c, Postfach 1966, 8021 Zürich
Tel. +41 43 544 09 60, Mobile  +41 79 341 01 99
i...@sensational.ch, http://www.sensational.ch

Re: [PHP-DEV] FFI extension / NULL-Checks

[Philip Hofstetter]

On Mon, Sep 9, 2019 at 10:13 AM Stanislav Malyshev 
wrote:


> > isset($err)
> > $err[0] != null
> > -> is always true, regardless of whether func as assigned an error or not
> >
> > $err[0];
> > -> segfault
>
> This is a bit confusing - if $err[0] segfaults, how it can be != null?
> Does this behave differently in different contexts? Anyway, it shouldn't
> probably segfault in any case, so this looks like a bug.
>

I think there are a few disconnected issues. One is that checking something
for being NULL is a bit tricky with the given API and the other is that the
API around FFI\CData is a bit inconsistent and tricky to use.

Given

$err = $ffi->new("Error*");

what the library does is assume that $err is now a pointer to an array
(which is what C does I guess), but yet, there seems to be a bit of an
issue with actually accessing that array (if it's set to NULL) - and also,
don't use var_dump() to inspect it - that's deceptive because there's a
debug_info handler that knows ore than the actual field accessors (which
too makes this more complicated than needed).

So. Let's assume that in

$err = $ffi->new("Error*");
$ffi->func(FFI::addr($err));

func() sets that argument to NULL, then

$f = $err[0];
var_dump(gettype($f));

returns "object" - so the zeroth index exists (hence the isset being true).

However there's also
$f = $err->{0};

which normally would throw "Attempt to read undefined field '0' of C
struct/union" but because $err is seen as an array, accessing a property
named 0 is possible, but then a second null check will happen via
https://github.com/php/php-src/blob/09e9c4f3c11a875c67334578621084f156155307/ext/ffi/ffi.c#L1103-L1107
and
you get "NULL pointer dereference" instead.

I believe this difference between [0] and {0} shouldn't exist.

And even aside of that, I see no way in which user-code can ever check any
reference for NULL because any access of a Cdata property or index that's
happen to be set to NULL will either segfault, throw or fail a comparison
in PHP because Cdata instances, according to PHP's type conversion rules,
always convert to something that compares truthy when put in boolean
context.

The inconsistency between [] and {} aside, I believe there should be an
FFI::isNull() static method or a Cdata::isNull() instance method that allow
user-code to check things for being NULL. Or the throw in the code I liked
to above is removed, but that would leave the inconsistency between [] and
{}

Or maybe I'm just overlooking something and there's a simple way to check
something for being NULL, but if there is, it IMHO needs better docs.

Philip

Re: [PHP-DEV] FFI extension / NULL-Checks

[Stanislav Malyshev]

Hi!

> isset($err)
> $err[0] != null
> -> is always true, regardless of whether func as assigned an error or not
> 
> $err[0];
> -> segfault

This is a bit confusing - if $err[0] segfaults, how it can be != null?
Does this behave differently in different contexts? Anyway, it shouldn't
probably segfault in any case, so this looks like a bug.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: non-PIC build broken on oss-fuzz

[Stanislav Malyshev]

Hi!

>> I added --with-pic, it didn't change anything, same error.
> 
> See .

I am sorry, I don't understand how that comment helps. Could you explain
a bit further, what needs to be done to make the build work again?
configure --with-pic does not help to solve the problem.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: non-PIC build broken on oss-fuzz

[Stanislav Malyshev]

Hi!

On 9/9/19 12:57 AM, Dmitry Stogov wrote:
> how do you add "-pie" flag?

I do not. I just compile PHP. The script used to configure and build it
is here:
https://github.com/google/oss-fuzz/blob/master/projects/php/build.sh
There are no special flags there as far as I can see. The fuzzing SAPI
lives here: https://github.com/php/php-fuzzing-sapi
The compiler used is clang. You can reproduce the build by using Docker
and these instructions:
https://google.github.io/oss-fuzz/getting-started/new-project-guide/#testing-locally

Specifically:
python infra/helper.py build_image php
python infra/helper.py build_fuzzers --sanitizer address php
or, if you want to see the details, instead of second command, use:
python infra/helper.py shell php
and then:
compile

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: non-PIC build broken on oss-fuzz

[Christoph M. Becker]

On 09.09.2019 at 09:29, Stanislav Malyshev wrote:

>> I suspect the problem caused by "-pie" linker flag (It requires all
>> object files to be build with -fPIE or -fPIC).
>> To quick fix this, you may add PHP configure flag "--with-pic".
>> Actually, this should build PHP as before the patch.
>
> I added --with-pic, it didn't change anything, same error.

See .

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: non-PIC build broken on oss-fuzz

[Stanislav Malyshev]

Hi!

> I suspect the problem caused by "-pie" linker flag (It requires all
> object files to be build with -fPIE or -fPIC).
> To quick fix this, you may add PHP configure flag "--with-pic".
> Actually, this should build PHP as before the patch.

I added --with-pic, it didn't change anything, same error.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] FFI extension / NULL-Checks

[Philip Hofstetter]

Hello,

(I'm writing to the internals list because I don't think that at this
point, FFI usage is wide-spread enough to get an opinion on other venues)

maybe I'm just stupid, but I think there has been a slight oversight in the
API design for the FFI interface.

My problem is with functions that return a pointer to a struct as an out
parameter.

So in C, it would look like this:

Error* err;
func();

if (err != NULL){
   do_error_handling();
}

If I translate this to PHP FFI, I would do

$err = $ffi->new("Error*");
$ffi->func(FFI::addr($err));

if I `var_dump` $err, I do see a public {0} property be set to NULL or to
actual error data.

My issue is though: How do I check whether err* as been assgined to?

isset($err)
$err[0] != null
-> is always true, regardless of whether func as assigned an error or not

isset($err->{0})
isset($err[0])
-> Cannot use object of type FFI\CData as array

$err->{0} != NULL;
-> FFI\Exception: NULL pointer dereference

$err[0];
-> segfault

I'm sure I must be doing something wrong, but I don't know what. Also, the
documentation could do with an example on how to achieve the desired result
and, TBH, I think some of the various attempts produce a somewhat
unexpected output.

Any comments?

Philip


var_dump(isset($r->{0}));
-> Error:  Cannot use object of type FFI\CData as array

$a = '{0}';
var_dump(isset($r->$a));
-> Error:  Cannot use object of type FFI\CData as array


var_dump(isset($r[0]));
var_dump($r[0]);