> On 2/14/18 3:38 AM, Raphael Hertzog wrote:
[...]
> > Isn't it possible that sbrk() returns that pointer to you and you treat
> > it as being an error instead of a valid address?
The problem is in QEMU:
dualbus@ubuntu:~$ cat sbrk.c
#include
#include
int main() {
On 2/14/18 3:38 AM, Raphael Hertzog wrote:
> One thing that I saw in that document is "An interesting fact is that if
> you produce a position independent executable, the starting address
> instead changes to 0x0".
>
> Isn't it possible that sbrk() returns that pointer to you and you treat
> it
On Tue, 13 Feb 2018, Chet Ramey wrote:
> > Note that a bash binary compiled with PIE works fine for normal usage
> > with a current Linux kernel. Apparently it was causing troubles with
> > older Linux kernels, see
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483
> >
> > But with
On 2/13/18 11:23 AM, Raphael Hertzog wrote:
> Hello,
>
> On Tue, 13 Feb 2018, Chet Ramey wrote:
>>> It would be nice if bash's malloc implementation could be fixed to also
>>> work under qemu-user.
>>
>> Does sbrk(2) work in a PIE-enabled environment?
>
> Note that a bash binary compiled with
Hello,
On Tue, 13 Feb 2018, Chet Ramey wrote:
> > It would be nice if bash's malloc implementation could be fixed to also
> > work under qemu-user.
>
> Does sbrk(2) work in a PIE-enabled environment?
Note that a bash binary compiled with PIE works fine for normal usage
with a current Linux
On 2/13/18 6:41 AM, Raphael Hertzog wrote:
> Hello,
>
> in Debian we wanted to build bash with PIE enabled [1], but we discovered that
> bash was broken under qemu-user when it was compiled that way [2].
>
> It turns out that it's broken only when it uses bash's malloc
> implementation. If we
Hello,
in Debian we wanted to build bash with PIE enabled [1], but we discovered that
bash was broken under qemu-user when it was compiled that way [2].
It turns out that it's broken only when it uses bash's malloc
implementation. If we build bash with PIE and --without-bash-malloc then
we don't
