Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image

(off-list ancestor, not in this archive)
Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image · Andrew Donnellan <hidden> · 2019-04-16
Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image · Daniel Axtens <hidden> · 2019-04-18
Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image · Matthew Garrett <hidden> · 2019-04-18
Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image · Daniel Axtens <hidden> · 2019-04-29
Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image · Daniel Axtens <hidden> · 2019-04-29
Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image · Andrew Donnellan <hidden> · 2019-04-30

From: Matthew Garrett <hidden>
Date: 2019-04-18 19:35:50
Also in: linux-api, linux-security-module, lkml

On Tue, Apr 16, 2019 at 1:40 AM Andrew Donnellan
[off-list ref] wrote:

I'm thinking about whether we should lock down the powerpc xmon debug
monitor - intuitively, I think the answer is yes if for no other reason
than Least Astonishment, when lockdown is enabled you probably don't
expect xmon to keep letting you access kernel memory.

The original patchset contained a sysrq hotkey to allow physically
present users to disable lockdown, so I'm not super concerned about
this case - I could definitely be convinced otherwise, though.

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help