On Mon, Dec 03, 2018 at 09:55:36AM +, Ramana Radhakrishnan wrote:
> 2018-11-23 Ramana Radhakrishnan
>
> * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New
> * config/aarch64/aarch64.c (aarch64_override_options_internal):
> Handle
> and put in
On 03/12/2018 16:39, Ard Biesheuvel wrote:
> On Mon, 3 Dec 2018 at 10:55, Ramana Radhakrishnan
> wrote:
>>
>> For quite sometime the kernel guys, (more specifically Ard) have been
>> talking about using a system register (sp_el0) and an offset from that
>> for a canary based access. This patchset
On 10/01/2019 15:49, James Greenhalgh wrote:
> On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan wrote:
>> For quite sometime the kernel guys, (more specifically Ard) have been
>> talking about using a system register (sp_el0) and an offset from that
>> for a canary based access. This
On Thu, Jan 10, 2019 at 03:49:27PM +, James Greenhalgh wrote:
> On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan wrote:
> > For quite sometime the kernel guys, (more specifically Ard) have been
> > talking about using a system register (sp_el0) and an offset from that
> > for a
On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan wrote:
> For quite sometime the kernel guys, (more specifically Ard) have been
> talking about using a system register (sp_el0) and an offset from that
> for a canary based access. This patchset adds support for a new set of
>
On Thu, Jan 10, 2019 at 11:05 AM Jakub Jelinek wrote:
>
> On Thu, Jan 10, 2019 at 10:53:32AM +, Ramana Radhakrishnan wrote:
> > > 2018-11-23 Ramana Radhakrishnan
> > >
> > > * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New
> > > * config/aarch64/aarch64.c
On Thu, Jan 10, 2019 at 10:53:32AM +, Ramana Radhakrishnan wrote:
> > 2018-11-23 Ramana Radhakrishnan
> >
> > * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New
> > * config/aarch64/aarch64.c (aarch64_override_options_internal):
> > Handle
> > and
On Mon, Dec 3, 2018 at 9:55 AM Ramana Radhakrishnan
wrote:
>
> For quite sometime the kernel guys, (more specifically Ard) have been
> talking about using a system register (sp_el0) and an offset from that
> for a canary based access. This patchset adds support for a new set of
> command line
On Tue, Dec 4, 2018 at 12:58 PM Florian Weimer wrote:
>
> * Wilco Dijkstra:
>
> >> For userland, I would like to eventually copy the OpenBSD approach for
> >> architectures which have some form of PC-relative addressing: we can
> >> have multiple random canaries in (RELRO) .rodata in sufficiently
* Wilco Dijkstra:
>> For userland, I would like to eventually copy the OpenBSD approach for
>> architectures which have some form of PC-relative addressing: we can
>> have multiple random canaries in (RELRO) .rodata in sufficiently close
>> to the code that needs them (assuming that we have split
Hi,
Florian wrote:
> For userland, I would like to eventually copy the OpenBSD approach for
> architectures which have some form of PC-relative addressing: we can
> have multiple random canaries in (RELRO) .rodata in sufficiently close
> to the code that needs them (assuming that we have split
On Mon, 3 Dec 2018 at 10:55, Ramana Radhakrishnan
wrote:
>
> For quite sometime the kernel guys, (more specifically Ard) have been
> talking about using a system register (sp_el0) and an offset from that
> for a canary based access. This patchset adds support for a new set of
> command line
* Ramana Radhakrishnan:
> I don't intend to change the defaults in userland, we've discussed this
> for user-land in the past and as far as glibc and userland is concerned
> we stick to the options as currently existing. The system register
> option is really for the kernel to use along with
On 03/12/2018 09:59, Jakub Jelinek wrote:
> On Mon, Dec 03, 2018 at 09:55:36AM +, Ramana Radhakrishnan wrote:
>> + if (aarch64_stack_protector_guard == SSP_GLOBAL
>> + && opts->x_aarch64_stack_protector_guard_offset_str)
>> +{
>> + error ("Incompatible options
On Mon, Dec 03, 2018 at 09:55:36AM +, Ramana Radhakrishnan wrote:
> + if (aarch64_stack_protector_guard == SSP_GLOBAL
> + && opts->x_aarch64_stack_protector_guard_offset_str)
> +{
> + error ("Incompatible options -mstack-protector-guard=global and"
Diagnostic messages shouldn't
For quite sometime the kernel guys, (more specifically Ard) have been
talking about using a system register (sp_el0) and an offset from that
for a canary based access. This patchset adds support for a new set of
command line options similar to how powerpc has done this.
I don't intend to change
16 matches
Mail list logo
