linux-kernel - x86/entry vs kgdb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 May 2020 10:36:05 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     daniel.thompson@...aro.org, x86@...nel.org
Cc:     sumit.garg@...aro.org, jason.wessel@...driver.com,
        dianders@...omium.org, kgdb-bugreport@...ts.sourceforge.net,
        linux-kernel@...r.kernel.org, pmladek@...e.com,
        sergey.senozhatsky@...il.com, will@...nel.org
Subject: x86/entry vs kgdb

Hi!

Since you seem to care about kgdb, I figured you might want to fix this
before I mark it broken on x86 (we've been considering doing that for a
while).

AFAICT the whole debugreg usage of kgdb-x86_64 is completely hosed; it
doesn't respsect the normal exclusion zones as per arch_build_bp_info().

That is, breakpoints must never be in:

  - in the cpu_entry_area
  - in .entry.text
  - in .noinstr.text
  - in anything else marked NOKPROBE

by not respecting these constraints it is trivial to completely and
utterly hose the machine. The entry rework that is current underway will
explicitly not deal with #DB triggering in any of those places.