On 2/24/2021 11:42 AM, Borislav Petkov wrote:
On Wed, Feb 24, 2021 at 11:30:34AM -0800, Andy Lutomirski wrote:
On Wed, Feb 24, 2021 at 11:20 AM Borislav Petkov wrote:
On Wed, Feb 24, 2021 at 09:56:13AM -0800, Yu, Yu-cheng wrote:
No. Maybe I am doing too much. The GP fault sets si_addr to
On Wed, Feb 24, 2021 at 11:30:34AM -0800, Andy Lutomirski wrote:
> On Wed, Feb 24, 2021 at 11:20 AM Borislav Petkov wrote:
> >
> > On Wed, Feb 24, 2021 at 09:56:13AM -0800, Yu, Yu-cheng wrote:
> > > No. Maybe I am doing too much. The GP fault sets si_addr to zero, for
> > > example. So maybe
On Wed, Feb 24, 2021 at 11:20 AM Borislav Petkov wrote:
>
> On Wed, Feb 24, 2021 at 09:56:13AM -0800, Yu, Yu-cheng wrote:
> > No. Maybe I am doing too much. The GP fault sets si_addr to zero, for
> > example. So maybe do the same here?
>
> No, you're looking at this from the wrong angle. This
On Wed, Feb 24, 2021 at 09:56:13AM -0800, Yu, Yu-cheng wrote:
> No. Maybe I am doing too much. The GP fault sets si_addr to zero, for
> example. So maybe do the same here?
No, you're looking at this from the wrong angle. This is going to be
user-visible and the moment it gets upstream, it is
On 2/24/2021 8:53 AM, Borislav Petkov wrote:
On Wed, Feb 24, 2021 at 08:44:45AM -0800, Yu, Yu-cheng wrote:
+ force_sig_fault(SIGSEGV, SEGV_CPERR,
+ (void __user *)uprobe_get_trap_addr(regs));
Why is this calling an uprobes function?
I will change it to
On Wed, Feb 24, 2021 at 08:44:45AM -0800, Yu, Yu-cheng wrote:
> > > + force_sig_fault(SIGSEGV, SEGV_CPERR,
> > > + (void __user *)uprobe_get_trap_addr(regs));
> >
> > Why is this calling an uprobes function?
> >
>
> I will change it to error_get_trap_addr().
"/*
* Posix
On 2/24/2021 8:13 AM, Borislav Petkov wrote:
On Wed, Feb 17, 2021 at 02:27:10PM -0800, Yu-cheng Yu wrote:
+/*
+ * When a control protection exception occurs, send a signal to the responsible
+ * application. Currently, control protection is only enabled for user mode.
+ * This exception should
On Wed, Feb 17, 2021 at 02:27:10PM -0800, Yu-cheng Yu wrote:
> +/*
> + * When a control protection exception occurs, send a signal to the
> responsible
> + * application. Currently, control protection is only enabled for user mode.
> + * This exception should not come from kernel mode.
> + */
>
A control-protection fault is triggered when a control-flow transfer
attempt violates Shadow Stack or Indirect Branch Tracking constraints.
For example, the return address for a RET instruction differs from the copy
on the shadow stack; or an indirect JMP instruction, without the NOTRACK
prefix,
9 matches
Mail list logo
