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

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,

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

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

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

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!

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

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 > >

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

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

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

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) to origina

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

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

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: > >

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

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

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 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

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

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

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

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 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 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 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] 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:

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:

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

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

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

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 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

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

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 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 e

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 e

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 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

n 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/commi

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

n 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/commi

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: >

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

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

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

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

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

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

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 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

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

Re: [GIT PULL] Kernel lockdown for secure boot

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 all sensiti

Re: [GIT PULL] Kernel lockdown for secure boot

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 all sensiti

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

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

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

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.) >

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.) >

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 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

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

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 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 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

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

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

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

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

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

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

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

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

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

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

  1   2   3   4   5   6   7   8   >