Hi Wilco,
> On 21 Dec 2018, at 19:02, Wilco Dijkstra wrote:
>
> Remember these are just temporaries for use in the prolog and epilog -
> there is no need to save/restore the static base. Setting static chain
> to x9 and the temporaries to x10/x11 is the simplest solution. We
> can separately lo
Hi Olivier,
> I'm experimenting with the idea of adjusting the
> stack probing code using r9 today, to see if it could
> save/restore that reg if it happens to be the static chain
> as well.
>
> If that can be made to work, maybe that would be a better
> alternative than just swapping and have the
Hi Wilco,
(and thanks everyone for the interesting input on this)
> On 17 Dec 2018, at 14:55, Wilco Dijkstra wrote:
>
> The AArch64 ABI defines x18 as platform specific:
[...]
> Using x9 would make its use as an extra argument clearer.
I'm experimenting with the idea of adjusting the
stack pro
On Mon, 17 Dec 2018, Hans-Peter Nilsson wrote:
> On Mon, 17 Dec 2018, Wilco Dijkstra wrote:
> > H-P:
> > > So, changing from R18 to R11 for aarch64 seems right, as the
> > > latter is call-clobbered and the former is call-saved IIUC.
> >
> > The AArch64 ABI defines x18 as platform specific:
> > htt
On Mon, 17 Dec 2018, Wilco Dijkstra wrote:
> H-P:
> > So, changing from R18 to R11 for aarch64 seems right, as the
> > latter is call-clobbered and the former is call-saved IIUC.
>
> The AArch64 ABI defines x18 as platform specific:
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI005
Hi Hans-Peter,
> While the choice of static-chain register does not affect the
> ABI, it's the other way round: the choice of static-chain
> register matters, specifically it's call-clobberedness.
Agreed.
> It looks like the current aarch64 static-chain register R18 is
> call-saved but without s
On Wed, 12 Dec 2018, Wilco Dijkstra wrote:
> I've not seen such an alternative implementation (-fno-trampolines is
> ignored on all targets I tried), but it wouldn't affect the ABI since you can
> only take the address of a nested function when you're the parent function.
Regarding the trampoline-
Hi Martin,
> One could also argue that it creates a false sense of security
> and diverts resources from properly fixing the real problems
> i.e. the buffer overflows which lets an attacker write to the
> stack in the first place. A program without buffer overflows
> is secure even without an exec
Hi Wilco,
Am Donnerstag, den 13.12.2018, 16:33 + schrieb Wilco Dijkstra:
> Uecker, Martin wrote:
> > Am Mittwoch, den 12.12.2018, 22:04 + schrieb Wilco Dijkstra:
> > > Hi Martin,
> > >
> > > > Does a non-executable stack actually improve security?
> > >
> > > Absolutely, it's like closi
Hi Martin,
Uecker, Martin wrote:
>Am Mittwoch, den 12.12.2018, 22:04 + schrieb Wilco Dijkstra:
>> Hi Martin,
>>
>> > Does a non-executable stack actually improve security?
>>
>> Absolutely, it's like closing your front door rather than just leave it open
>> for anyone.
>
> The question is wh
On Wed, Dec 12, 2018 at 10:04:11PM +, Wilco Dijkstra wrote:
> Hi Martin,
>
> > Does a non-executable stack actually improve security?
>
> Absolutely, it's like closing your front door rather than just leave it open
> for anyone.
On many Linux systems, if you use trampolines anywhere then the
> On Dec 12, 2018, at 5:12 PM, Uecker, Martin
> wrote:
>> ...
>> I've not seen such an alternative implementation (-fno-trampolines is
>> ignored on all targets I tried),
>
> It was implemented for Ada. But here is a patch to also
> activate it for C:
>
> https://gcc.gnu.org/ml/gcc-patches/2
Hi Wilco,
Am Mittwoch, den 12.12.2018, 22:04 + schrieb Wilco Dijkstra:
> Hi Martin,
>
> > Does a non-executable stack actually improve security?
>
> Absolutely, it's like closing your front door rather than just leave it open
> for anyone.
The question is whether it is like closing the fro
Hi Martin,
> Does a non-executable stack actually improve security?
Absolutely, it's like closing your front door rather than just leave it open
for anyone.
> For the alternative implementation using (custom) function
> descriptors (-fno-trampolines) the static chain becomes
> part of the ABI or
Am Mittwoch, den 12.12.2018, 18:53 + schrieb Wilco Dijkstra:
> Hi,
>
> > > On 12 Dec 2018,@18:21, Richard Earnshaw (lists)
>
> wrote:
>
> > > However, that introduces an issue that that
> > > code is potentially used across multiple versions of gcc, with
> > > potentially different choices
Hi,
>> On 12 Dec 2018, at 18:21, Richard Earnshaw (lists)
>> wrote:
>
>> However, that introduces an issue that that
>> code is potentially used across multiple versions of gcc, with
>> potentially different choices of the static chain register. Hmm, this
>> might need some more careful though
Hi Richard,
Thanks for your feedback on this !
> On 12 Dec 2018, at 18:21, Richard Earnshaw (lists)
> wrote:
>
> libffi is a separate project; so a patch for that needs to be sent to
> the libffi maintainers.
Oh, I hadn't realized that.
> However, that introduces an issue that that
> code
On 12/12/2018 15:47, Olivier Hainque wrote:
> Hello,
>
> Ping for part of the changes last proposed here:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00761.html
>
> Submitted separately as an attempt to facilitate the review
> process.
>
> This piece is the change of static chain from r1
18 matches
Mail list logo
