You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(11) |
Feb
(11) |
Mar
|
Apr
|
May
(3) |
Jun
(19) |
Jul
(5) |
Aug
(13) |
Sep
(18) |
Oct
(8) |
Nov
(25) |
Dec
(3) |
2006 |
Jan
(16) |
Feb
|
Mar
|
Apr
(55) |
May
(23) |
Jun
(5) |
Jul
(19) |
Aug
(12) |
Sep
(12) |
Oct
(24) |
Nov
(3) |
Dec
(7) |
2007 |
Jan
|
Feb
(13) |
Mar
(12) |
Apr
(4) |
May
|
Jun
|
Jul
(6) |
Aug
(12) |
Sep
(3) |
Oct
(1) |
Nov
(16) |
Dec
(2) |
2008 |
Jan
(20) |
Feb
(6) |
Mar
(2) |
Apr
(3) |
May
(29) |
Jun
(11) |
Jul
(16) |
Aug
(7) |
Sep
(2) |
Oct
|
Nov
(9) |
Dec
(24) |
2009 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(5) |
Jun
(13) |
Jul
(25) |
Aug
|
Sep
(47) |
Oct
(5) |
Nov
(13) |
Dec
|
2010 |
Jan
(2) |
Feb
(4) |
Mar
(7) |
Apr
(6) |
May
(2) |
Jun
(14) |
Jul
(10) |
Aug
(6) |
Sep
(12) |
Oct
(6) |
Nov
(16) |
Dec
|
2011 |
Jan
(8) |
Feb
(10) |
Mar
(41) |
Apr
|
May
(5) |
Jun
(1) |
Jul
(1) |
Aug
(6) |
Sep
(8) |
Oct
(11) |
Nov
|
Dec
(15) |
2012 |
Jan
(15) |
Feb
(5) |
Mar
(7) |
Apr
(4) |
May
(19) |
Jun
(27) |
Jul
(20) |
Aug
(40) |
Sep
(19) |
Oct
(45) |
Nov
(102) |
Dec
(26) |
2013 |
Jan
(18) |
Feb
(21) |
Mar
(36) |
Apr
(46) |
May
(46) |
Jun
(10) |
Jul
(20) |
Aug
(8) |
Sep
(53) |
Oct
(109) |
Nov
(58) |
Dec
(37) |
2014 |
Jan
(37) |
Feb
(19) |
Mar
(5) |
Apr
(16) |
May
(23) |
Jun
(3) |
Jul
(30) |
Aug
(40) |
Sep
(110) |
Oct
(207) |
Nov
(84) |
Dec
(147) |
2015 |
Jan
(88) |
Feb
(40) |
Mar
(57) |
Apr
(61) |
May
(48) |
Jun
(65) |
Jul
(23) |
Aug
(15) |
Sep
(43) |
Oct
(130) |
Nov
(210) |
Dec
(177) |
2016 |
Jan
(135) |
Feb
(302) |
Mar
(288) |
Apr
(201) |
May
(65) |
Jun
(166) |
Jul
(193) |
Aug
(139) |
Sep
(211) |
Oct
(281) |
Nov
(259) |
Dec
(86) |
2017 |
Jan
(571) |
Feb
(257) |
Mar
(276) |
Apr
(138) |
May
(257) |
Jun
(145) |
Jul
(68) |
Aug
(176) |
Sep
(152) |
Oct
(72) |
Nov
(18) |
Dec
(9) |
2018 |
Jan
(5) |
Feb
|
Mar
(30) |
Apr
(1) |
May
(18) |
Jun
(2) |
Jul
|
Aug
(43) |
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: James M. <jm...@na...> - 2023-01-20 23:08:06
|
The Call for Participation for the 2023 LSS-NA conference is open! See details of the event and information on submitting proposals here: https://events.linuxfoundation.org/linux-security-summit-north-america/ LSS-NA 2023 will be in Vancouver, BC, Canada, from May 10th to May 12th. This will be a three day event, co-located with Open Source Summit North America [1]. The LSS-NA CfP is open until March 1st, 2023. Note that announcements relating to the Linux Security Summit may be found now on the Fediverse, via: https://social.kernel.org/LinuxSecSummit -- James Morris <jm...@na...> [1] https://events.linuxfoundation.org/open-source-summit-north-america/ |
From: James M. <jm...@na...> - 2022-03-18 23:04:04
|
On Tue, 8 Feb 2022, James Morris wrote: > * Event: September 23-24 Correction: This should be 23-24 June per the top of the email. -- James Morris <jm...@na...> |
From: James M. <jm...@na...> - 2022-02-07 22:52:35
|
============================================================================== ANNOUNCEMENT AND CALL FOR PARTICIPATION LINUX SECURITY SUMMIT NORTH AMERICA 2022 23-24 June Austin, Texas & Virtual ============================================================================== DESCRIPTION Linux Security Summit North America (LSS-NA) is a technical forum for collaboration between Linux developers, researchers, and end-users. Its primary aim is to foster community efforts in analyzing and solving Linux security challenges. The program committee currently seeks proposals for: * Refereed Presentations: 45 minutes in length. * Panel Discussion Topics: 45 minutes in length. * Short Topics: 30 minutes in total, including at least 10 minutes discussion. * Tutorials 90 minutes in length. Tutorial sessions should be focused on advanced Linux security defense topics within areas such as the kernel, compiler, and security-related libraries. Priority will be given to tutorials created for this conference, and those where the presenter a leading subject matter expert on the topic. Topic areas include, but are not limited to: * Kernel self-protection * Access control * Cryptography and key management * Integrity policy and enforcement * Hardware Security * IoT and embedded security * Virtualization and containers * System-specific system hardening * Case studies * Security tools * Security UX * Emerging technologies, threats & techniques Proposals should be submitted via: https://events.linuxfoundation.org/linux-security-summit-north-america/ Note that for 2022, we are returning to having both North American and European events (LSS-EU will be held in September). LSS-NA DATES * CFP close: March 30 * CFP notifications: April 15 * Schedule announced: April 19 * Event: September 23-24 WHO SHOULD ATTEND We're seeking a diverse range of attendees and welcome participation by people involved in Linux security development, operations, and research. LSS is a unique global event that provides the opportunity to present and discuss your work or research with key Linux security community members and maintainers. It's also useful for those who wish to keep up with the latest in Linux security development and to provide input to the development process. WEB SITE https://events.linuxfoundation.org/linux-security-summit-north-america/ TWITTER For event updates and announcements, follow: https://twitter.com/LinuxSecSummit #linuxsecuritysummit PROGRAM COMMITTEE The program committee for LSS 2021 is: * James Morris, Microsoft * Serge Hallyn, Cisco * Paul Moore, Microsoft * Stephen Smalley, NSA * Elena Reshetova, Intel * John Johansen, Canonical * Kees Cook, Google * Casey Schaufler, Intel * Mimi Zohar, IBM * David A. Wheeler, Linux Foundation The program committee may be contacted as a group via email: lss-pc () lists.linuxfoundation.org -- |
From: James M. <jm...@na...> - 2021-09-14 03:11:33
|
For folks presenting remotely, the deadline for video talks is extended to 20th September, 2021. Reminder: you can keep track LSS event information via: https://twitter.com/LinuxSecSummit -- James Morris <jm...@na...> |
From: James M. <jm...@na...> - 2021-06-22 02:52:55
|
Two further (and hopefully final) changes: - LSS 2021 will now be a hybrid event, catering to both in-person and remote attendees and presenters - The CFP is extended to July 11th. On Wed, 26 May 2021, James Morris wrote: > Note that the venue of LSS 2021 has now changed to Seattle, USA. > > See https://events.linuxfoundation.org/linux-security-summit-north-america/ > > The new event dates are 29 September to 01 October. > > The CFP closes on June 27th. > > > > > > On Tue, 9 Feb 2021, James Morris wrote: > > > ============================================================================== > > ANNOUNCEMENT AND CALL FOR PARTICIPATION > > > > LINUX SECURITY SUMMIT 2021 > > > > 27-29 September > > Dublin, Ireland > > ============================================================================== > > > > DESCRIPTION > > > > Linux Security Summit (LSS) is a technical forum for collaboration between > > Linux developers, researchers, and end-users. Its primary aim is to foster > > community efforts in analyzing and solving Linux security challenges. > > > > The program committee currently seeks proposals for: > > > > * Refereed Presentations: > > 45 minutes in length. > > > > * Panel Discussion Topics: > > 45 minutes in length. > > > > * Short Topics: > > 30 minutes in total, including at least 10 minutes discussion. > > > > * Tutorials > > 90 minutes in length. > > > > Tutorial sessions should be focused on advanced Linux security defense > > topics within areas such as the kernel, compiler, and security-related > > libraries. Priority will be given to tutorials created for this conference, > > and those where the presenter a leading subject matter expert on the topic. > > > > Topic areas include, but are not limited to: > > > > * Kernel self-protection > > * Access control > > * Cryptography and key management > > * Integrity policy and enforcement > > * Hardware Security > > * IoT and embedded security > > * Virtualization and containers > > * System-specific system hardening > > * Case studies > > * Security tools > > * Security UX > > * Emerging technologies, threats & techniques > > > > Proposals should be submitted via: > > https://events.linuxfoundation.org/linux-security-summit-europe/program/cfp/ > > > > > > ** Note that for 2021, the North American and European events are combined into > > a single event planned for Dublin, Ireland. ** > > > > > > DATES > > > > * CFP close: June 27 > > * CFP notifications: July 20 > > * Schedule announced: July 22 > > * Event: September 27-29 > > > > WHO SHOULD ATTEND > > > > We're seeking a diverse range of attendees and welcome participation by > > people involved in Linux security development, operations, and research. > > > > LSS is a unique global event that provides the opportunity to present and > > discuss your work or research with key Linux security community members and > > maintainers. It's also useful for those who wish to keep up with the latest > > in Linux security development and to provide input to the development > > process. > > > > WEB SITE > > > > https://events.linuxfoundation.org/linux-security-summit-europe/ > > > > TWITTER > > > > For event updates and announcements, follow: > > > > https://twitter.com/LinuxSecSummit > > > > #linuxsecuritysummit > > > > PROGRAM COMMITTEE > > > > The program committee for LSS 2021 is: > > > > * James Morris, Microsoft > > * Serge Hallyn, Cisco > > * Paul Moore, Cisco > > * Stephen Smalley, NSA > > * Elena Reshetova, Intel > > * John Johansen, Canonical > > * Kees Cook, Google > > * Casey Schaufler, Intel > > * Mimi Zohar, IBM > > * David A. Wheeler, Institute for Defense Analyses > > > > The program committee may be contacted as a group via email: > > lss-pc () lists.linuxfoundation.org > > > > > > -- > James Morris > <jm...@na...> > > -- James Morris <jm...@na...> |
From: James M. <jm...@na...> - 2021-05-25 16:44:58
|
Note that the venue of LSS 2021 has now changed to Seattle, USA. See https://events.linuxfoundation.org/linux-security-summit-north-america/ The new event dates are 29 September to 01 October. The CFP closes on June 27th. On Tue, 9 Feb 2021, James Morris wrote: > ============================================================================== > ANNOUNCEMENT AND CALL FOR PARTICIPATION > > LINUX SECURITY SUMMIT 2021 > > 27-29 September > Dublin, Ireland > ============================================================================== > > DESCRIPTION > > Linux Security Summit (LSS) is a technical forum for collaboration between > Linux developers, researchers, and end-users. Its primary aim is to foster > community efforts in analyzing and solving Linux security challenges. > > The program committee currently seeks proposals for: > > * Refereed Presentations: > 45 minutes in length. > > * Panel Discussion Topics: > 45 minutes in length. > > * Short Topics: > 30 minutes in total, including at least 10 minutes discussion. > > * Tutorials > 90 minutes in length. > > Tutorial sessions should be focused on advanced Linux security defense > topics within areas such as the kernel, compiler, and security-related > libraries. Priority will be given to tutorials created for this conference, > and those where the presenter a leading subject matter expert on the topic. > > Topic areas include, but are not limited to: > > * Kernel self-protection > * Access control > * Cryptography and key management > * Integrity policy and enforcement > * Hardware Security > * IoT and embedded security > * Virtualization and containers > * System-specific system hardening > * Case studies > * Security tools > * Security UX > * Emerging technologies, threats & techniques > > Proposals should be submitted via: > https://events.linuxfoundation.org/linux-security-summit-europe/program/cfp/ > > > ** Note that for 2021, the North American and European events are combined into > a single event planned for Dublin, Ireland. ** > > > DATES > > * CFP close: June 27 > * CFP notifications: July 20 > * Schedule announced: July 22 > * Event: September 27-29 > > WHO SHOULD ATTEND > > We're seeking a diverse range of attendees and welcome participation by > people involved in Linux security development, operations, and research. > > LSS is a unique global event that provides the opportunity to present and > discuss your work or research with key Linux security community members and > maintainers. It's also useful for those who wish to keep up with the latest > in Linux security development and to provide input to the development > process. > > WEB SITE > > https://events.linuxfoundation.org/linux-security-summit-europe/ > > TWITTER > > For event updates and announcements, follow: > > https://twitter.com/LinuxSecSummit > > #linuxsecuritysummit > > PROGRAM COMMITTEE > > The program committee for LSS 2021 is: > > * James Morris, Microsoft > * Serge Hallyn, Cisco > * Paul Moore, Cisco > * Stephen Smalley, NSA > * Elena Reshetova, Intel > * John Johansen, Canonical > * Kees Cook, Google > * Casey Schaufler, Intel > * Mimi Zohar, IBM > * David A. Wheeler, Institute for Defense Analyses > > The program committee may be contacted as a group via email: > lss-pc () lists.linuxfoundation.org > > -- James Morris <jm...@na...> |
From: James M. <jm...@na...> - 2021-02-08 20:18:42
|
============================================================================== ANNOUNCEMENT AND CALL FOR PARTICIPATION LINUX SECURITY SUMMIT 2021 27-29 September Dublin, Ireland ============================================================================== DESCRIPTION Linux Security Summit (LSS) is a technical forum for collaboration between Linux developers, researchers, and end-users. Its primary aim is to foster community efforts in analyzing and solving Linux security challenges. The program committee currently seeks proposals for: * Refereed Presentations: 45 minutes in length. * Panel Discussion Topics: 45 minutes in length. * Short Topics: 30 minutes in total, including at least 10 minutes discussion. * Tutorials 90 minutes in length. Tutorial sessions should be focused on advanced Linux security defense topics within areas such as the kernel, compiler, and security-related libraries. Priority will be given to tutorials created for this conference, and those where the presenter a leading subject matter expert on the topic. Topic areas include, but are not limited to: * Kernel self-protection * Access control * Cryptography and key management * Integrity policy and enforcement * Hardware Security * IoT and embedded security * Virtualization and containers * System-specific system hardening * Case studies * Security tools * Security UX * Emerging technologies, threats & techniques Proposals should be submitted via: https://events.linuxfoundation.org/linux-security-summit-europe/program/cfp/ ** Note that for 2021, the North American and European events are combined into a single event planned for Dublin, Ireland. ** DATES * CFP close: June 27 * CFP notifications: July 20 * Schedule announced: July 22 * Event: September 27-29 WHO SHOULD ATTEND We're seeking a diverse range of attendees and welcome participation by people involved in Linux security development, operations, and research. LSS is a unique global event that provides the opportunity to present and discuss your work or research with key Linux security community members and maintainers. It's also useful for those who wish to keep up with the latest in Linux security development and to provide input to the development process. WEB SITE https://events.linuxfoundation.org/linux-security-summit-europe/ TWITTER For event updates and announcements, follow: https://twitter.com/LinuxSecSummit #linuxsecuritysummit PROGRAM COMMITTEE The program committee for LSS 2021 is: * James Morris, Microsoft * Serge Hallyn, Cisco * Paul Moore, Cisco * Stephen Smalley, NSA * Elena Reshetova, Intel * John Johansen, Canonical * Kees Cook, Google * Casey Schaufler, Intel * Mimi Zohar, IBM * David A. Wheeler, Institute for Defense Analyses The program committee may be contacted as a group via email: lss-pc () lists.linuxfoundation.org |
From: James M. <jm...@na...> - 2020-02-04 00:17:31
|
============================================================================== ANNOUNCEMENT AND CALL FOR PARTICIPATION LINUX SECURITY SUMMIT NORTH AMERICA 2020 24-26 JUNE AUSTIN, TEXAS, USA ============================================================================== DESCRIPTION Linux Security Summit North America (LSS-NA) is a technical forum for collaboration between Linux developers, researchers, and end-users. Its primary aim is to foster community efforts in analyzing and solving Linux security challenges. The program committee currently seeks proposals for: * Refereed Presentations: 45 minutes in length. * Panel Discussion Topics: 45 minutes in length. * Short Topics: 30 minutes in total, including at least 10 minutes discussion. * Tutorials 90 minutes in length. Tutorial sessions should be focused on advanced Linux security defense topics within areas such as the kernel, compiler, and security-related libraries. Priority will be given to tutorials created for this conference, and those where the presenter a leading subject matter expert on the topic. Topic areas include, but are not limited to: * Kernel self-protection * Access control * Cryptography and key management * Integrity policy and enforcement * Hardware Security * IoT and embedded security * Virtualization and containers * System-specific system hardening * Case studies * Security tools * Security UX * Emerging technologies, threats & techniques Proposals should be submitted via: https://events.linuxfoundation.org/linux-security-summit-north-america/program/cfp/ DATES * CFP close: March 31 * CFP notifications: April 13 * Schedule announced: April 16 * Event: June 24-26 WHO SHOULD ATTEND We're seeking a diverse range of attendees and welcome participation by people involved in Linux security development, operations, and research. LSS-NA is a unique global event that provides the opportunity to present and discuss your work or research with key Linux security community members and maintainers. It’s also useful for those who wish to keep up with the latest in Linux security development and to provide input to the development process. WEB SITE https://events.linuxfoundation.org/linux-security-summit-north-america/ TWITTER For event updates and announcements, follow: https://twitter.com/LinuxSecSummit #linuxsecuritysummit PROGRAM COMMITTEE The program committee for LSS 2020 is: * James Morris, Microsoft * Serge Hallyn, Cisco * Paul Moore, Cisco * Stephen Smalley, NSA * Elena Reshetova, Intel * John Johansen, Canonical * Kees Cook, Google * Casey Schaufler, Intel * Mimi Zohar, IBM * David A. Wheeler, Institute for Defense Analyses The program committee may be contacted as a group via email: lss-pc () lists.linuxfoundation.org |
From: Jarkko S. <jar...@li...> - 2019-06-24 16:39:04
|
On Thu, 2019-06-20 at 15:00 -0700, Matthew Garrett wrote: > On Thu, Jun 20, 2019 at 2:37 PM Jarkko Sakkinen > <jar...@li...> wrote: > > Right! OK, I squashed just the fix to the earlier patch. Master and > > next are updated. Can you take a peek of [1] and see if it looks > > legit given all the fuzz around these changes? Then I'm confident > > enough to do the 5.3 PR. > > All looks good to me. Thanks! Thank you! I'll send the PR now. /Jarkko |
From: Matthew G. <mj...@go...> - 2019-06-20 22:00:55
|
On Thu, Jun 20, 2019 at 2:37 PM Jarkko Sakkinen <jar...@li...> wrote: > Right! OK, I squashed just the fix to the earlier patch. Master and > next are updated. Can you take a peek of [1] and see if it looks > legit given all the fuzz around these changes? Then I'm confident > enough to do the 5.3 PR. All looks good to me. Thanks! |
From: Jarkko S. <jar...@li...> - 2019-06-20 21:53:29
|
On Wed, Jun 19, 2019 at 03:48:23PM -0700, Matthew Garrett wrote: > On Wed, Jun 19, 2019 at 2:55 AM Ard Biesheuvel > <ard...@li...> wrote: > > > > (+ Jarkko, tpmdd, Matthew) > > > > On Sat, 15 Jun 2019 at 06:02, Hariprasad Kelam > > <har...@gm...> wrote: > > > > > > This patch fixes below warning > > > > > > drivers/firmware/efi/tpm.c:78:38: warning: passing argument 1 of > > > ‘tpm2_calc_event_log_size’ makes pointer from integer without a cast > > > [-Wint-conversion] > > > > > > Signed-off-by: Hariprasad Kelam <har...@gm...> > > > > I think we already have a fix queued for this, no? > > It looks like I fixed this in "Don't duplicate events from the final > event log in the TCG2 log" rather than a separate patch - I'm fine > merging this, based on Jarkko's preferences. Right! OK, I squashed just the fix to the earlier patch. Master and next are updated. Can you take a peek of [1] and see if it looks legit given all the fuzz around these changes? Then I'm confident enough to do the 5.3 PR. [1] git://git.infradead.org/users/jjs/linux-tpmdd.git /Jarkko |
From: Matthew G. <mj...@go...> - 2019-06-19 23:14:52
|
On Wed, Jun 19, 2019 at 2:55 AM Ard Biesheuvel <ard...@li...> wrote: > > (+ Jarkko, tpmdd, Matthew) > > On Sat, 15 Jun 2019 at 06:02, Hariprasad Kelam > <har...@gm...> wrote: > > > > This patch fixes below warning > > > > drivers/firmware/efi/tpm.c:78:38: warning: passing argument 1 of > > ‘tpm2_calc_event_log_size’ makes pointer from integer without a cast > > [-Wint-conversion] > > > > Signed-off-by: Hariprasad Kelam <har...@gm...> > > I think we already have a fix queued for this, no? It looks like I fixed this in "Don't duplicate events from the final event log in the TCG2 log" rather than a separate patch - I'm fine merging this, based on Jarkko's preferences. |
From: Ard B. <ard...@li...> - 2019-06-19 10:18:44
|
(+ Jarkko, tpmdd, Matthew) On Sat, 15 Jun 2019 at 06:02, Hariprasad Kelam <har...@gm...> wrote: > > This patch fixes below warning > > drivers/firmware/efi/tpm.c:78:38: warning: passing argument 1 of > ‘tpm2_calc_event_log_size’ makes pointer from integer without a cast > [-Wint-conversion] > > Signed-off-by: Hariprasad Kelam <har...@gm...> I think we already have a fix queued for this, no? > --- > drivers/firmware/efi/tpm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c > index 74d0cd1..1d3f5ca 100644 > --- a/drivers/firmware/efi/tpm.c > +++ b/drivers/firmware/efi/tpm.c > @@ -75,7 +75,7 @@ int __init efi_tpm_eventlog_init(void) > goto out; > } > > - tbl_size = tpm2_calc_event_log_size(efi.tpm_final_log > + tbl_size = tpm2_calc_event_log_size((void *)efi.tpm_final_log > + sizeof(final_tbl->version) > + sizeof(final_tbl->nr_events), > final_tbl->nr_events, > -- > 2.7.4 > |
From: James M. <jm...@na...> - 2019-04-09 23:10:56
|
============================================================================== ANNOUNCEMENT AND CALL FOR PARTICIPATION LINUX SECURITY SUMMIT NORTH AMERICA 2019 19-21 August SAN DIEGO, CA, USA ============================================================================== DESCRIPTION The Linux Security Summit (LSS) is a technical forum for collaboration between Linux developers, researchers, and end users. Its primary aim is to foster community efforts in analyzing and solving Linux security challenges. LSS will be held this year as two separate events, one in North America (LSS-NA), and one in Europe (LSS-EU), to facilitate broader participation in Linux Security development. Note that this CFP is for LSS-NA; a separate CFP will be announced for LSS-EU in May. We encourage everyone to attend both events. The program committee currently seeks proposals for: * Refereed Presentations: 45 minutes in length. * Panel Discussion Topics: 45 minutes in length. * Short Topics: 30 minutes in total, including at least 10 minutes discussion. * Tutorials (NEW for 2019) 90 minutes in length. * Hackfest Sessions (NEW for 2019) 1/2 day. Note that LSS NA is now a 3-day event. The third day will be a mix of tutorials and hackfest sessions: * Tutorial sessions should be focused on advanced Linux security defense topics within areas such as the kernel, compiler, and security-related libraries. Priority will be given to tutorials created for this conference. * Hackfest proposals should aim to solve, or make significant progress on a well-defined problem in the Linux security defense space, and be supported by multiple community developers. Topic areas include, but are not limited to: * Kernel self-protection * Access control * Cryptography and key management * Integrity policy and enforcement * Hardware Security * IoT and embedded security * Virtualization and containers * System-specific system hardening * Case studies * Security tools * Security UX * Emerging technologies, threats & techniques Proposals should be submitted via: https://events.linuxfoundation.org/events/linux-security-summit-north-america-2019/program/cfp/ DATES * CFP Close: May 31, 2019 * CFP Notifications: June 17, 2019 * Schedule Announced: June 19, 2019 * Event: August 19-21, 2019 WHO SHOULD ATTEND We're seeking a diverse range of attendees, and welcome participation by people involved in Linux security development, operations, and research. The LSS is a unique global event which provides the opportunity to present and discuss your work or research with key Linux security community members and maintainers. It’s also useful for those who wish to keep up with the latest in Linux security development, and to provide input to the development process. WEB SITE https://events.linuxfoundation.org/events/linux-security-summit-north-america-2019/ TWITTER For event updates and announcements, follow: https://twitter.com/LinuxSecSummit PROGRAM COMMITTEE The program committee for LSS 2019 is: * James Morris, Microsoft * Serge Hallyn, Cisco * Paul Moore, Cisco * Stephen Smalley, NSA * Elena Reshetova, Intel * John Johansen, Canonical * Kees Cook, Google * Casey Schaufler, Intel * Mimi Zohar, IBM * David A. Wheeler, Institute for Defense Analyses The program committee may be contacted as a group via email: lss-pc () lists.linuxfoundation.org |
From: Jarkko S. <jar...@li...> - 2018-08-27 08:25:13
|
On Fri, 2018-08-24 at 10:33 +0100, David Howells wrote: > Jarkko Sakkinen <jar...@li...> wrote: > > > I could rebase them and make a patch set out of them when I have time. > > Thanks. I'm not going to do anything further with this until after the merge > window anyway. > > And thanks for taking the time to look through the patches. I just dumped the > entire patchset on you rather than weeding out the duplicate/obsolete patches > as I don't have time just now to port them to linus/master. Are you coming to Edinburgh in late Oct? Could discuss there about TPM and keyring "intersections" (not only this patch set but also trusted keys etc.). > David /Jarkko |
From: Mimi Z. <zo...@li...> - 2018-08-24 11:23:06
|
On Fri, 2018-08-24 at 09:25 +0300, Jarkko Sakkinen wrote: > On Fri, Aug 24, 2018 at 09:24:34AM +0300, Jarkko Sakkinen wrote: > > On Tue, Aug 21, 2018 at 12:30:04PM -0600, Jason Gunthorpe wrote: > > > On Tue, Aug 21, 2018 at 04:56:56PM +0100, David Howells wrote: > > > > Add newly registered TPMs to the tail of the list, not the beginning, so that > > > > things that are specifying TPM_ANY_NUM don't find that the device they're > > > > using has inadvertently changed. Adding a second device would break IMA, for > > > > instance. > > > > > > > > Signed-off-by: David Howells <dho...@re...> > > > > Reviewed-by: Jason Gunthorpe <jgu...@ob...> > > > > Signed-off-by: Peter Huewe <pet...@gm...> > > > > cc: st...@vg... > > > > --- > > > > > > We really should apply this patch... > > > > > > Jason > > > > This is the first time I remember seeing it. > > At least in the sense that I should review it. I remember this patch, because it affected IMA. It has already been upstreamed as 398a1e71dc82. Mimi |
From: David H. <dho...@re...> - 2018-08-24 09:33:20
|
Jarkko Sakkinen <jar...@li...> wrote: > I could rebase them and make a patch set out of them when I have time. Thanks. I'm not going to do anything further with this until after the merge window anyway. And thanks for taking the time to look through the patches. I just dumped the entire patchset on you rather than weeding out the duplicate/obsolete patches as I don't have time just now to port them to linus/master. David |
From: Jarkko S. <jar...@li...> - 2018-08-24 08:49:51
|
On Fri, Aug 24, 2018 at 10:52:27AM +0300, Jarkko Sakkinen wrote: > On Tue, Aug 21, 2018 at 04:57:43PM +0100, David Howells wrote: > > Break the TPM bits out of security/keys/trusted.c into their own call wrapper > > library. > > > > Signed-off-by: David Howells <dho...@re...> > > I think the very first steps that we should take would be to make TPM > subsystem to use struct tpm_buf internally for everything and convert > tpm_send() to take tpm_buf instead of a raw buffer. > > For TPM 2.0 the subsystem already uses tpm_buf. I remember Tomas Winkler > working on to do the same for TPM 1.x. > > After that it would make sense to convert TPM 1.x to use struct tpm_buf to > construct commands. > > After all of this is done it is possible to evaluate these changes. > > BTW right now there is call wrapper interface provided by the TPM > subsystem for TPM 2.0 trusted keys. Not sure if this has been the > right design choice. TPM 1.x and TPM 2.0 trusted keys implementations > live in different subsystems ATM, which at least somewhat wrong. Tomas' patches are scattered here: https://patchwork.kernel.org/patch/10261169/ I could rebase them and make a patch set out of them when I have time. /Jarkko |
From: Jarkko S. <jar...@li...> - 2018-08-24 07:52:38
|
On Tue, Aug 21, 2018 at 04:57:43PM +0100, David Howells wrote: > Break the TPM bits out of security/keys/trusted.c into their own call wrapper > library. > > Signed-off-by: David Howells <dho...@re...> I think the very first steps that we should take would be to make TPM subsystem to use struct tpm_buf internally for everything and convert tpm_send() to take tpm_buf instead of a raw buffer. For TPM 2.0 the subsystem already uses tpm_buf. I remember Tomas Winkler working on to do the same for TPM 1.x. After that it would make sense to convert TPM 1.x to use struct tpm_buf to construct commands. After all of this is done it is possible to evaluate these changes. BTW right now there is call wrapper interface provided by the TPM subsystem for TPM 2.0 trusted keys. Not sure if this has been the right design choice. TPM 1.x and TPM 2.0 trusted keys implementations live in different subsystems ATM, which at least somewhat wrong. /Jarkko |
From: Jarkko S. <jar...@li...> - 2018-08-24 07:42:32
|
On Tue, Aug 21, 2018 at 04:57:22PM +0100, David Howells wrote: > Use struct tpm_chip rather than chip number as interface parameter for most > interface functions. This allows the client to be sure about the consistency > of what device it uses. > > Signed-off-by: David Howells <dho...@re...> > --- > > drivers/char/tpm/tpm-interface.c | 76 ++++++++------------------------- > drivers/char/tpm/tpm-sysfs.c | 2 - > include/linux/tpm.h | 16 ++++--- > security/integrity/ima/ima.h | 2 - > security/integrity/ima/ima_crypto.c | 4 +- > security/integrity/ima/ima_init.c | 19 +++++--- > security/integrity/ima/ima_queue.c | 4 +- > security/keys/trusted.c | 80 ++++++++++++++++++++++------------- > 8 files changed, 96 insertions(+), 107 deletions(-) Should be split at least to three patches and TPM side is already in the upstream. /Jarkko |
From: Jarkko S. <jar...@li...> - 2018-08-24 06:30:28
|
On Tue, Aug 21, 2018 at 04:57:09PM +0100, David Howells wrote: > Provide a platform driver for the user emulator driver. This seems to be > necessary to stop tpm_chip_find_get() from blowing up because it assumes > unconditionally that any device will have a driver attached: > > if (try_module_get(pos->dev->driver->owner)) { > > However, this doesn't then work right because if I remove the TPM device and > re-add it, the tpm ID isn't recycled (ie, /dev/tpm0 becomes unavailable and > the new TPM is /dev/tpm1). > > Signed-off-by: David Howells <dho...@re...> Again, a duplicate. /Jarkko |
From: Jarkko S. <jar...@li...> - 2018-08-24 06:29:26
|
On Tue, Aug 21, 2018 at 12:31:40PM -0600, Jason Gunthorpe wrote: > On Tue, Aug 21, 2018 at 04:57:03PM +0100, David Howells wrote: > > Provide a misc device file (/dev/tpm_emul) by which a userspace TPM emulator > > can set up a virtual TPM device under the control of the TPM frontend. The > > way this works is: > > > > (1) The emulator opens /dev/tpm_emul which is provided by the tpm_user > > driver. > > > > (2) tpm_user registers a TPM device and the tpm driver creates a /dev/tpmN > > misc device for the trousers package and suchlike to access. > > > > (3) The emulator sits in read() on the emulator device waiting for a command > > to come through. > > > > (4) tpm_user passes requests from /dev/tpmN to the emulator's read() call. > > > > (5) The emulator processes the request. > > > > (6) The emulator either write()'s the reply or calls ioctl(fd,0,0) to cancel > > the command. > > > > (7) The emulator goes back to read() to wait for the next command. > > > > (8) tpm_user passes the reply back to the tpm driver which passes it back to > > /dev/tpmN. > > > > When the emulator closes /dev/tpm_emul, the TPM driver is unregistered and the > > /dev/tpmN misc device is then removed. Any outstanding requests are aborted > > and -EIO will be returned from then on. Multiple TPMs can be registered. > > > > Signed-off-by: David Howells <dho...@re...> > > --- > > > > drivers/char/tpm/Kconfig | 13 + > > drivers/char/tpm/Makefile | 1 > > drivers/char/tpm/tpm_user_emul.c | 672 ++++++++++++++++++++++++++++++++++++++ > > include/linux/wait.h | 11 + > > 4 files changed, 697 insertions(+) > > create mode 100644 drivers/char/tpm/tpm_user_emul.c > > This looks to duplicate the vtpm stuff... Yeah, this is a duplicate to tpm_vtpm_proxy. > > Jason /Jarkko |
From: Jarkko S. <jar...@li...> - 2018-08-24 06:26:17
|
On Fri, Aug 24, 2018 at 09:24:34AM +0300, Jarkko Sakkinen wrote: > On Tue, Aug 21, 2018 at 12:30:04PM -0600, Jason Gunthorpe wrote: > > On Tue, Aug 21, 2018 at 04:56:56PM +0100, David Howells wrote: > > > Add newly registered TPMs to the tail of the list, not the beginning, so that > > > things that are specifying TPM_ANY_NUM don't find that the device they're > > > using has inadvertently changed. Adding a second device would break IMA, for > > > instance. > > > > > > Signed-off-by: David Howells <dho...@re...> > > > Reviewed-by: Jason Gunthorpe <jgu...@ob...> > > > Signed-off-by: Peter Huewe <pet...@gm...> > > > cc: st...@vg... > > > --- > > > > We really should apply this patch... > > > > Jason > > This is the first time I remember seeing it. At least in the sense that I should review it. /Jarkkko |
From: Jarkko S. <jar...@li...> - 2018-08-24 06:25:06
|
On Tue, Aug 21, 2018 at 12:30:04PM -0600, Jason Gunthorpe wrote: > On Tue, Aug 21, 2018 at 04:56:56PM +0100, David Howells wrote: > > Add newly registered TPMs to the tail of the list, not the beginning, so that > > things that are specifying TPM_ANY_NUM don't find that the device they're > > using has inadvertently changed. Adding a second device would break IMA, for > > instance. > > > > Signed-off-by: David Howells <dho...@re...> > > Reviewed-by: Jason Gunthorpe <jgu...@ob...> > > Signed-off-by: Peter Huewe <pet...@gm...> > > cc: st...@vg... > > --- > > We really should apply this patch... > > Jason This is the first time I remember seeing it. /Jarkko |
From: Jarkko S. <jar...@li...> - 2018-08-24 06:24:23
|
Use "tpm" instead of "TPM" in the short summary. On Tue, Aug 21, 2018 at 04:56:56PM +0100, David Howells wrote: > Add newly registered TPMs to the tail of the list, not the beginning, so that > things that are specifying TPM_ANY_NUM don't find that the device they're > using has inadvertently changed. Adding a second device would break IMA, for > instance. > > Signed-off-by: David Howells <dho...@re...> > Reviewed-by: Jason Gunthorpe <jgu...@ob...> > Signed-off-by: Peter Huewe <pet...@gm...> > cc: st...@vg... Usually I add Cc-tag before signed-off-by's (and have the first c in upper case). Peter's singed-off-by should be accompanied with a co-developed-by tag if he has participated to the development of this commit. As far as I see signed-off-by without co-developed-by makes sense in two occasions: * You own the subsystem tree i.e. you have to sign the changes that you include part of your pull request. * You are the initial authoer of the change. > --- > > drivers/char/tpm/tpm-interface.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c > index 6af17002a115..cfb9089887bd 100644 > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -1122,7 +1122,7 @@ struct tpm_chip *tpm_register_hardware(struct device *dev, > > /* Make chip available */ > spin_lock(&driver_lock); > - list_add_rcu(&chip->list, &tpm_chip_list); I would add here a comment just as a remainder. > + list_add_tail_rcu(&chip->list, &tpm_chip_list); > spin_unlock(&driver_lock); > > return chip; /Jarkko |