Re: [PATCH 2/4] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification

Hi Varad, Thanks for your review! On Thu, Apr 15, 2021 at 02:08:32PM +0200, Varad Gautam wrote: > Hi Joey, > > On 4/9/21 4:46 AM, Lee, Chun-Yi wrote: > > This patch adds the logic for checking the CodeSigning extended > > key usage when verifying signature of kernel module or > > kexec PE binary

Re: [PATCH 1/4] X.509: Add CodeSigning extended key usage parsing

Hi Varad, Thanks for your review! On Tue, Apr 13, 2021 at 04:28:11PM +0200, Varad Gautam wrote: > Hi, > > On 3/9/21 10:10 AM, Lee, Chun-Yi wrote: > > This patch adds the logic for parsing the CodeSign extended key usage > > extension in X.509. The parsing result will be set to the eku flag > >

Re: [PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU

Hi Randy, On Mon, Feb 22, 2021 at 08:48:42AM -0800, Randy Dunlap wrote: > Hi, > > On 2/21/21 10:42 PM, Lee, Chun-Yi wrote: > > Add an openssl command option example for generating CodeSign extended > > key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. > > > > Signed-off-by: "Lee, Chu

Re: [PATCH 1/4] X.509: Add CodeSigning extended key usage parsing

On Thu, Jan 21, 2021 at 04:32:26PM +0200, Jarkko Sakkinen wrote: > On Thu, Jan 21, 2021 at 12:23:53PM +0800, joeyli wrote: > > Hi Jarkko, > > > > On Thu, Jan 21, 2021 at 01:40:48AM +0200, Jarkko Sakkinen wrote: > > > On Wed, Jan 20, 2021 at 05:05:14PM +0800, Lee, Chu

Re: [PATCH 1/4] X.509: Add CodeSigning extended key usage parsing

Hi Jarkko, On Thu, Jan 21, 2021 at 01:40:48AM +0200, Jarkko Sakkinen wrote: > On Wed, Jan 20, 2021 at 05:05:14PM +0800, Lee, Chun-Yi wrote: > > This patch adds the logic for parsing the CodeSign extended key usage > > extension in X.509. The parsing result will be set to the eku flag > > which is

Re: [PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU

Hi Randy, Thanks for your review! I will update it in next version. Joey Lee On Wed, Nov 25, 2020 at 09:25:51AM -0800, Randy Dunlap wrote: > Hi-- > > On 11/24/20 11:26 PM, Lee, Chun-Yi wrote: > > Add an openssl command option example for generating CodeSign extended > > key usage in X.509 when

Re: [RFC PATCH 2/2] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification

Hi Randy, On Tue, Oct 20, 2020 at 07:56:29AM -0700, Randy Dunlap wrote: > On 10/20/20 6:42 AM, Ben Boeckel wrote: > > On Tue, Oct 20, 2020 at 14:50:01 +0800, Lee, Chun-Yi wrote: > >> +config CHECK_CODESIGN_EKU > >> + bool "Check codeSigning extended key usage" > >> + depends on PKCS7_MESSAGE_PAR

Re: [RFC PATCH 2/2] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification

Hi Ben, On Tue, Oct 20, 2020 at 09:42:08AM -0400, Ben Boeckel wrote: > On Tue, Oct 20, 2020 at 14:50:01 +0800, Lee, Chun-Yi wrote: > > +config CHECK_CODESIGN_EKU > > + bool "Check codeSigning extended key usage" > > + depends on PKCS7_MESSAGE_PARSER=y > > + depends on SYSTEM_DATA_VERIFICATIO

Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction

Hi Ard, On Thu, Sep 24, 2020 at 12:47:46PM +0200, Ard Biesheuvel wrote: > On Thu, 24 Sep 2020 at 10:28, Lee, Chun-Yi wrote: > > > > This patch moved the logic of creating efivars mount point to the > > registration of efivars abstraction. It's useful for userland to > > determine the availability

Re: [PATCH] efi/efivars: Create efivars mount point in the registration of efivars abstraction

Hi Greg, On Thu, Sep 24, 2020 at 11:51:57AM +0200, Greg Kroah-Hartman wrote: > On Thu, Sep 24, 2020 at 04:28:33PM +0800, Lee, Chun-Yi wrote: > > This patch moved the logic of creating efivars mount point to the > > registration of efivars abstraction. It's useful for userland to > > determine the

Re: [PATCH] platform/x86: acer-wmi: add automatic keyboard background light toggle key as KEY_LIGHTS_TOGGLE

Hi Timo, On Tue, Aug 04, 2020 at 02:14:23AM +0200, Timo Witte wrote: > Got a dmesg message on my AMD Renoir based Acer laptop: > "acer_wmi: Unknown key number - 0x84" when toggling keyboard > background light > > Signed-off-by: Timo Witte Reviewed-by: "Lee, Chun-Yi" Thanks for your help! Joey

Re: [PATCH v2] efi/efivars: Create efivars mount point via efivars abstraction

On Wed, Aug 26, 2020 at 11:56:33PM +0800, Joey Lee wrote: > Hi Ard, > > On Wed, Aug 26, 2020 at 02:08:18PM +0200, Ard Biesheuvel wrote: > > On Wed, 26 Aug 2020 at 02:46, Lee, Chun-Yi wrote: > > > > > > This patch creates efivars mount point when active efivars abstraction > > > be set. It is usef

Re: [PATCH v2] efi/efivars: Create efivars mount point via efivars abstraction

Hi Ard, On Wed, Aug 26, 2020 at 02:08:18PM +0200, Ard Biesheuvel wrote: > On Wed, 26 Aug 2020 at 02:46, Lee, Chun-Yi wrote: > > > > This patch creates efivars mount point when active efivars abstraction > > be set. It is useful for userland to determine the availability of efivars > > filesystem.

Re: [PATCH] efi/efivars: create efivars mount point when get variable services are available

Hi Ard, On Thu, Aug 20, 2020 at 11:30:27AM +0200, Ard Biesheuvel wrote: > On Wed, 19 Aug 2020 at 11:28, Lee, Chun-Yi wrote: > > > > The efivars filesystem depends on GetVariable or GetNextVariable EFI > > runtime services. So the /sys/firmware/efi/efivars does not need to be > > created when GetV

Re: [PATCH V34 10/29] hibernate: Disable when the kernel is locked down

Hi experts, On Mon, Jun 24, 2019 at 03:21:23PM +0200, Jiri Kosina wrote: > On Sat, 22 Jun 2019, Pavel Machek wrote: > > > > There is currently no way to verify the resume image when returning > > > from hibernate. This might compromise the signed modules trust model, > > > so until we can work w

Re: [PATCH 2/2 v3] efi: print appropriate status message when loading certificates

On Fri, May 03, 2019 at 04:23:51PM +0200, Ard Biesheuvel wrote: > On Fri, 3 May 2019 at 10:59, joeyli wrote: > > > > On Fri, May 03, 2019 at 10:07:59AM +0200, Ard Biesheuvel wrote: > > > On Fri, 3 May 2019 at 09:18, joeyli wrote: > > > > > > > > Hi

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

On Wed, Jan 09, 2019 at 05:47:53PM +0100, Stephan Mueller wrote: > Am Mittwoch, 9. Januar 2019, 17:39:58 CET schrieb joeyli: > > Hi joeyli, > > > > > I am doing encrypt-then-MAC. > > Note, this is what the authenc() AEAD cipher does. > OK.. Thanks for your re

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

On Thu, Jan 10, 2019 at 05:09:46PM -0800, Andy Lutomirski wrote: > On Thu, Jan 10, 2019 at 7:13 AM joeyli wrote: > > > > On Wed, Jan 09, 2019 at 10:47:42AM -0800, Andy Lutomirski wrote: > > > On Wed, Jan 9, 2019 at 8:40 AM joeyli wrote: > > > > > > &g

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

On Wed, Jan 09, 2019 at 10:47:42AM -0800, Andy Lutomirski wrote: > On Wed, Jan 9, 2019 at 8:40 AM joeyli wrote: > > > > Hi Andy, > > > > Thanks for your review! > > > > On Tue, Jan 08, 2019 at 01:41:48PM -0800, Andy Lutomirski wrote: > >

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Hi James On Tue, Jan 08, 2019 at 10:49:39PM -0800, James Bottomley wrote: > On Tue, 2019-01-08 at 17:43 -0800, Andy Lutomirski wrote: > > [Adding Jarkko because this stuff relates to the TPM.] > > > > On Tue, Jan 8, 2019 at 4:44 PM James Bottomley > > wrote: > > > > > > On Tue, 2019-01-08 at 15

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

On Thu, Jan 10, 2019 at 12:39:58AM +0800, joeyli wrote: > Hi Andy, > [...snip] > > Let's why I encrypt/decrypt data pages one by one, then I copy the ^^^ That's why > encrypt/decrypt data from buffer page (only one buffer page reserved > for encrypt/decrypt)

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

Hi Andy, Thanks for your review! On Tue, Jan 08, 2019 at 01:41:48PM -0800, Andy Lutomirski wrote: > > On Jan 7, 2019, at 9:37 AM, joeyli wrote: > > > > Hi Pavel, > > > > Thanks for your review! > > > >> On Sun, Jan 06, 2019 at 07:10:27PM +0100,

Re: [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image

Hi Pavel, Thanks for your review! On Sun, Jan 06, 2019 at 07:10:27PM +0100, Pavel Machek wrote: > Hi! > > > This patchset is the implementation of encryption and authentication > > for hibernate snapshot image. The image will be encrypted by AES and > > authenticated by HMAC. > > Ok, so you en

Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler

Hi Stephan, First, thanks for your review! On Sun, Jan 06, 2019 at 09:01:27AM +0100, Stephan Mueller wrote: > Am Donnerstag, 3. Januar 2019, 15:32:23 CET schrieb Lee, Chun-Yi: > > Hi Chun, > > > This patch adds a snapshot keys handler for using the key retention > > service api to create keys

Re: [PATCH 0/2] [RFC] sysfs: Add hook for checking the file capability of opener

Hi Greg, Thanks for your review! On Sun, Dec 30, 2018 at 03:45:06PM +0100, Greg Kroah-Hartman wrote: > On Sun, Dec 30, 2018 at 09:28:54PM +0800, Lee, Chun-Yi wrote: > > There have some discussion in the following mail loop about checking > > capability in sysfs write handler: > > https://lkm

Re: [PATCH 2/2] PM / Sleep: Check the file capability when writing wake lock interface

Hi Greg, On Sun, Dec 30, 2018 at 03:48:35PM +0100, Greg Kroah-Hartman wrote: > On Sun, Dec 30, 2018 at 09:28:56PM +0800, Lee, Chun-Yi wrote: > > The wake lock/unlock sysfs interfaces check that the writer must has > > CAP_BLOCK_SUSPEND capability. But the checking logic can be bypassed > > by open

Re: [PATCH][RFC v2] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

Hi Yu Chen, Thanks for your response! On Tue, Dec 11, 2018 at 11:12:21AM +0800, Yu Chen wrote: > Hi Joey, > On Mon, Dec 10, 2018 at 02:31:53PM +0800, joeyli wrote: > > Hi Chen Yu and ACPI experts, > > > > On Sat, May 05, 2018 at 07:53:22PM +0800, Chen Yu wrote: &g

Re: [PATCH][RFC v2] ACPI: acpi_pad: Do not launch acpi_pad threads on idle cpus

Hi Chen Yu and ACPI experts, On Sat, May 05, 2018 at 07:53:22PM +0800, Chen Yu wrote: > According to current implementation of acpi_pad driver, > it does not make sense to spawn any power saving threads > on the cpus which are already idle - it might bring > unnecessary overhead on these idle cpus

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

Hi Any, Jann, On Wed, Oct 03, 2018 at 03:08:12PM -0700, Andy Lutomirski wrote: > On Tue, Oct 2, 2018 at 12:36 PM Jann Horn wrote: > > > > +Andy for opinions on things in write handlers > > +Mimi Zohar as EVM maintainer > > > > On Tue, Oct 2, 2018 at 9:55 AM jo

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

Hi Jann, Thanks for your review and very sorry for my delay! On Thu, Sep 13, 2018 at 04:31:18PM +0200, Jann Horn wrote: > +cc keyrings list > > On Thu, Sep 13, 2018 at 4:08 PM Lee, Chun-Yi wrote: > > This patch adds a snapshot keys handler for using the key retention > > service api to create k

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

Hi Yu Chen, Thanks for your review and very sorry for my delay! On Thu, Sep 13, 2018 at 09:58:32PM +0800, Yu Chen wrote: > On Wed, Sep 12, 2018 at 10:23:33PM +0800, Lee, Chun-Yi wrote: > > This patch adds a snapshot keys handler for using the key retention > > service api to create keys for snap

Re: [PATCH 1/5] PM / hibernate: Create snapshot keys handler

Hi Randy, On Wed, Sep 12, 2018 at 09:27:27AM -0700, Randy Dunlap wrote: > Hi, > > On 9/12/18 7:23 AM, Lee, Chun-Yi wrote: > > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig > > index 3a6c2f87699e..7c5c30149dbc 100644 > > --- a/kernel/power/Kconfig > > +++ b/kernel/power/Kconfig > > @@ -

Re: [PATCH 5/5] PM / hibernate: An option to request that snapshot image must be authenticated

Hi Randy, On Wed, Sep 12, 2018 at 09:24:38AM -0700, Randy Dunlap wrote: > Hi, > > On 9/12/18 7:23 AM, Lee, Chun-Yi wrote: > > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig > > index 7c5c30149dbc..3c998fd6dc4c 100644 > > --- a/kernel/power/Kconfig > > +++ b/kernel/power/Kconfig > > @@

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

On Fri, Aug 10, 2018 at 08:58:37AM -0500, Bjorn Helgaas wrote: > On Fri, Aug 10, 2018 at 05:25:01PM +0800, joeyli wrote: > > On Wed, Aug 08, 2018 at 04:23:22PM -0500, Bjorn Helgaas wrote: > > ... [...snip] > > hm... I have another question that it may not relates to this iss

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

On Wed, Aug 08, 2018 at 04:23:22PM -0500, Bjorn Helgaas wrote: > On Wed, Aug 08, 2018 at 11:53:18PM +0800, joeyli wrote: > > Hi Bjorn, > > > > First, thanks for your review! > > > > On Mon, Aug 06, 2018 at 04:48:07PM -0500, Bjorn Helgaas wrote: > > > On

Re: [PATCH v2] platform/x86: acer-wmi: refactor function has_cap

Hi Gustavo, Sorry for my delay! On Mon, Aug 06, 2018 at 03:38:32PM -0500, Gustavo A. R. Silva wrote: > Refactor function has_cap in order to avoid returning integer > values, when instead it should return booleans. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gust

Re: [PATCH] x86/PCI: Claim the resources of firmware enabled IOAPIC before children bus

Hi Bjorn, First, thanks for your review! On Mon, Aug 06, 2018 at 04:48:07PM -0500, Bjorn Helgaas wrote: > On Tue, Jul 24, 2018 at 07:01:44PM +0800, Lee, Chun-Yi wrote: > > I got a machine that the resource of firmware enabled IOAPIC conflicts > > with the resource of a children bus when the PCI h

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

On Fri, Jul 13, 2018 at 03:34:25PM +0800, Yu Chen wrote: > Hi, > On Thu, Jul 12, 2018 at 06:10:37PM +0800, joeyli wrote: > > Hi Yu Chen, > > > > Sorry for my delay... > > > > On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote: [...snip] > > >

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

Hi Yu Chen, Sorry for my delay... On Fri, Jul 06, 2018 at 11:28:56PM +0800, Yu Chen wrote: > Hi Joey Lee, > On Fri, Jun 29, 2018 at 08:59:43PM +0800, joeyli wrote: > > On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote: > > > Hi, > > > On Thu, Jun 28, 2018 at

Re: [PATCH 0/3][RFC] Introduce the in-kernel hibernation encryption

Hi Chen Yu, On Wed, Jun 20, 2018 at 05:39:37PM +0800, Chen Yu wrote: > Hi, > As security becomes more and more important, we add the in-kernel > encryption support for hibernation. > > This prototype is a trial version to implement the hibernation > encryption in the kernel, so that the users do

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

On Thu, Jun 28, 2018 at 10:52:07PM +0800, Yu Chen wrote: > Hi, > On Thu, Jun 28, 2018 at 10:28:56PM +0800, joeyli wrote: > > On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote: > > > Hi, > > > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote: > > >

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

On Thu, Jun 28, 2018 at 09:50:17PM +0800, Yu Chen wrote: > Hi, > On Thu, Jun 28, 2018 at 09:07:20PM +0800, joeyli wrote: > > Hi Chen Yu, > > > > On Wed, Jun 20, 2018 at 05:40:32PM +0800, Chen Yu wrote: > > > Use the helper functions introduced previously to encryp

Re: [PATCH 2/3][RFC] PM / Hibernate: Encrypt the snapshot pages before submitted to the block device

en encrypted, and vice versa > for the resume process. > I want to suggest my solution that it direct signs/encrypts the memory snapshot image. This solution is already shipped with SLE12 a couple of years: https://github.com/joeyli/linux-s4sign/commits/s4sign-hmac-encrypted-key-v0.2-v4

Re: [PATCH 07/24] hibernate: Disable when the kernel is locked down

nation encryption and authentication: https://github.com/joeyli/linux-s4sign/wiki My plan is: - Hibernation encryption: There is a draft patch to encrypt image by ctr(aes). This patch works with the first version of hibernation verification: https://github.com/joeyli/linux-s4sign/

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

Hi Ard, On Thu, May 03, 2018 at 02:05:51PM +0200, Ard Biesheuvel wrote: > On 2 May 2018 at 08:17, Lee, Chun-Yi wrote: > > When using kdump, SOMETIMES the "size not consistent" warning message > > shows up when the crash kernel boots with early_ioremap_debug parameter: > > > > WARNING: CPU: 0 PID:

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

On Mon, Apr 16, 2018 at 06:35:22PM -0600, Randy Wright wrote: > On Mon, Apr 16, 2018 at 02:37:38PM +0800, joeyli wrote: > > Hi Randy, > > ... > > Randy, do you want to try Dave's kexec patch on your environment? Please > > remove > > my patch first. >

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

Hi Randy, On Mon, Apr 16, 2018 at 11:09:04AM +0800, Dave Young wrote: > On 04/16/18 at 10:57am, Dave Young wrote: > > On 04/13/18 at 02:27pm, Lee, Chun-Yi wrote: > > > When using kdump, SOMETIMES the "size not consistent" warning message > > > shows up when the crash kernel boots with early_iorema

Re: [PATCH] efi: Fix the size not consistent issue when unmapping memory map

On Mon, Apr 16, 2018 at 10:57:34AM +0800, Dave Young wrote: > On 04/13/18 at 02:27pm, Lee, Chun-Yi wrote: > > When using kdump, SOMETIMES the "size not consistent" warning message > > shows up when the crash kernel boots with early_ioremap_debug parameter: > > > > WARNING: CPU: 0 PID: 0 at ../mm/e

Re: [GIT PULL] Kernel lockdown for secure boot

On Sun, Apr 08, 2018 at 08:40:10PM -0700, Alexei Starovoitov wrote: > On Sun, Apr 08, 2018 at 04:07:42PM +0800, joeyli wrote: > > > > > If the only thing that folks are paranoid about is reading > > > arbitrary kernel memory with bpf_probe_read() helper > > &

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 03, 2018 at 07:34:25PM -0700, Alexei Starovoitov wrote: > On Tue, Apr 3, 2018 at 9:26 AM, Andy Lutomirski wrote: > > On Tue, Apr 3, 2018 at 8:41 AM, Alexei Starovoitov > > wrote: > >> On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote: > >>> > > >>> >> "bpf: Restrict kern

Re: [GIT PULL] Kernel lockdown for secure boot

s KMK and EVM. There have another idea is using a tree to register all sensitive data then blanking them when reading. Here is a very early developing version: https://github.com/joeyli/linux-sensitive_data/commits/sensitive-data-tree-v0.1-v4.15 But this approach causes runtime overhead and a

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

Hi David, On Wed, Apr 04, 2018 at 05:17:24PM +0100, David Howells wrote: > Andy Lutomirski wrote: > > > Since this thread has devolved horribly, I'm going to propose a solution. > > > > 1. Split the "lockdown" state into three levels: (please don't > > bikeshed about the names right now.) > >

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

On Wed, Apr 04, 2018 at 11:19:27PM +0100, David Howells wrote: > Jann Horn wrote: > > > > Uh, no. bpf, for example, can be used to modify kernel memory. > > > > I'm pretty sure bpf isn't supposed to be able to modify arbitrary > > kernel memory. AFAIU if you can use BPF to write to arbitrary ke

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

Hi Andy, On Wed, Apr 04, 2018 at 07:49:12AM -0700, Andy Lutomirski wrote: > Since this thread has devolved horribly, I'm going to propose a solution. ... > 6. There's a way to *decrease* the lockdown level below the configured > value. (This ability itself may be gated by a config option.) > Choi

Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load

Hi Mimi, On Mon, Mar 19, 2018 at 10:12:03AM -0400, Mimi Zohar wrote: > On Sun, 2018-03-11 at 11:20 +0800, joeyli wrote: > > On Wed, Mar 07, 2018 at 07:28:37AM -0800, James Bottomley wrote: > > > On Wed, 2018-03-07 at 08:18 -0500, Mimi Zohar wrote: > > > > On Tue, 2

Re: [PATCH] ACPI / scan: Send the change uevent with offine environmental data

Hi Rafael, On Mon, Mar 19, 2018 at 11:02:32AM +0100, Rafael J. Wysocki wrote: > On Friday, March 2, 2018 7:35:08 AM CET Lee, Chun-Yi wrote: > > In current design of ACPI container offline, Kernel emits > > KOBJ_CHANGE uevent to user space to indidate that the ejection of > > the container was tri

Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

On Thu, Mar 15, 2018 at 07:30:26AM -0700, James Bottomley wrote: > On Thu, 2018-03-15 at 14:16 +0800, joeyli wrote: > > On Wed, Mar 14, 2018 at 07:19:25AM -0700, James Bottomley wrote: > > > > > > On Wed, 2018-03-14 at 14:08 +0800, joeyli wrote: > > > > >

Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

On Wed, Mar 14, 2018 at 07:19:25AM -0700, James Bottomley wrote: > On Wed, 2018-03-14 at 14:08 +0800, joeyli wrote: > > On Tue, Mar 13, 2018 at 10:18:35AM -0700, James Bottomley wrote: > > > > > > On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote: > > >

Re: [PATCH 1/5] MODSIGN: do not load mok when secure boot disabled

Hi Ard, First! Thanks for your review! On Tue, Mar 13, 2018 at 05:25:30PM +, Ard Biesheuvel wrote: > On 13 March 2018 at 10:37, Lee, Chun-Yi wrote: > > The mok can not be trusted when the secure boot is disabled. Which > > means that the kernel embedded certificate is the only trusted key.

Re: [PATCH 4/5] MODSIGN: checking the blacklisted hash before loading a kernel module

On Tue, Mar 13, 2018 at 10:18:35AM -0700, James Bottomley wrote: > On Tue, 2018-03-13 at 18:38 +0800, Lee, Chun-Yi wrote: > > This patch adds the logic for checking the kernel module's hash > > base on blacklist. The hash must be generated by sha256 and enrolled > > to dbx/mokx. > > > > For exampl

Re: [PATCH 2/5] MODSIGN: print appropriate status message when getting UEFI certificates list

Hi James, Thanks for your review. On Tue, Mar 13, 2018 at 10:17:50AM -0700, James Bottomley wrote: > On Tue, 2018-03-13 at 18:35 +0800, Lee, Chun-Yi wrote: > > When getting certificates list from UEFI variable, the original error > > message shows the state number from UEFI firmware. It's hard to

Re: [PATCH 0/9] KEYS: Blacklisting & UEFI database load

On Wed, Mar 07, 2018 at 07:28:37AM -0800, James Bottomley wrote: > On Wed, 2018-03-07 at 08:18 -0500, Mimi Zohar wrote: > > On Tue, 2018-03-06 at 15:05 +0100, Jiri Slaby wrote: > > > what's the status of this please? Distributors (I checked SUSE, > > > RedHat and Ubuntu) have to carry these patches

Re: [PATCH] ACPI / scan: Send the change uevent with offine environmental data

On Fri, Mar 02, 2018 at 03:00:59PM +0100, Michal Hocko wrote: > On Fri 02-03-18 14:35:08, Lee, Chun-Yi wrote: > > In current design of ACPI container offline, Kernel emits > > KOBJ_CHANGE uevent to user space to indidate that the ejection of > > the container was triggered by platform. (caa73ea15 p

Re: [PATCH 1/4] MODSIGN: do not load mok when secure boot disabled

Hi James, First, thank you for reviewing and comment! On Thu, Nov 30, 2017 at 07:51:03AM -0800, James Bottomley wrote: > On Wed, 2017-11-29 at 22:11 +0800, Lee, Chun-Yi wrote: > > The mok can not be trusted when the secure boot is disabled. Which > > means that the kernel embedded certificate is

Re: [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove

On Wed, Nov 29, 2017 at 08:49:13AM +0800, joeyli wrote: > Hi Andrea, > > On Fri, Nov 24, 2017 at 10:22:35AM +, Andrea Reale wrote: > > Resending the patch adding linux-acpi in CC, as suggested by Rafael. > > Everyone else: apologies for the noise. > > >

Re: [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove

On Fri, Nov 24, 2017 at 07:17:41PM +0100, Michal Hocko wrote: > On Fri 24-11-17 15:54:59, Andrea Reale wrote: > > On Fri 24 Nov 2017, 16:43, Michal Hocko wrote: > > > On Fri 24-11-17 14:49:17, Andrea Reale wrote: > > > > Hi Rafael, > > > > > > > > On Fri 24 Nov 2017, 15:39, Rafael J. Wysocki wrote

Re: [PATCH v2 2/5] mm: memory_hotplug: Remove assumption on memory state before hotremove

Hi Andrea, On Fri, Nov 24, 2017 at 10:22:35AM +, Andrea Reale wrote: > Resending the patch adding linux-acpi in CC, as suggested by Rafael. > Everyone else: apologies for the noise. > > Commit 242831eb15a0 ("Memory hotplug / ACPI: Simplify memory removal") > introduced an assumption whereas

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

On Fri, Oct 27, 2017 at 03:32:26PM -0400, Mimi Zohar wrote: > On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote: > > On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote: > > > Hi Mimi, > > > > > > Thank you for reviewing. > > > > > > On M

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

Hi Mimi, Thank you for reviewing. On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote: > On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote: > > From: Chun-Yi Lee > > > > When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image > > through kexec_file systemcall if securele

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

Hi David, On Mon, Oct 23, 2017 at 03:49:44PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a whitelist can be built over time ? >

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

On Mon, Oct 23, 2017 at 03:53:00PM +0100, David Howells wrote: > j...@suse.com wrote: > > > hm... patch 4 only prevents write_mem() but not read_mem(). > > Or I missed anything? > > Actually, yes, as it happens, patch 11 prevents you from even opening /dev/mem > and /dev/kmem by locking down open

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

On Fri, Oct 20, 2017 at 09:48:16PM +0100, David Howells wrote: > Alan Cox wrote: > > > There are a load of standard tools that use this so I think you are going > > to need a whitelist. Can you at least log *which* MSR in the failing case > > so a whitelist can be built over time ? > [...snip] >

Re: [PATCH 17/27] acpi: Disable APEI error injection if the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:41PM +0100, David Howells wrote: > From: Linn Crosetto > > ACPI provides an error injection mechanism, EINJ, for debugging and testing > the ACPI Platform Error Interface (APEI) and other RAS features. If > supported by the firmware, ACPI specification 5.0 and later

Re: [PATCH 16/27] acpi: Disable ACPI table override if the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:34PM +0100, David Howells wrote: > From: Linn Crosetto > > >From the kernel documentation (initrd_table_override.txt): > > If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible > to override nearly any ACPI table provided by the BIOS with an >

Re: [PATCH 15/27] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

On Thu, Oct 19, 2017 at 03:52:27PM +0100, David Howells wrote: > From: Josh Boyer > > This option allows userspace to pass the RSDP address to the kernel, which > makes it possible for a user to modify the workings of hardware . Reject > the option when the kernel is locked down. > > Signed-off

Re: [PATCH 14/27] ACPI: Limit access to custom_method when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:19PM +0100, David Howells wrote: > From: Matthew Garrett > > custom_method effectively allows arbitrary access to system memory, making > it possible for an attacker to circumvent restrictions on module loading. > Disable it if the kernel is locked down. > > Signed-

Re: [PATCH 13/27] asus-wmi: Restrict debugfs interface when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:11PM +0100, David Howells wrote: > From: Matthew Garrett > > We have no way of validating what all of the Asus WMI methods do on a given > machine - and there's a risk that some will allow hardware state to be > manipulated in such a way that arbitrary code can be ex

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

On Thu, Oct 19, 2017 at 03:52:04PM +0100, David Howells wrote: > From: Matthew Garrett > > Writing to MSRs should not be allowed if the kernel is locked down, since > it could lead to execution of arbitrary code in kernel mode. Based on a > patch by Kees Cook. > > Signed-off-by: Matthew Garrett

Re: [PATCH 11/27] x86: Lock down IO port access when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:56PM +0100, David Howells wrote: > From: Matthew Garrett > > IO port access would permit users to gain access to PCI configuration > registers, which in turn (on a lot of hardware) give access to MMIO > register space. This would potentially permit root to trigger ar

Re: [PATCH 10/27] PCI: Lock down BAR access when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:49PM +0100, David Howells wrote: > From: Matthew Garrett > > Any hardware that can potentially generate DMA has to be locked down in > order to avoid it being possible for an attacker to modify kernel code, > allowing them to circumvent disabled module loading or mod

Re: [PATCH 09/27] uswsusp: Disable when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:42PM +0100, David Howells wrote: > From: Matthew Garrett > > uswsusp allows a user process to dump and then restore kernel state, which > makes it possible to modify the running kernel. Disable this if the kernel > is locked down. > > Signed-off-by: Matthew Garrett

Re: [PATCH 08/27] hibernate: Disable when the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:34PM +0100, David Howells wrote: > From: Josh Boyer > > There is currently no way to verify the resume image when returning > from hibernate. This might compromise the signed modules trust model, > so until we can work with signed hibernate images we disable it when

Re: [PATCH 06/27] Copy secure_boot flag in boot params across kexec reboot

On Thu, Oct 19, 2017 at 03:51:20PM +0100, David Howells wrote: > From: Dave Young > > Kexec reboot in case secure boot being enabled does not keep the secure > boot mode in new kernel, so later one can load unsigned kernel via legacy > kexec_load. In this state, the system is missing the protect

Re: [PATCH 05/27] kexec: Disable at runtime if the kernel is locked down

On Thu, Oct 19, 2017 at 03:51:09PM +0100, David Howells wrote: > From: Matthew Garrett > > kexec permits the loading and execution of arbitrary code in ring 0, which > is something that lock-down is meant to prevent. It makes sense to disable > kexec in this situation. > > This does not affect k

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

Hi David, Thanks for you send out this series. On Thu, Oct 19, 2017 at 03:51:02PM +0100, David Howells wrote: > From: Matthew Garrett > > Allowing users to write to address space makes it possible for the kernel to > be subverted, avoiding module loading restrictions. Prevent this when the > k

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

Hi David, Thanks for you send our this series. On Thu, Oct 19, 2017 at 03:50:55PM +0100, David Howells wrote: > If the kernel is locked down, require that all modules have valid > signatures that we can verify. > > Signed-off-by: David Howells I have reviewed and tested this patch. Please feel

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

Hi Alexei, Thanks for your review! On Thu, Oct 19, 2017 at 03:18:30PM -0700, Alexei Starovoitov wrote: > On Thu, Oct 19, 2017 at 03:52:49PM +0100, David Howells wrote: > > From: Chun-Yi Lee > > > > There are some bpf functions can be used to read kernel memory: > > bpf_probe_read, bpf_probe_wr

Re: Draft manpage explaining kernel lockdown

Hi David, On Thu, Oct 05, 2017 at 12:00:24PM +0100, David Howells wrote: > Hi Ard, Michael, > > Attached is a draft for a manual page (kernel_lockdown.7) that I intend to > point at from messages emitted when the kernel prohibits something because the > kernel is in 'lockdown' mode, typically tri

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

Hi, On Mon, Jul 10, 2017 at 11:24:44AM +0800, Gary Lin wrote: > A new section, secdata, in the setup header is introduced to store the > distro-specific security version which is designed to help the > bootloader to warn the user when loading a less secure or vulnerable > kernel. The secdata secti

Re: A udev rule to serve the change event of ACPI container?

On Fri, Aug 04, 2017 at 05:06:19PM +0200, Michal Hocko wrote: > On Thu 03-08-17 11:37:37, YASUAKI ISHIMATSU wrote: > > > > > > On 08/02/2017 01:49 AM, joeyli wrote: > > > Hi YASUAKI, > > > > > > On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI I

Re: A udev rule to serve the change event of ACPI container?

On Thu, Aug 03, 2017 at 11:31:53AM +0200, Michal Hocko wrote: > On Thu 03-08-17 17:22:37, Joey Lee wrote: > > On Wed, Aug 02, 2017 at 11:01:43AM +0200, Michal Hocko wrote: > > > On Mon 31-07-17 15:38:45, Joey Lee wrote: > [...] > > > > So, the behavior is: > > > > > > > > Kernel received ejection

Re: A udev rule to serve the change event of ACPI container?

On Wed, Aug 02, 2017 at 11:01:43AM +0200, Michal Hocko wrote: > On Mon 31-07-17 15:38:45, Joey Lee wrote: > > Hi Michal, > > > > Sorry for my delay... > > > > On Tue, Jul 25, 2017 at 02:48:37PM +0200, Michal Hocko wrote: > > > On Mon 24-07-17 17:29:21, Joey Lee wrote: > [...] > > > > For the succ

Re: A udev rule to serve the change event of ACPI container?

Hi YASUAKI, On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI ISHIMATSU wrote: > Hi Joey, > > On 07/23/2017 05:18 AM, joeyli wrote: [...snip] > >>> > >> > >> At least Yasuaki raised similar behavior for container in 2013. > >> It's similar

Re: A udev rule to serve the change event of ACPI container?

Hi Michal, Sorry for my delay... On Tue, Jul 25, 2017 at 02:48:37PM +0200, Michal Hocko wrote: > On Mon 24-07-17 17:29:21, Joey Lee wrote: > > On Mon, Jul 24, 2017 at 10:57:02AM +0200, Michal Hocko wrote: > > > On Wed 19-07-17 17:09:10, Joey Lee wrote: > > > > On Mon, Jul 17, 2017 at 11:05:25AM +

Re: A udev rule to serve the change event of ACPI container?

On Mon, Jul 24, 2017 at 10:57:02AM +0200, Michal Hocko wrote: > On Wed 19-07-17 17:09:10, Joey Lee wrote: > > On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote: > [...] > > > The problem I have with this expectation is that userspace will never > > > have a good atomic view of the whole

Re: A udev rule to serve the change event of ACPI container?

Hi Yasuaki, On Fri, Jul 14, 2017 at 10:44:14PM +0800, joeyli wrote: > On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > > On Thu 13-

Re: A udev rule to serve the change event of ACPI container?

On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote: > On Fri 14-07-17 22:44:14, Joey Lee wrote: > > On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > > > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > > >

Re: A udev rule to serve the change event of ACPI container?

On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > On Thu 13-07-17 14:58:06, Joey Lee wrote: > [...] > > > > If BIOS emits ejection event for a ACPI0004 container, someone

Re: A udev rule to serve the change event of ACPI container?

On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > On Thu 13-07-17 14:58:06, Joey Lee wrote: > > Hi Michal, > > > > Sorry for my delay. > > > > On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote: > > > On Mon 26-06-17 10:59:07, Michal Hocko wrote: > > > > On Mon 26-06-17 1

Re: A udev rule to serve the change event of ACPI container?

Hi Michal, Sorry for my delay. On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote: > On Mon 26-06-17 10:59:07, Michal Hocko wrote: > > On Mon 26-06-17 14:26:57, Joey Lee wrote: > > > Hi all, > > > > > > If ACPI received ejection request for a ACPI container, kernel > > > emits KOBJ_CH

  1   2   3   4   >