On 2/8/2021 11:48 AM, Borislav Petkov wrote:
On Mon, Feb 08, 2021 at 11:23:18AM -0800, Yu, Yu-cheng wrote:
exc_general_protection() and do_trap() both call show_signal(), which
then calls printk_ratelimit().
You could've done some git archeology and could've found
abd4f7505baf ("x86: i386-
On Mon, Feb 08, 2021 at 11:23:18AM -0800, Yu, Yu-cheng wrote:
> exc_general_protection() and do_trap() both call show_signal(), which
> then calls printk_ratelimit().
You could've done some git archeology and could've found
abd4f7505baf ("x86: i386-show-unhandled-signals-v3")
which explains wh
On 2/8/2021 10:53 AM, Borislav Petkov wrote:
On Mon, Feb 08, 2021 at 10:50:07AM -0800, Yu, Yu-cheng wrote:
I have not run into the situation. Initially it was there because other
faults have it.
Which other faults?
exc_general_protection() and do_trap() both call show_signal(), which
then
On Mon, Feb 08, 2021 at 10:50:07AM -0800, Yu, Yu-cheng wrote:
> I have not run into the situation. Initially it was there because other
> faults have it.
Which other faults?
> When you asked, I went through it and put out my reasoning.
What does that mean?
> I think it still makes sense to kee
On 2/8/2021 10:20 AM, Borislav Petkov wrote:
On Fri, Feb 05, 2021 at 10:00:21AM -0800, Yu, Yu-cheng wrote:
The ratelimit here is only for #CP, and its rate is not counted together
with other types of faults. If a task gets here, it will exit. The only
condition the ratelimit will trigger is wh
On Fri, Feb 05, 2021 at 10:00:21AM -0800, Yu, Yu-cheng wrote:
> The ratelimit here is only for #CP, and its rate is not counted together
> with other types of faults. If a task gets here, it will exit. The only
> condition the ratelimit will trigger is when multiple tasks hit #CP at once,
> which
On Fri, Feb 05, 2021 at 10:00:21AM -0800, Yu, Yu-cheng wrote:
> On 2/5/2021 5:59 AM, Borislav Petkov wrote:
> > On Wed, Feb 03, 2021 at 02:55:28PM -0800, Yu-cheng Yu wrote:
> > > +DEFINE_IDTENTRY_ERRORCODE(exc_control_protection)
> > > +{
> > > + static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_
On 2/5/2021 5:59 AM, Borislav Petkov wrote:
On Wed, Feb 03, 2021 at 02:55:28PM -0800, Yu-cheng Yu wrote:
+DEFINE_IDTENTRY_ERRORCODE(exc_control_protection)
+{
+ static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
+ DEFAULT_RATELIMIT_BURST);
+
On Wed, Feb 03, 2021 at 02:55:28PM -0800, Yu-cheng Yu wrote:
> +DEFINE_IDTENTRY_ERRORCODE(exc_control_protection)
> +{
> + static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
> + DEFAULT_RATELIMIT_BURST);
> + struct task_struct *tsk;
> +
> + i
On 2/4/2021 12:09 PM, Kees Cook wrote:
On Wed, Feb 03, 2021 at 02:55:28PM -0800, Yu-cheng Yu wrote:
[...]
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 7f5aec758f0e..f5354c35df32 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -606,6 +606,66 @@ DEF
On Wed, Feb 03, 2021 at 02:55:28PM -0800, Yu-cheng Yu wrote:
> 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
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, ar
12 matches
Mail list logo
