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' struct
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' structu
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:
> > >
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 ver
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.
> > > > >
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
> >
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
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)
>
> Warni
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 'unsigne
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
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 and
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
> cod
NFIG_OPTIMIZE_INLINING")
> 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
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 "
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
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 we
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 wrote
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 use
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
>>
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
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
>>>
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.
> >
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
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. Why
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 "tur
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,
>> SPECTRE_V2_CMD_RETPOLINE_GEN
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 c
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 pred
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:
>>>
>>> arch/powerpc/Mak
|6 ++
> 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
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 un
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
themse
32 matches
Mail list logo
