| Message ID | 20190520205501.177637-1-matthewgarrett@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for crypto agile logs | expand |
On Mon, May 20, 2019 at 01:54:57PM -0700, Matthew Garrett wrote: > Identical to previous version except without the KSAN workaround - Ard > has a better solution for that. I'll check in detail through tomorrow but probably will get merged now that we have Ard's ack's (thanks Ard for all the trouble!) :-) /Jarkko
On Mon, May 20, 2019 at 01:54:57PM -0700, Matthew Garrett wrote: > Identical to previous version except without the KSAN workaround - Ard > has a better solution for that. Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> /Jarkko
On Thu, May 23, 2019 at 03:14:49PM +0300, Jarkko Sakkinen wrote: > On Mon, May 20, 2019 at 01:54:57PM -0700, Matthew Garrett wrote: > > Identical to previous version except without the KSAN workaround - Ard > > has a better solution for that. > > > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Only applied to my master at this point becaues the patches from my earlier PRs are not yet mirrored to security/next-general. /Jarkko
On Mon, May 20, 2019 at 10:55 PM Matthew Garrett <matthewgarrett@google.com> wrote: > > Identical to previous version except without the KSAN workaround - Ard > has a better solution for that. Just tested the patchset on aarch64, all works fine. Reviewed-by: Bartosz Szczepanek <bsz@semihalf.com> Tested-by: Bartosz Szczepanek <bsz@semihalf.com>
On Thu, 23 May 2019, Jarkko Sakkinen wrote: > On Thu, May 23, 2019 at 03:14:49PM +0300, Jarkko Sakkinen wrote: > > On Mon, May 20, 2019 at 01:54:57PM -0700, Matthew Garrett wrote: > > > Identical to previous version except without the KSAN workaround - Ard > > > has a better solution for that. > > > > > > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > Only applied to my master at this point becaues the patches from > my earlier PRs are not yet mirrored to security/next-general. Which PRs are these? btw, Linus wants security subsystem maintainers to submit PRs directly to him from now on. I'll only be carrying patches for the core LSM and new security mechanisms before they're merged and have a maintainer assigned.
On Fri, May 24, 2019 at 02:54:20AM +1000, James Morris wrote: > On Thu, 23 May 2019, Jarkko Sakkinen wrote: > > > On Thu, May 23, 2019 at 03:14:49PM +0300, Jarkko Sakkinen wrote: > > > On Mon, May 20, 2019 at 01:54:57PM -0700, Matthew Garrett wrote: > > > > Identical to previous version except without the KSAN workaround - Ard > > > > has a better solution for that. > > > > > > > > > Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> > > > > Only applied to my master at this point becaues the patches from > > my earlier PRs are not yet mirrored to security/next-general. > > Which PRs are these? > > btw, Linus wants security subsystem maintainers to submit PRs directly to > him from now on. > > I'll only be carrying patches for the core LSM and new security mechanisms > before they're merged and have a maintainer assigned. I'm referring to these: https://lore.kernel.org/linux-integrity/20190329115544.GA27351@linux.intel.com/ I got response from you that those were applied and there is another response in that thread that they are being sent to Linus. That is why I haven't done anything since. Most of them are critical fixes to v5.1 changes. Should I now take the action to send a PR to Linus and tag them to stable? /Jarkko
On Fri, 24 May 2019, Jarkko Sakkinen wrote: > I'm referring to these: > > https://lore.kernel.org/linux-integrity/20190329115544.GA27351@linux.intel.com/ > > I got response from you that those were applied and there is another > response in that thread that they are being sent to Linus. That is why I > haven't done anything since. Most of them are critical fixes to v5.1 > changes. These are in Linus' tree. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a556810d8e06aa2da8bbe22da3d105eb5a0d0c7d I initially queued them in the next-tpm branch, but forgot to drop them from there after sending them to Linus as a v5.1 fix. Linus was not happy to see them again in the v5.2 merge window. Apologies for the confusion.
On Sat, May 25, 2019 at 05:22:34AM +1000, James Morris wrote: > On Fri, 24 May 2019, Jarkko Sakkinen wrote: > > > I'm referring to these: > > > > https://lore.kernel.org/linux-integrity/20190329115544.GA27351@linux.intel.com/ > > > > I got response from you that those were applied and there is another > > response in that thread that they are being sent to Linus. That is why I > > haven't done anything since. Most of them are critical fixes to v5.1 > > changes. > > These are in Linus' tree. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a556810d8e06aa2da8bbe22da3d105eb5a0d0c7d > > I initially queued them in the next-tpm branch, but forgot to drop them > from there after sending them to Linus as a v5.1 fix. Linus was not happy > to see them again in the v5.2 merge window. > > Apologies for the confusion. OK, just to confirm, my next PR will go straight to Linus? /Jarkko
On Mon, May 20, 2019 at 1:56 PM Matthew Garrett <matthewgarrett@google.com> wrote: > > Identical to previous version except without the KSAN workaround - Ard > has a better solution for that. I just tested this on x86_64 with the systemd-boot (previously gummiboot) bootloader. For context, this bootloader is essentially just an EFI chainloader. This bootloader measures the kernel cmdline into PCR 8. However, it calls GetEventLog before calling HashLogExtendEvent, intending to have the log entry written to the "EFI TCG 2.0 final events table". See: https://github.com/systemd/systemd/blob/75e40119a471454516ad0acc96f6f4094e7fb652/src/boot/efi/measure.c#L212-L227 With the current patchset, this log entry appears _twice_ in the sysfs file. This is caused by the fact that the sysfs event log unconditionally appends the entire final event log to the output of GetEventLog. However, the correct behavior would be to append only the _new_ entries that appear in the final event log to the output of GetEventLog. This could be done by first calculating the length of the final events log table, then recalculating the length of the final events log after the kernel calls ExitBootServices. This would let us know for sure that we are only appending new log entries.