On 3/26/21 9:01 AM, Vitaly Kuznetsov wrote:
Vitaly Kuznetsov writes:
..
(this is with your v2 included). There's nothing about CPU0 for
e.g. async PF + timestamps are really interesting. Seems we have issues
to fix) I'm playing with it right now.
What if we do the following (instead of your
64.
Reported-by: Xiaoyi Chen
Tested-by: Mohamed Aboubakr
Signed-off-by: Lenny Szubowicz
---
arch/x86/kernel/kvmclock.c | 40 ++
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 1
On 3/17/21 9:30 AM, Vitaly Kuznetsov wrote:
Lenny Szubowicz writes:
Turn off host updates to the registered kvmclock memory
locations when transitioning to a hibernated kernel in
resume_target_kernel().
This is accomplished for secondary vcpus by disabling host
clock updates for that vcpu
64.
Reported-by: Xiaoyi Chen
Tested-by: Mohamed Aboubakr
Signed-off-by: Lenny Szubowicz
---
arch/x86/kernel/kvmclock.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index aa593743
On 12/14/20 3:52 PM, Hyunwook (Wooky) Baek wrote:
Hello,
We found SEV-enabled VMs crash with the latest CentOS and Rhel images in Google
Cloud (centos-8-v20201112 and rhel-8-v20201112), because the MOK var table patch
(https://lkml.org/lkml/2020/8/25/1344) is making a #GP with SEV-enabled VMs,
b
On 9/21/20 12:55 PM, Arvind Sankar wrote:
On Mon, Sep 21, 2020 at 06:27:17PM +0200, Ard Biesheuvel wrote:
On Mon, 21 Sep 2020 at 18:19, Arvind Sankar wrote:
On Fri, Sep 04, 2020 at 09:31:05PM -0400, Lenny Szubowicz wrote:
+ /*
+ * The EFI MOK config table must fit within a single
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 58c909022a5a56cd1d9e89c8c5461fd1f6a27bb5
Gitweb:
https://git.kernel.org/tip/58c909022a5a56cd1d9e89c8c5461fd1f6a27bb5
Author:Lenny Szubowicz
AuthorDate:Fri, 04 Sep 2020 21:31:05 -04:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 726bd8965a5f112d9601f7ce68effa1e46e02bf2
Gitweb:
https://git.kernel.org/tip/726bd8965a5f112d9601f7ce68effa1e46e02bf2
Author:Lenny Szubowicz
AuthorDate:Fri, 04 Sep 2020 21:31:07 -04:00
The following commit has been merged into the efi/core branch of tip:
Commit-ID: 38a1f03aa24094b4a8de846700cb6cb21cc06468
Gitweb:
https://git.kernel.org/tip/38a1f03aa24094b4a8de846700cb6cb21cc06468
Author:Lenny Szubowicz
AuthorDate:Fri, 04 Sep 2020 21:31:06 -04:00
On 9/11/20 3:08 PM, Mimi Zohar wrote:
On Fri, 2020-09-11 at 21:16 +0300, Ard Biesheuvel wrote:
I think we can just merge the patches as they are, with Mimi's R-b carried over.
Other than the comments beginning on the "/*" line as opposed to the
subsequent line, the updated 2/2 and 3/3 patches
On 9/11/20 11:59 AM, Mimi Zohar wrote:
On Fri, 2020-09-11 at 11:54 -0400, Lenny Szubowicz wrote:
On 9/11/20 11:02 AM, Ard Biesheuvel wrote:
On Sat, 5 Sep 2020 at 04:31, Lenny Szubowicz wrote:
Move the loading of certs from the UEFI MokListRT into a separate
routine to facilitate additional
On 9/11/20 11:02 AM, Ard Biesheuvel wrote:
On Sat, 5 Sep 2020 at 04:31, Lenny Szubowicz wrote:
Move the loading of certs from the UEFI MokListRT into a separate
routine to facilitate additional MokList functionality.
There is no visible functional change as a result of this patch.
Although
files are read-only
to root and are provided for use by user space utilities such as
mokutil.
A subsequent patch will load MOK certs into the trusted platform
key ring using this infrastructure.
Signed-off-by: Lenny Szubowicz
---
arch/x86/kernel/setup.c | 1 +
arch/x86/platform
support to load certs from the MokListRT
entry in the MOK variable configuration table, if it's present.
The pre-existing support to load certs from the MokListRT EFI
variable remains and is used if the EFI MOK configuration table
isn't present or can't be successfully used.
Signe
. So the order of the keys
on their respective key rings is the same.
Signed-off-by: Lenny Szubowicz
---
security/integrity/platform_certs/load_uefi.c | 63 +--
1 file changed, 44 insertions(+), 19 deletions(-)
diff --git a/security/integrity/platform_certs/load_uefi.c
b/security
:
https://lore.kernel.org/lkml/20200826034455.28707-1-lszub...@redhat.com/
Lenny Szubowicz (3):
efi: Support for MOK variable config table
integrity: Move import of MokListRT certs to a separate routine
integrity: Load certs from the EFI MOK config table
arch/x86/kernel/setup.c
On 8/26/20 7:55 AM, Mimi Zohar wrote:
Hi Lenny,
On Tue, 2020-08-25 at 23:44 -0400, Lenny Szubowicz wrote:
Because of system-specific EFI firmware limitations,
EFI volatile variables may not be capable of holding the
required contents of the Machine Owner Key (MOK) certificate
store. Therefore
On 9/2/20 3:55 AM, Andy Shevchenko wrote:
On Wed, Aug 26, 2020 at 6:45 AM Lenny Szubowicz wrote:
Move the loading of certs from the UEFI MokListRT into a separate
routine to facilitate additional MokList functionality.
There is no visible functional change as a result of this patch.
Although
. So the order of the keys
on their respective key rings is the same.
Signed-off-by: Lenny Szubowicz
---
security/integrity/platform_certs/load_uefi.c | 63 +--
1 file changed, 44 insertions(+), 19 deletions(-)
diff --git a/security/integrity/platform_certs/load_uefi.c
b/security
the MOK variable configuration table, if it's present.
The pre-existing support to load certs from the MokListRT EFI
variable remains and is used if the EFI MOK configuration table
isn't present or can't be successfully used.
Signed-off-by: Lenny Szubowicz
---
security/integrity
such as mokutil.
A subsequent patch will load MOK certs into the trusted platform
key ring using this infrastructure.
Signed-off-by: Lenny Szubowicz
---
arch/x86/kernel/setup.c | 1 +
arch/x86/platform/efi/efi.c | 3 +
drivers/firmware/efi/Makefile | 1 +
drivers
sysfs binary files under:
/sys/firmware/efi/mok-variables/
Lenny Szubowicz (3):
efi: Support for MOK variable config table
integrity: Move import of MokListRT certs to a separate routine
integrity: Load certs from the EFI MOK config table
arch/x86/kernel/setup.c
()
doesn't commit the prior writes if there are still multiple references.
Additionally, since configfs does not support the fsync file operation,
a configfs flush only occurs in the context of a close. This makes it
safe to move the commit from release to flush.
Signed-off-by: Lenny Szubowicz
--
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: fd62619598069c974739476d1851a00d665041d7
Gitweb:
https://git.kernel.org/tip/fd62619598069c974739476d1851a00d665041d7
Author:Lenny Szubowicz
AuthorDate:Thu, 07 May 2020 14:33:32 -04:00
On 5/12/20 9:34 AM, Joerg Roedel wrote:
On Mon, May 11, 2020 at 09:43:11AM -0400, Lenny Szubowicz wrote:
I suspect that you have TPM 2.x functionality enabled in the BIOS/firmware.
Unless you are actually using the TPM, try setting it to TPM 1.2 mode.
I've seen an incompatiblity on
On 5/8/20 11:07 AM, Joerg Roedel wrote:
+ Baolu, Maintainer of Intel IOMMU
Baolu, does that ring any bells?
On Wed, May 06, 2020 at 04:46:02PM +0200, Uwe Kleine-König wrote:
Hello,
On my Lenovo T460p I cannot shutdown and reboot when the iommu is
enabled. This is using linux 5.2.7 as provided
ation.
Signed-off-by: Lenny Szubowicz
Suggested-by: Ard Biesheuvel
--
v3:
- Move define of EFI_MMAP_NR_SLACK_SLOTS to efistub.h instead
of providing a helper function to get it.
v2:
- Instead of freeing the EFI memory map buffer allocated by
efi_get_memory_map(), avoid the allocation in the
ation.
Signed-off-by: Lenny Szubowicz
Suggested-by: Ard Biesheuvel
--
v2:
- Instead of freeing the EFI memory map buffer allocated by
efi_get_memory_map(), avoid the allocation in the first place.
- Changed the title of the patch because the v1 title no longer
applies. v1 ref:
On 5/6/20 3:23 AM, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 21:00, Lenny Szubowicz wrote:
In allocate_e820(), free the EFI map buffer that has been returned
by efi_get_memory_map(). The returned size of the EFI map buffer
is used to allocate an adequately sized e820ext buffer, if it&#
gone on return from allocate_e820().
Signed-off-by: Lenny Szubowicz
---
drivers/firmware/efi/libstub/x86-stub.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/efi/libstub/x86-stub.c
b/drivers/firmware/efi/libstub/x86-stub.c
index 05ccb229fb45..4efe3e7a218d 100644
.
Signed-off-by: Lenny Szubowicz
---
drivers/acpi/acpi_lpit.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpi_lpit.c b/drivers/acpi/acpi_lpit.c
index e43cb71b6972..8b170a07908a 100644
--- a/drivers/acpi/acpi_lpit.c
+++ b/drivers/acpi/acpi_lpit.c
Fix once per second (round_robin_time) memory leak of about 1 KB in
each acpi_pad kernel idling thread that is activated.
Found by testing with kmemleak.
Signed-off-by: Lenny Szubowicz
---
drivers/acpi/acpi_pad.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/acpi/acpi_pad.c b
I methods. As a result, only the
appropriate driver registers as the cpu frequency driver and the other
one ends up being unloaded.
Tested on various systems where acpi-cpufreq, intel_pstate, and
pcc-cpufreq are the expected cpu frequency drivers.
Signed-off-by: Lenny Szubowicz
Signed-off-by:
- Original Message -
> From: "Lenny Szubowicz"
> To: "Matthew Garrett" ,
> linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org, jwbo...@redhat.com, keesc...@chromium.org
> Sent: Thursday, August 29, 2013 11:57:36 AM
> Subject: Re: [PATCH
- Original Message -
> From: "Matthew Garrett"
> To: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org, jwbo...@redhat.com, keesc...@chromium.org,
> "Matthew Garrett"
>
> Sent: Monday, August 19, 2013 12:10:13 PM
> Subject: [PATCH 04/10] ACPI: Limit access to custom_method
>
- Original Message -
> From: "Matthew Garrett"
> To: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org, jwbo...@redhat.com, keesc...@chromium.org,
> "Matthew Garrett"
>
> Sent: Monday, August 19, 2013 1:26:09 PM
> Subject: [PATCH V2 08/10] kexec: Disable at runtime if the ke
- Original Message -
> From: "Matthew Garrett"
> To: "Lenny Szubowicz"
> Cc: linux-kernel@vger.kernel.org, linux-...@vger.kernel.org,
> jwbo...@redhat.com, keesc...@chromium.org
> Sent: Wednesday, August 28, 2013 6:41:55 PM
> Subject: Re: [PATC
- Original Message -
> From: "Matthew Garrett"
> To: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org, jwbo...@redhat.com, keesc...@chromium.org
> Sent: Monday, August 19, 2013 1:26:01 PM
> Subject: [PATCH 0/10] Add additional security checks when module loading is
> restric
influence which facility registers with pstore, it's useful to have a
positive indication.
Signed-off-by: Lenny Szubowicz
Reported-by: Naotaka Hamaguchi
---
fs/pstore/platform.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platf
- Original Message -
> From: "Tony Luck"
> To: "Lenny Szubowicz"
> Cc: "Anton Vorontsov" , "Matt Fleming"
> , "Linux Kernel Mailing List"
> , "n hamaguchi" ,
> "Don Zickus"
> Sent:
a dangling pointer to deallocated mem for the pstore
buffer when registration fails.
Signed-off-by: Lenny Szubowicz
Reported-by: Naotaka Hamaguchi
---
drivers/acpi/apei/erst.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/apei/erst.c b/drivers
influence which facility registers with pstore, it's useful to have a
positive indication.
Signed-off-by: Lenny Szubowicz
Reported-by: Naotaka Hamaguchi
---
fs/pstore/platform.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/fs/pstore/platform.c b/fs/pstore/platf
This is patch 3/3 of a patch set that cleans up pstore_register failure paths.
If efivars fails to register with pstore, there is no point to keeping
the 4 KB buffer around. It's only used by the pstore read/write routines.
Signed-off-by: Lenny Szubowicz
Reported-by: Naotaka Hama
the individual patches.
Lenny Szubowicz (3):
pstore: Return unique error if backend registration excluded by kernel
param
acpi: Eliminate console msg if pstore.backend excludes ERST
efivars: If pstore_register fails, free unneeded pstore buffer
drivers/acpi/apei/erst.c | 20
44 matches
Mail list logo
