mirror of https://gitee.com/openkylin/linux.git
x86/hw_breakpoint: Prevent data breakpoints on cpu_entry_area
A data breakpoint near the top of an IST stack will cause unrecoverable recursion. A data breakpoint on the GDT, IDT, or TSS is terrifying. Prevent either of these from happening. Co-developed-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@suse.de> Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> Link: https://lkml.kernel.org/r/20200505134058.272448010@linutronix.de
This commit is contained in:
parent
1f1fbc70c1
commit
24ae0c91cb
|
@ -227,10 +227,35 @@ int arch_check_bp_in_kernelspace(struct arch_hw_breakpoint *hw)
|
|||
return (va >= TASK_SIZE_MAX) || ((va + len - 1) >= TASK_SIZE_MAX);
|
||||
}
|
||||
|
||||
/*
|
||||
* Checks whether the range from addr to end, inclusive, overlaps the CPU
|
||||
* entry area range.
|
||||
*/
|
||||
static inline bool within_cpu_entry_area(unsigned long addr, unsigned long end)
|
||||
{
|
||||
return end >= CPU_ENTRY_AREA_BASE &&
|
||||
addr < (CPU_ENTRY_AREA_BASE + CPU_ENTRY_AREA_TOTAL_SIZE);
|
||||
}
|
||||
|
||||
static int arch_build_bp_info(struct perf_event *bp,
|
||||
const struct perf_event_attr *attr,
|
||||
struct arch_hw_breakpoint *hw)
|
||||
{
|
||||
unsigned long bp_end;
|
||||
|
||||
bp_end = attr->bp_addr + attr->bp_len - 1;
|
||||
if (bp_end < attr->bp_addr)
|
||||
return -EINVAL;
|
||||
|
||||
/*
|
||||
* Prevent any breakpoint of any type that overlaps the
|
||||
* cpu_entry_area. This protects the IST stacks and also
|
||||
* reduces the chance that we ever find out what happens if
|
||||
* there's a data breakpoint on the GDT, IDT, or TSS.
|
||||
*/
|
||||
if (within_cpu_entry_area(attr->bp_addr, bp_end))
|
||||
return -EINVAL;
|
||||
|
||||
hw->address = attr->bp_addr;
|
||||
hw->mask = 0;
|
||||
|
||||
|
|
Loading…
Reference in New Issue