Andrew Donnellan [off-list ref] writes:
On 4/6/19 1:05 pm, Christopher M Riedl wrote:>>> + if (!xmon_is_ro) {quoted
quoted
quoted
+ 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
ajd@linux.ibm.com IBM Australia Limited