32-bit x86 Position Independent Code – It's That Bad • Hacker News Board

Re: 32-bit x86 Position Independent Code – It's That Bad

#101

Post by bandrami » Thu, Apr 16, 2015, 9:14 AM UTC

vetinari wrote: post #53

bandrami wrote: post #28

Earlier quoted context omitted.

For every package, you link statically, you as the parent package owner become responsible for all security flaws of all the packages you link statically Well, speaking as an administrator rather than a developer: a developer shouldn't be making that kind of policy decision (time of symbol resolution) to begin with barring a strong technical need (plug-in based architecture, etc.). I mean, 90% of packages don't care…

The embedded glib inside pkg-config solves the chicken-egg problem: pkg-config requires glib and glib requires pkg-config. This way, you can build pkg-config first with its embedded glib, then glib itself and then go solve your own problems, instead of butchering the build system to make them build at all.

Oh, true, and I didn't mean that as a criticism of pkg-config; they only did that because it was literally the only option. In general you should only duplicate actual code if it's the only option, was my point; pkg-config is the pattern and gnulib is the anti-pattern in that.

Re: 32-bit x86 Position Independent Code – It's That Bad

#102

Post by wtbob » Thu, Apr 16, 2015, 11:06 AM UTC

eropple wrote: post #65

wtbob wrote: post #55

Earlier quoted context omitted.

> What if you have binaries compiled from proprietary code bases… Then don't do that. Seriously, RMS, ESR and others have written a plethora of well-reasoned essays indicating why proprietary software is a poor choice.

So you're admitting that this isn't a solution and you need to change the rules of the game to make it work. Well, I'm convinced.

'Doctor, it hurts when I stab myself in the eye!'

'Well, don't stab yourself in the eye.'

Re: 32-bit x86 Position Independent Code – It's That Bad

#103

Post by q3k » Thu, Apr 23, 2015, 12:47 AM UTC

hyc_symas wrote: post #91

q3k wrote: post #39

Earlier quoted context omitted.

There is however, an important security benefit from PIC: ASLR. It's not a silver bullet, but can stop a range of vulnerabilities from being reliably exploitable usable unless an memory leak is also available. Even if you so far as control the instruction pointer as an attacker, you might just not know where to jump to in the target address space...

ASLR is a pretty hackish solution to the main problem, which is that the function call stack and parameter stack are combined. The problems that ASLR mitigates don't exist in languages like Forth, where there are two separate stacks - a call stack and a separate parameter stack.

It's foolish to think ASLR only prevents stack smashes - it also prevents unlink-style attacks via heap overflows and use-after-frees, data overflows into pointers and other segments, and many other vectors.

Yes, it is a mitigation strategy that wouldn't exist in an ideal world. But we have to do best with what we have, and security takes a very pragmatic approach at this.

Re: 32-bit x86 Position Independent Code – It's That Bad

#104

Post by q3k » Thu, Apr 23, 2015, 12:48 AM UTC

StillBored wrote: post #93

hyc_symas wrote: post #91

Earlier quoted context omitted.

ASLR is a pretty hackish solution to the main problem, which is that the function call stack and parameter stack are combined. The problems that ASLR mitigates don't exist in languages like Forth, where there are two separate stacks - a call stack and a separate parameter stack.

This is really an ABI issue, more than a language one. I'm not sure anything in C requires a combined stack. Plus, processor arches like ARM and POWER use link registers rather than a stack to store the return address. Its the ABI that then chooses to put the LR on the parameter stack. Even on x86 SP could be dedicated as a function stack and separated from BP (or pick another x86_64 register) as the parameter stack.…

ARM does store the return PC in a link register, but unless you're in a leaf function, it will still be pushed into the stack and can be overwritten by overflows.