Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

> My assumption here is: > 1) there are some less important and so security-insensitive firmwares, >by which I mean that such firmwares won't be expected to be signed in >terms of vulnerability or integrity. >(I can't give you examples though.) > 2) firmware's signature will be

Re: [3/3] arm64: Add software workaround for Falkor erratum 1041

On Thu, 9 Nov 2017, Manoj Iyer wrote: James, Looks like my VM test raised a false alarm. I retested stock Artful 4.13 kernel (No erratum 1041 patches applied). James, an update on the crash (false alarm). We suspect this is a firmware crash due to a possible fw bug. Once this is

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Fri, 2017-11-10 at 02:46 +0100, Luis R. Rodriguez wrote: > On Thu, Nov 09, 2017 at 10:48:43AM +0900, AKASHI, Takahiro wrote: > > On Wed, Nov 08, 2017 at 08:46:26PM +0100, Luis R. Rodriguez wrote: > > > But perhaps I'm not understanding the issue well, let me know. > > > > My point is quite

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Thu, 2017-11-09 at 13:46 +0900, AKASHI, Takahiro wrote: > Mimi, > > On Wed, Nov 08, 2017 at 09:17:37PM -0500, Mimi Zohar wrote: > > > > IMHO that should just fail then, ie, a "locked down" kernel should not > > > > want to > > > > *pass* a firmware signature if such thing could not be done. >

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Resent with Akashi's correct email address. On Fri, Nov 10, 2017 at 5:39 PM, Bhupesh Sharma wrote: > Hi Ard, Akashi > > I have met an issue on an arm64 board using the latest master branch from > Linus. > > I think I have a dirty hack to avoid the issue, but would want more

arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Hi Ard, Akashi I have met an issue on an arm64 board using the latest master branch from Linus. I think I have a dirty hack to avoid the issue, but would want more opinions from you as it might break crashkernel dump on other arm64 machines. 1. This arm64 machine supports acpi only boot mode

Re: [PATCH 26/30] Lock down ftrace

Okay, I've dropped the ftrace lockdown patch for the moment from my git branch. David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041

Hi Shanker, On 09/11/17 15:22, Shanker Donthineni wrote: > On 11/09/2017 05:08 AM, James Morse wrote: >> On 04/11/17 21:43, Shanker Donthineni wrote: >>> On 11/03/2017 10:11 AM, Robin Murphy wrote: On 03/11/17 03:27, Shanker Donthineni wrote: > The ARM architecture defines the memory

Re: [PATCH 26/30] Lock down ftrace

On Fri, 10 Nov 2017, David Howells wrote: > That would be fine by me. I have a patch that locks down kprobes in this > series. Which AFAICS renders locking down ftrace as-is unnecessary ... > Steven says that ftrace might acquire the ability to dump registers in > the future. ... and even

Re: [PATCH 26/30] Lock down ftrace

Jiri Kosina wrote: > > The idea is to prevent cryptographic data for filesystems and other things > > from being read out of the kernel memory as well as to prevent unauthorised > > modification of kernel memory. > > Then it would make sense to actually lock down dumping of

Re: [PATCH 26/30] Lock down ftrace

On Fri, 10 Nov 2017, David Howells wrote: > > I fail to see how this fits into the secure boot security model, could you > > please explain? > > The idea is to prevent cryptographic data for filesystems and other things > from being read out of the kernel memory as well as to prevent

Re: [PATCH 26/30] Lock down ftrace

On Thu, 9 Nov 2017, David Howells wrote: > Disallow the use of ftrace when the kernel is locked down. This patch > turns off ftrace_enabled late in the kernel boot so that the selftest can > still be potentially be run. > > The sysctl that controls ftrace_enables is also disallowed when the

Re: [PATCH 26/30] Lock down ftrace

Jiri Kosina wrote: > > This prevents crypto data theft by analysis of execution patterns, and, if > > in future ftrace also logs the register contents at the time, will prevent > > data theft by that mechanism also. > > I fail to see how this fits into the secure boot security