Re: [PATCH] tpm: Fix typo in tpmrm class definition

On Tue, Sep 12, 2023 at 4:41 AM Jarkko Sakkinen wrote: > > On Tue Sep 12, 2023 at 1:32 AM EEST, Justin M. Forbes wrote: > > Commit d2e8071bed0be ("tpm: make all 'class' structures const") > > unfortunately had a typo for the name on tpmrm. > > > > Fixes: d2e8071bed0b ("tpm: make all 'class'

Re: [PATCH] Fix typo in tpmrm class definition

On Mon, Sep 11, 2023 at 5:09 PM Jarkko Sakkinen wrote: > > On Fri Sep 8, 2023 at 5:06 PM EEST, Justin M. Forbes wrote: > > Commit d2e8071bed0be ("tpm: make all 'class' structures const") > > unfortunately had a typo for the name on tpmrm. > > > > Fixes: d2e8071bed0b ("tpm: make all 'class'

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

On Tue, Jan 26, 2021 at 11:07 AM Greg KH wrote: > > On Tue, Jan 26, 2021 at 10:19:34AM -0600, Josh Poimboeuf wrote: > > On Tue, Jan 26, 2021 at 10:15:52AM -0600, Justin Forbes wrote: > > > On Tue, Jan 26, 2021 at 10:05 AM Peter Zijlstra > > > wrote: > > >

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

On Tue, Jan 26, 2021 at 10:05 AM Peter Zijlstra wrote: > > On Tue, Jan 26, 2021 at 09:46:51AM -0600, Josh Poimboeuf wrote: > > On Tue, Jan 26, 2021 at 04:15:37PM +0100, Peter Zijlstra wrote: > > > On Tue, Jan 26, 2021 at 08:51:55AM -0600, Josh Poimboeuf wrote: > > > > User space mixes compiler

Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules

On Tue, Jan 26, 2021 at 2:21 AM Greg KH wrote: > > On Mon, Jan 25, 2021 at 04:07:57PM -0600, Josh Poimboeuf wrote: > > On Tue, Jan 26, 2021 at 06:44:35AM +0900, Masahiro Yamada wrote: > > > > > If people use a different compiler, they must be > > > > > prepared for any possible problem. > > > > >

Re: [PATCH] mm/filemap: add static for function __add_to_page_cache_locked

On Mon, Dec 7, 2020 at 2:16 AM Michal Kubecek wrote: > > On Thu, Nov 12, 2020 at 08:18:57AM +0800, Alex Shi wrote: > > > > > > 在 2020/11/11 上午3:50, Andrew Morton 写道: > > > On Tue, 10 Nov 2020 08:39:24 +0530 Souptick Joarder > > > wrote: > > > > > >> On Fri, Nov 6, 2020 at 4:55 PM Alex Shi > >

Re: [PATCH 5.8 35/99] tools/libbpf: Avoid counting local symbols in ABI check

On Wed, Sep 30, 2020 at 12:02 AM Tony Ambardar wrote: > > [adding Michael Ellerman, linux-ppc maintainer] > > Hello Justin, > > On Tue, 29 Sep 2020 at 14:54, Justin Forbes wrote: > > > > On Tue, Sep 29, 2020 at 6:53 AM Greg Kroah-Hartman > > wr

Re: [PATCH 5.8 35/99] tools/libbpf: Avoid counting local symbols in ABI check

On Tue, Sep 29, 2020 at 6:53 AM Greg Kroah-Hartman wrote: > > From: Tony Ambardar > > [ Upstream commit 746f534a4809e07f427f7d13d10f3a6a9641e5c3 ] > > Encountered the following failure building libbpf from kernel 5.8.5 sources > with GCC 8.4.0 and binutils 2.34: (long paths shortened) > >

Re: crypto: aegis128: error: incompatible types when initializing type 'unsigned char' using type 'uint8x16_t'

On Mon, Jul 27, 2020 at 8:05 AM Andrea Righi wrote: > > I'm experiencing this build error on arm64 after updating to gcc 10: > > crypto/aegis128-neon-inner.c: In function 'crypto_aegis128_init_neon': > crypto/aegis128-neon-inner.c:151:3: error: incompatible types when > initializing type

Re: [PATCH 5.2 123/413] PCI: Add missing link delays required by the PCIe spec

On Sat, Aug 3, 2019 at 1:50 AM Greg Kroah-Hartman wrote: > > On Fri, Aug 02, 2019 at 12:06:39PM -0500, Justin Forbes wrote: > > On Wed, Jul 24, 2019 at 3:31 PM Greg Kroah-Hartman > > wrote: > > > > > > [ Upstream commit c2bf1fc212f7e6f25ace1af8f0b3ac061ea48ba

Re: [PATCH 5.2 123/413] PCI: Add missing link delays required by the PCIe spec

On Wed, Jul 24, 2019 at 3:31 PM Greg Kroah-Hartman wrote: > > [ Upstream commit c2bf1fc212f7e6f25ace1af8f0b3ac061ea48ba5 ] > > Currently Linux does not follow PCIe spec regarding the required delays > after reset. A concrete example is a Thunderbolt add-in-card that > consists of a PCIe switch

Re: [PATCH 5.0 119/123] s390/mm: convert to the generic get_user_pages_fast code

On Mon, May 20, 2019 at 7:30 AM Greg Kroah-Hartman wrote: > > From: Martin Schwidefsky > > commit 1a42010cdc26bb7e5912984f3c91b8c6d55f089a upstream. > > Define the gup_fast_permitted to check against the asce_limit of the > mm attached to the current task, then replace the s390 specific gup >

Re: [PATCH] s390: mark __cpacf_check_opcode() and cpacf_query_func() as __always_inline

;) > Reported-by: Laura Abbott > Signed-off-by: Masahiro Yamada > --- > Thanks for the fix, this does indeed fix the build issues for us. Justin Tested-by: Justin Forbes > arch/s390/include/asm/cpacf.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley wrote: > On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote: >> James Bottomley wrote: >> >> > > > As a step by step process, I agree. However, I think we can >> > > > automate it to the point where you install a package and it >> > > > says

Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

On Fri, Aug 17, 2018 at 9:58 AM, James Bottomley wrote: > On Fri, 2018-08-17 at 09:24 +0100, David Howells wrote: >> James Bottomley wrote: >> >> > > > As a step by step process, I agree. However, I think we can >> > > > automate it to the point where you install a package and it >> > > > says

Re: [Ksummit-discuss] bug-introducing patches

On Tue, May 8, 2018 at 3:55 PM, Sasha Levin wrote: > On Tue, May 08, 2018 at 08:40:02PM +, Matthew Wilcox wrote: >>I think your sample size omits some people. I run Debian Testing on my >>laptop. That gets something akin to a Linus release pretty soon after he

Re: [Ksummit-discuss] bug-introducing patches

On Tue, May 8, 2018 at 3:55 PM, Sasha Levin wrote: > On Tue, May 08, 2018 at 08:40:02PM +, Matthew Wilcox wrote: >>I think your sample size omits some people. I run Debian Testing on my >>laptop. That gets something akin to a Linus release pretty soon after he >>releases it, and while it gets

Re: [Ksummit-discuss] bug-introducing patches

On Mon, May 7, 2018 at 9:34 PM, Sasha Levin wrote: > On Thu, May 03, 2018 at 04:09:05PM -0700, Tony Lindgren wrote: >>* Mark Brown [180503 22:44]: >>> On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote: >>> >>> > As for -next, me and

Re: [Ksummit-discuss] bug-introducing patches

On Mon, May 7, 2018 at 9:34 PM, Sasha Levin wrote: > On Thu, May 03, 2018 at 04:09:05PM -0700, Tony Lindgren wrote: >>* Mark Brown [180503 22:44]: >>> On Wed, May 02, 2018 at 08:52:29PM -0700, Guenter Roeck wrote: >>> >>> > As for -next, me and others stopped reporting bugs in it, because when

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 3, 2018 at 11:02 AM, Sasha Levin wrote: > On Thu, May 03, 2018 at 08:49:11AM -0700, Guenter Roeck wrote: >>On Thu, May 03, 2018 at 02:55:36PM +, Sasha Levin wrote: >>> On Wed, May 02, 2018 at 05:38:32PM -0700, Guenter Roeck wrote: >>> >On 05/02/2018

Re: [Ksummit-discuss] bug-introducing patches

On Thu, May 3, 2018 at 11:02 AM, Sasha Levin wrote: > On Thu, May 03, 2018 at 08:49:11AM -0700, Guenter Roeck wrote: >>On Thu, May 03, 2018 at 02:55:36PM +, Sasha Levin wrote: >>> On Wed, May 02, 2018 at 05:38:32PM -0700, Guenter Roeck wrote: >>> >On 05/02/2018 05:06 PM, Theodore Y. Ts'o

Re: Linux messages full of `random: get_random_u32 called from`

On Wed, May 2, 2018 at 5:25 PM, Theodore Y. Ts'o wrote: > On Wed, May 02, 2018 at 10:49:34AM -0700, Laura Abbott wrote: >> >> It is a Fedora patch we're carrying >> https://src.fedoraproject.org/rpms/libgcrypt/blob/master/f/libgcrypt-1.6.2-fips-ctor.patch#_23 >> so yes, it is a

Re: Linux messages full of `random: get_random_u32 called from`

On Wed, May 2, 2018 at 5:25 PM, Theodore Y. Ts'o wrote: > On Wed, May 02, 2018 at 10:49:34AM -0700, Laura Abbott wrote: >> >> It is a Fedora patch we're carrying >> https://src.fedoraproject.org/rpms/libgcrypt/blob/master/f/libgcrypt-1.6.2-fips-ctor.patch#_23 >> so yes, it is a Fedora specific

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, May 1, 2018 at 7:02 PM, Theodore Y. Ts'o <ty...@mit.edu> wrote: > On Tue, May 01, 2018 at 05:35:56PM -0500, Justin Forbes wrote: >> >> I have not reproduced in GCE myself. We did get some confirmation >> that removing dracut-fips does make the problem less dire

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, May 1, 2018 at 7:02 PM, Theodore Y. Ts'o wrote: > On Tue, May 01, 2018 at 05:35:56PM -0500, Justin Forbes wrote: >> >> I have not reproduced in GCE myself. We did get some confirmation >> that removing dracut-fips does make the problem less dire (but I >> wo

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, May 1, 2018 at 7:55 AM, Theodore Y. Ts'o <ty...@mit.edu> wrote: > On Tue, May 01, 2018 at 06:52:47AM -0500, Justin Forbes wrote: >> >> We have also had reports that Fedora users are seeing this on Google >> Compute Engine. > > Can you reproduce this yo

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, May 1, 2018 at 7:55 AM, Theodore Y. Ts'o wrote: > On Tue, May 01, 2018 at 06:52:47AM -0500, Justin Forbes wrote: >> >> We have also had reports that Fedora users are seeing this on Google >> Compute Engine. > > Can you reproduce this yourself? If so, could

Re: Linux messages full of `random: get_random_u32 called from`

On Mon, Apr 30, 2018 at 4:12 PM, Jeremy Cline wrote: > On 04/29/2018 06:05 PM, Theodore Y. Ts'o wrote: >> On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote: >>> On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote: Umm. No.

Re: Linux messages full of `random: get_random_u32 called from`

On Mon, Apr 30, 2018 at 4:12 PM, Jeremy Cline wrote: > On 04/29/2018 06:05 PM, Theodore Y. Ts'o wrote: >> On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote: >>> On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote: Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE >>>

Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image

On Wed, Apr 11, 2018, 5:38 PM Linus Torvalds wrote: > > On Wed, Apr 11, 2018 at 2:05 PM, Jordan Glover > wrote: > >> > >> If that /dev/mem access prevention was just instead done as an even > >> stricter mode of the existing

Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image

On Wed, Apr 11, 2018, 5:38 PM Linus Torvalds wrote: > > On Wed, Apr 11, 2018 at 2:05 PM, Jordan Glover > wrote: > >> > >> If that /dev/mem access prevention was just instead done as an even > >> stricter mode of the existing CONFIG_STRICT_DEVMEM, it could just be > >> enabled unconditionally. >

Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image

On Wed, Apr 11, 2018 at 1:09 PM, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 9:24 AM, David Howells wrote: >> Provide a single call to allow kernel code to determine whether the system >> should be locked down, thereby disallowing various

Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image

On Wed, Apr 11, 2018 at 1:09 PM, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 9:24 AM, David Howells wrote: >> 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

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: >> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote: >> >>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: >>>

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: >> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote: >> >>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: >>> > Theodore Y. Ts'o wrote: >>> > >>> > > Whoa.

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett wrote: >> >> The generic distros have been shipping this policy for the past 5 years. > > .. so apparently it doesn't actually break things?

Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett wrote: >> >> The generic distros have been shipping this policy for the past 5 years. > > .. so apparently it doesn't actually break things? Why not enable it > by default then? > > And if

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

On Tue, Jan 9, 2018 at 8:02 PM, Dave Hansen wrote: > On 01/09/2018 05:06 PM, Thomas Gleixner wrote: >> --- a/arch/x86/kernel/cpu/bugs.c >> +++ b/arch/x86/kernel/cpu/bugs.c >> @@ -79,6 +79,7 @@ enum spectre_v2_mitigation_cmd { >> SPECTRE_V2_CMD_RETPOLINE, >>

Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

On Tue, Jan 9, 2018 at 8:02 PM, Dave Hansen wrote: > On 01/09/2018 05:06 PM, Thomas Gleixner wrote: >> --- a/arch/x86/kernel/cpu/bugs.c >> +++ b/arch/x86/kernel/cpu/bugs.c >> @@ -79,6 +79,7 @@ enum spectre_v2_mitigation_cmd { >> SPECTRE_V2_CMD_RETPOLINE, >>

Re: [PATCH v3 11/13] retpoline/taint: Taint kernel for missing retpoline in compiler

On Thu, Jan 4, 2018 at 8:37 AM, David Woodhouse wrote: > From: Andi Kleen > > When the kernel or a module hasn't been compiled with a retpoline > aware compiler, print a warning and set a taint flag. > > For modules it is checked at compile time, however

Re: [PATCH v3 11/13] retpoline/taint: Taint kernel for missing retpoline in compiler

On Thu, Jan 4, 2018 at 8:37 AM, David Woodhouse wrote: > From: Andi Kleen > > When the kernel or a module hasn't been compiled with a retpoline > aware compiler, print a warning and set a taint flag. > > For modules it is checked at compile time, however it cannot > check assembler or other non

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 11:56 AM, Tim Chen wrote: > This patch series enables the basic detection and usage of x86 indirect > branch speculation feature. It enables the indirect branch restricted > speculation (IBRS) on kernel entry and disables it on exit. > It

Re: [PATCH 0/7] IBRS patch series

On Thu, Jan 4, 2018 at 11:56 AM, Tim Chen wrote: > This patch series enables the basic detection and usage of x86 indirect > branch speculation feature. It enables the indirect branch restricted > speculation (IBRS) on kernel entry and disables it on exit. > It enumerates the indirect branch

Re: [PATCH] powerpc: fix distclean with Makefile.postlink

On Mon, May 8, 2017 at 8:50 AM, Horia Geantă wrote: > On 5/8/2017 2:57 PM, Michael Ellerman wrote: >> Horia Geantă writes: >> >>> Makefile.postlink always includes include/config/auto.conf, however >>> this file is not present in a clean kernel tree,

Re: [PATCH] powerpc: fix distclean with Makefile.postlink

On Mon, May 8, 2017 at 8:50 AM, Horia Geantă wrote: > On 5/8/2017 2:57 PM, Michael Ellerman wrote: >> Horia Geantă writes: >> >>> Makefile.postlink always includes include/config/auto.conf, however >>> this file is not present in a clean kernel tree, causing make to fail: >>> >>>

Re: [PATCH 00/24] Kernel lockdown

ec_file.c |6 ++ > kernel/module.c |2 +- > kernel/params.c | 27 - > kernel/power/hibernate.c |2 +- > kernel/power/user.c |3 +++ > kernel/trace/bpf_trace.c |

Re: [PATCH 00/24] Kernel lockdown

++ > kernel/module.c |2 +- > kernel/params.c | 27 - > kernel/power/hibernate.c |2 +- > kernel/power/user.c |3 +++ > kernel/trace/bpf_trace.c | 11 ++ > security/Kconfig | 15 ++ > security/Makefile |3 +++ > security/lock_down.c | 40 > + > 35 files changed, 291 insertions(+), 22 deletions(-) > create mode 100644 security/lock_down.c > Tested-by: Justin Forbes

Re: [PATCH 00/24] Kernel lockdown

On Fri, Apr 7, 2017 at 10:59 AM, Austin S. Hemmelgarn wrote: > On 2017-04-05 16:14, David Howells wrote: >> >> >> These patches provide a facility by which a variety of avenues by which >> userspace can feasibly modify the running kernel image can be locked down. >> These

Re: [PATCH 00/24] Kernel lockdown

On Fri, Apr 7, 2017 at 10:59 AM, Austin S. Hemmelgarn wrote: > On 2017-04-05 16:14, David Howells wrote: >> >> >> These patches provide a facility by which a variety of avenues by which >> userspace can feasibly modify the running kernel image can be locked down. >> These include: >> >> (*) No

Re: [PATCH 00/16] Kernel lockdown

On Wed, Nov 16, 2016 at 3:47 PM, David Howells wrote: > > These patches provide a facility by which a variety of avenues by which > userspace can feasibly modify the running kernel image can be locked down. > These include: > Bit surprised to see this. Not that I am opposed

Re: [PATCH 00/16] Kernel lockdown

On Wed, Nov 16, 2016 at 3:47 PM, David Howells wrote: > > These patches provide a facility by which a variety of avenues by which > userspace can feasibly modify the running kernel image can be locked down. > These include: > Bit surprised to see this. Not that I am opposed to the patches