> On May 2, 2019, at 4:19 PM, James Morris wrote:
>
>> On Thu, 2 May 2019, Matthew Garrett wrote:
>>
>>> On Thu, May 2, 2019 at 2:07 PM James Morris wrote:
>>> One possible direction is to (as previously mentioned) assign IDs to each
>>> callsite and be able to check this ID against a simple
On Thu, 2 May 2019, Matthew Garrett wrote:
> On Thu, May 2, 2019 at 2:07 PM James Morris wrote:
> > One possible direction is to (as previously mentioned) assign IDs to each
> > callsite and be able to check this ID against a simple policy array
> > (allow/deny). The default policy choices could
On Thu, May 2, 2019 at 2:07 PM James Morris wrote:
> One possible direction is to (as previously mentioned) assign IDs to each
> callsite and be able to check this ID against a simple policy array
> (allow/deny). The default policy choices could be reduced to 'all' or
> 'none' during kconfig, and
On Mon, 29 Apr 2019, Matthew Garrett wrote:
> Hi James,
>
> What's the best way forward with this? I'm still not entirely clear on
> how it can be implemented purely as an LSM, but if you have ideas on
> what sort of implementation you'd prefer I'm happy to work on that.
It can't be implemented
Hi James,
What's the best way forward with this? I'm still not entirely clear on
how it can be implemented purely as an LSM, but if you have ideas on
what sort of implementation you'd prefer I'm happy to work on that.
Hi,
>>> 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 or
From: David Howells
Provide a single call to allow kernel code to determine whether the system
should be locked down, thereby disallowing various accesses that might
allow the running kernel image to be changed including the loading of
modules that aren't validly signed with a key we recognise, f
7 matches
Mail list logo