Re: [PATCH 1/2] efi+tpm: Don't access event->count when it isn't mapped.
On Tue, Aug 27, 2019 at 04:41:55PM +0300, Jarkko Sakkinen wrote: > On Tue, Aug 27, 2019 at 02:03:44PM +0300, Jarkko Sakkinen wrote: > > > Jarkko, these two should probably go to 5.3 if possible - I > > > independently had a report of a system hitting this issue last week > > > (Intel apparently put a surprising amount of data in the event logs on > > > the NUCs). > > > > OK, I can try to push them. I'll do PR today. > > Ard, how do you wish these to be managed? > > I'm asking this because: > > 1. Neither patch was CC'd to linux-integrity. > 2. Neither patch has your tags ATM. I think Ard's not back until September. I can just to re-send them with the accumulated tags and Cc linux-integrity, if you think that would help? -- Peter
Re: [PATCH 1/2] efi+tpm: Don't access event->count when it isn't mapped.
On Tue, Aug 27, 2019 at 6:42 AM Jarkko Sakkinen wrote: > > On Tue, Aug 27, 2019 at 02:03:44PM +0300, Jarkko Sakkinen wrote: > > > Jarkko, these two should probably go to 5.3 if possible - I > > > independently had a report of a system hitting this issue last week > > > (Intel apparently put a surprising amount of data in the event logs on > > > the NUCs). > > > > OK, I can try to push them. I'll do PR today. > > Ard, how do you wish these to be managed? > > I'm asking this because: > > 1. Neither patch was CC'd to linux-integrity. > 2. Neither patch has your tags ATM. Feel free to add my tags, but I don't think it's important.
Re: [PATCH 0/6 V2] CCIX Protocol error reporting.
Jonathan, On Tue, 20 Aug 2019, Jonathan Cameron wrote: Cc+ linux-s...@vger.kernel.org > The following boilerplate is granting rights to the kernel. > Note that I haven't applied the CCIX copyright notice anywhere in this > series because we aren't quoting from the specification. That is > much more likely to happen in documentation patches than in code. > > Like anything else in this series it is open to comment. > > This patch is being distributed by the CCIX Consortium, Inc. (CCIX) to > you and other parties that are participating (the "participants") in the > Linux kernel with the understanding that the participants will use CCIX's > name and trademark only when this patch is used in association with the > Linux kernel and associated user space. The code is licensed under GPLV2, so what precludes any other GPLV2 project to import that code? If there is a mentioning of CCIX Consortium in the imported code then you cannot impose that this needs to be removed because it ends up in something which is neither Linux kernel nor associated user space. And that's especially true when this ends up being a copyright notice. > CCIX is also distributing this patch to these participants with the > understanding that if any portion of the CCIX specification will be > used or referenced in the Linux kernel, the participants will not modify > the cited portion of the CCIX specification and will give CCIX proper > copyright attribution by including the following copyright notice with > the cited part of the CCIX specification: > "© 2019 CCIX CONSORTIUM, INC. ALL RIGHTS RESERVED." Just to prove the point. Thanks, tglx
Re: [PATCH 1/2] efi+tpm: Don't access event->count when it isn't mapped.
On Tue, Aug 27, 2019 at 02:03:44PM +0300, Jarkko Sakkinen wrote: > > Jarkko, these two should probably go to 5.3 if possible - I > > independently had a report of a system hitting this issue last week > > (Intel apparently put a surprising amount of data in the event logs on > > the NUCs). > > OK, I can try to push them. I'll do PR today. Ard, how do you wish these to be managed? I'm asking this because: 1. Neither patch was CC'd to linux-integrity. 2. Neither patch has your tags ATM. /Jarkko
Re: [PATCH 1/2] efi+tpm: Don't access event->count when it isn't mapped.
On Mon, Aug 26, 2019 at 10:44:31AM -0700, Matthew Garrett wrote: > On Mon, Aug 26, 2019 at 9:28 AM Jarkko Sakkinen > wrote: > > > > On Mon, Aug 26, 2019 at 11:30:27AM -0400, Peter Jones wrote: > > > Some machines generate a lot of event log entries. When we're > > > iterating over them, the code removes the old mapping and adds a > > > new one, so once we cross the page boundary we're unmapping the page > > > with the count on it. Hilarity ensues. > > > > > > This patch keeps the info from the header in local variables so we don't > > > need to access that page again or keep track of if it's mapped. > > > > > > Signed-off-by: Peter Jones > > > Tested-by: Lyude Paul > > > > Reviewed-by: Jarkko Sakkinen > Acked-by: Matthew Garrett > > Jarkko, these two should probably go to 5.3 if possible - I > independently had a report of a system hitting this issue last week > (Intel apparently put a surprising amount of data in the event logs on > the NUCs). OK, I can try to push them. I'll do PR today. /Jarkko
Re: Early EFI-related boot freeze in parse_setup_data()
On Fri, Aug 16, 2019 at 2:14 PM Daniel Drake wrote: > Anyway, the system freeze occurs in parse_setup_data(), specifically: > > data = early_memremap(pa_data, sizeof(*data)); > data_len = data->len + sizeof(struct setup_data); > > Dereferencing data->len causes the system to hang. I presume it > triggers an exception handler due to some kind of invalid memory > access. > > By returning early in that function, boot continues basically fine. So > I could then log the details: pa_data has value 0x892bb018 and > early_memremap returns address 0xff200018. Accessing just a > single byte at that address causes the system hang. I noticed a complaint about NX in the logs, right where it does the early_memremap of this data (which is now at address 0x893c0018): Notice: NX (Execute Disable) protection missing in CPU! e820: update [mem 0x893c0018-0x893cec57] usable ==> usable e820: update [mem 0x893c0018-0x893cec57] usable ==> usable e820: update [mem 0x893b3018-0x893bf057] usable ==> usable e820: update [mem 0x893b3018-0x893bf057] usable ==> usable Indeed, in the BIOS setup menu, "NX Mode" was Disabled. Setting it to Enabled avoids the hang and Linux boots as normal. Weird! Daniel
