Andrew Donnellan <a...@linux.ibm.com> writes: > On 4/6/19 1:05 pm, Christopher M Riedl wrote:>>> + if (!xmon_is_ro) { >>>> + xmon_is_ro = kernel_is_locked_down("Using xmon write-access", >>>> + LOCKDOWN_INTEGRITY); >>>> + if (xmon_is_ro) { >>>> + printf("xmon: Read-only due to kernel lockdown\n"); >>>> + clear_all_bpt(); >>> >>> Remind me again why we need to clear breakpoints in integrity mode? >>> >>> >>> Andrew >>> >> >> I interpreted "integrity" mode as meaning that any changes made by xmon >> should >> be reversed. This also covers the case when a user creates some breakpoint(s) >> in xmon, exits xmon, and then elevates the lockdown state. Upon hitting the >> first breakpoint and (re-)entering xmon, xmon will clear all breakpoints. >> >> Xmon can only take action in response to dynamic lockdown level changes when >> xmon is invoked in some manner - if there is a better way I am all ears :) >> > > Integrity mode merely means we are aiming to prevent modifications to > kernel memory. IMHO leaving existing breakpoints in place is fine as > long as when we hit the breakpoint xmon is in read-only mode. > > (dja/mpe might have opinions on this)
Apologies for taking so long to get back to you. I think ajd is right. I think about it like this. There are 2 transitions: - into integrity mode Here, we need to go into r/o, but do not need to clear breakpoints. You can still insert breakpoints in readonly mode, so clearing them just makes things more irritating rather than safer. - into confidentiality mode Here we need to purge breakpoints and disable xmon completely. Kind regards, Daniel > > -- > Andrew Donnellan OzLabs, ADL Canberra > a...@linux.ibm.com IBM Australia Limited