diff --git a/.markdownlint.yaml b/.markdownlint.yaml
index 26cdfaa..bf409f2 100644
--- a/.markdownlint.yaml
+++ b/.markdownlint.yaml
@@ -130,7 +130,7 @@ MD030:
# MD033/no-inline-html - Inline HTML
MD033:
# Allowed elements
- allowed_elements: ["br", "center", "img", "script", "form", "input", "a"]
+ allowed_elements: ["br", "center", "img", "script", "form", "input", "a", "div", "center","small"]
# MD034/no-bare-urls - Bare URL used
MD034: false
diff --git a/2024/QubesOSsummit/enhancing-os-awareness-of-hardware-security-capabilities.md b/2024/QubesOSsummit/enhancing-os-awareness-of-hardware-security-capabilities.md
new file mode 100644
index 0000000..39cd32b
--- /dev/null
+++ b/2024/QubesOSsummit/enhancing-os-awareness-of-hardware-security-capabilities.md
@@ -0,0 +1,77 @@
+---
+layout: cover
+background: /intro.png
+class: text-center
+routeAlias: assessment
+
+---
+
+## Enhancing OS Awareness of Hardware Security Capabilities in Qubes OS
+
+### Piotr Król
+
+---
+
+
+
+* Lack of OS awareness about hardware security capabilities leads to the
+inability to evaluate and improve system security posture.
+* Over the last two years, we have seen number of various communities
+approaching this topic.
+ - GNOME introduced the Device Security Settings page (based on [LVFS HSI](https://fwupd.github.io/libfwupdplugin/hsi.html)).
+ - KDE Plasma added Firmware Security page (based on [LVFS HSI](https://fwupd.github.io/libfwupdplugin/hsi.html)).
+ - Qubes OS Security Report (based on Qubes HCL).
+ - FSF RYF Certification (unclear rules).
+
+
+---
+clicks: 4
+---
+
+
+## Assessment
+
+* Some interfaces for CPU assessment already exist. We have tools like:
+ - `lscpu`, which shows `/sys/devices/system/cpu/vulnerabilities`.
+ - `/proc/cpuinfo` bugs.
+* We could only secure our ecosystem if we knew what security mechanisms are
+available on a given piece of hardware.
+* Shipping hardware with Linux would be more challenging without exposing the
+interface, which will help assess security configuration and help protect
+against misconfiguration of security features.
+* Achieving results requires broader cooperation between communities and vendors.
+* Followed presentations and communities discussed this topic:
+ - [Embedded Recipes: LVFS: The next 50 million firmware updates](https://embedded-recipes.org/2022/wp-content/uploads/2022/06/LVFS-ER-avec-compression.pdf).
+ - [TrenchBoot Summit: LVFS Host Security ID (HSI) and Silicon-Based Core Security](https://www.youtube.com/live/xZoCtNV8Qs0).
+ - Arm SystemArchAC Security Sub-team.
+
+
+
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+---
+
+
+# Discussion
diff --git a/2024/QubesOSsummit/implementing-uefi-secure-boot-in-qubes-os.md b/2024/QubesOSsummit/implementing-uefi-secure-boot-in-qubes-os.md
new file mode 100644
index 0000000..e4bffc1
--- /dev/null
+++ b/2024/QubesOSsummit/implementing-uefi-secure-boot-in-qubes-os.md
@@ -0,0 +1,525 @@
+---
+layout: cover
+background: /intro.png
+class: text-center
+routeAlias: implementing-uefi
+
+---
+
+## Implementing UEFI Secure Boot in Qubes OS
+
+### Challenges and Future Steps
+
+
+
+## Piotr Król
+
+
+---
+
+# Kudos
+
+* Kamil Aronowski
+* Marek Marczykowski-Górecki
+* Andrew Cooper
+
+---
+
+# Goals
+
+* Briefly explain what is UEFI Secure Boot and what led to OSS dislike of it.
+* Justify that only valid way of use of UEFI Secure Boot was defined by Trammel Hudson
+in [safeboot project](https://safeboot.dev/).
+ - Anything else are just excuses, which waste resources.
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+
+
+---
+transition: fade
+
+---
+
+
+
+
+
+---
+
+```c {*}{maxHeight:'100px'}
+ switch (GetImageType (File)) {
+ case IMAGE_FROM_FV:
+ Policy = ALWAYS_EXECUTE;
+ break;
+
+ case IMAGE_FROM_OPTION_ROM:
+ Policy = PcdGet32 (PcdOptionRomImageVerificationPolicy);
+ break;
+
+ case IMAGE_FROM_REMOVABLE_MEDIA:
+ Policy = PcdGet32 (PcdRemovableMediaImageVerificationPolicy);
+ break;
+
+ case IMAGE_FROM_FIXED_MEDIA:
+ Policy = PcdGet32 (PcdFixedMediaImageVerificationPolicy);
+ break;
+
+ default:
+ Policy = DENY_EXECUTE_ON_SECURITY_VIOLATION;
+ break;
+ }
+```
+
+Policies:
+`ALWAYS_EXECUTE`,`NEVER_EXECUTE`,`ALLOW_EXECUTE_ON_SECURITY_VIOLATION`,`DEFER_EXECUTE_ON_SECURITY_VIOLATION`,`DENY_EXECUTE_ON_SECURITY_VIOLATION`,
+`QUERY_USER_EXECUTE_ON_SECURITY_VIOLATION`.
+
+
+
+---
+
+# UEFI Secure Boot
+
+UEFI Secure Boot has emerged as a critical feature to protect systems against
+persistent firmware attacks and unauthorized code execution. While Qubes OS is
+renowned for its security-centric approach, the official support for UEFI
+Secure Boot remains a significant milestone yet to be fully realized.
+
+UEFI Secure Boot is really Chain of Trust technology, which covers very
+specific part of x86 UEFI compliant boot process.
+
+By default it covers only transition between UEFI BIOS and OS Loader/OS Kernel.
+Verification of components coming from Firmware Volume, OptionROMs, drivers
+from external media or internally connected are verified only if correct policy
+is set by UEFI BIOS vendor.
+
+
+
+---
+
+
+
+
+
+---
+
+# UEFI Secure Boot and Linux
+
+* Microsoft became a holder of of keys for UEFI CA
+ - nobody else had infrastructure (Microsoft already signed OS drivers),
+ - nobody else had/wanted to put resources in the process,
+* Microsoft to provide certification mandates among OEM inclusion of one their
+certificates in KEK database and two in DB (MSFT PCA, UEFI CA).
+* UEFI CA is the certificate which signs non-Microsoft software.
+
+
+
+---
+
+# UEFI Secure Boot has bad press
+
+* [PKfail (CVE-2024-8105)](https://www.cve.org/CVERecord?id=CVE-2024-8105)
+ - Use of insecure PK generated by AMI for reference implementation needs
+* [UEFI Shell considered harmful (CVE-2024-7756)](https://www.cve.org/CVERecord?id=CVE-2024-7756)
+ - If UEFI BIOS has UEFI Shell and attacker would be able to trigger it, then it
+ can be leveraged for UEFI Secure Boot bypass thanks to `mm` tool (CWE-489:
+ Active Debug Code).
+* [BootHole](https://eclypsium.com/blog/theres-a-hole-in-the-boot/)
+ - Multiple vulnerabilities in GRUB2 allowing to bypass UEFI Secure Boot.
+ - Lack of revocation in shim lead to escalation of revocation to certificate
+ from Microsoft to prevent shims that allow running vulnerable GRUB2.
+* [Black Lotus](https://github.com/Wack0/CVE-2022-21894)
+ - Bootkit using CVE-2022-21894 ("Baton Drop") to bypass UEFI Secure Boot.
+ - > Windows Boot Applications allow the `truncatememory` setting to remove
+ > blocks of memory containing "persistent" ranges of serialised data from the
+ > memory map, leading to Secure Boot bypass.
+
+
+
+---
+
+# The cure happen to be worse than the disease
+
+* Microsoft effort for maintaining security properties of UEFI Secure Boot on
+ certified hardware lead to requirements, which leads to many issues in OSS
+ ecosystem. If it all was not bad design from the beginning.
+ - [SBAT](https://github.com/rhboot/shim/blob/main/SBAT.md) (_Secure Boot
+ Advanced Targeting_) was created to create revocation mechanism in shim,
+ - All processes around signing are very bureaucratic.
+ - shim community put together dedicated [review
+ repo](https://github.com/rhboot/shim-review) and guidelines to simplify process
+ of OSS community.
+* Need for complex and non-standardized integration with HSMs.
+* But we can see almost no one attack UEFI Secure Boot mechanism, not even
+ implementation, but rather configuration or already authorized code.
+ - Maybe we will get there.
+
+
+
+---
+
+# UEFI Secure Boot and Qubes OS
+
+* Those are requirements for being signed by Microsoft, not for UEFI Secure
+Boot a la'safeboot.
+* First production-related
+ [question](https://groups.google.com/g/qubes-users/c/vrzdJmPNzrE/m/MC4l9QTJBAAJ)
+ coming from Wim Vervoorn (Eltan), Aug 2017.
+* Effort started to be tracked in
+ [#4371](https://github.com/QubesOS/qubes-issues/issues/4371) since Oct 2018.
+* Trammell reported booting Qubes OS 4.1 with secure boot enable leveraginging
+ unified `xen.efi` in Aug, 2020.
+ - initial concerns: xen.efi reliability while loading other boot files,
+ complexity of boot parameters modification
+* Effort for signing boot images was requested by Marek in May 2023 in
+ [#8206](https://github.com/QubesOS/qubes-issues/issues/8206).
+* Qubes OS Summit 2023 we discussed inclusion of Qubes OS CA in Dasharo firmware.
+* Frederic works on improving Qubes Builder v2 to include `pesign` for signing
+ needs [PR #77](https://github.com/QubesOS/qubes-builderv2/pull/77).
+* There is no easy way to use current installer (R4.2.3) and modify it for UEFI
+ Secure Boot enabled booting.
+* Current approach is to build unified `xen.efi` and sign it. Pre-built
+ `xen.efi` binaries will be provided in R4.3.
+
+
+
+---
+
+# UEFI Secure Boot and Xen
+
+* There is a lot in this can of worms.
+* From discussion with Andrew:
+ - Xen needs support for SBAT, which is not present yet.
+ - NX_COMPAT is required for SBAT support.
+ - kexec have to leverage SHA256 for checking integrity of executed images.
+ - kexec purgatory code should be built-in Xen.
+ - Livepatching have to check patches signatures.
+ - Command line have to be correctly handled (some options may be not safe).
+ - New hypercalls ABI for checking all passed pointers.
+ - Some debug options should have ability to be disabled at compilations time:
+ GDB stub.
+* In summary "unsigned code can't make any unaudited reads/writes".
+* Not everything affect Qubes OS.
+ - But ensuring Linux kernel lockdown mode is forced will belong to this tasks.
+
+
+
+---
+
+# What we can do right now?
+
+* Choose hardware which has better UEFI Secure Boot Support
+ - HP and some ACER BIOS implement ability to trust given file for execution,
+ - not ideal but could be improved, especially by Dasharo Team, of course if
+ there is consensus about security of such solution with Qubes OS Team,
+* Wait for R4.3.
+* Compile unified kernel yourself and try safeboot-like approach - this is what
+ we will try.
+* Disable UEFI Secure Boot
+
+---
+
+# It would not be end
+
+* What are the capabilities which my system support?
+* UEFI specificaition not defines what is supported,
+* every implementation may do things little bit different,
+* how to test that?
+ - try
+ - trust spec version compliance, which say something but not everything,
+
+---
+
+# Hackathon Challenge
+
+* Build unified xen.efi using qubes-builderv2
+ - fix documentation?
+* Test in OVMF
+
+
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+
+---
+
+# Q&A
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+
+---
+
+# Backup
+
+---
+
+# What could be done differently?
+
+* Improve reference UEFI BIOS implementation to make dealing with UEFI Secure
+ Boot manageable by mare mortals.
+* Provide system level tooling as part of OS installation process.
+ - Many distro doing that since those cannot afford fulfilling requirements
+ for review process.
diff --git a/2024/QubesOSsummit/qubes-os-summit-2024-day-1-closing-notes.md b/2024/QubesOSsummit/qubes-os-summit-2024-day-1-closing-notes.md
new file mode 100644
index 0000000..f8d37b1
--- /dev/null
+++ b/2024/QubesOSsummit/qubes-os-summit-2024-day-1-closing-notes.md
@@ -0,0 +1,74 @@
+---
+layout: cover
+background: /intro.png
+class: text-center
+routeAlias: closing-day-1
+
+---
+## Qubes OS Summit 2024 Day 1: Closing Notes
+
+### Piotr Król
+
+---
+
+# Platinum Sponsors
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+
+
+
+
+
+
+---
+
+
+
+
+
+
+
+Photo by Maciej Klimiuk
+
+
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+---
+
+
+# Thank you
+
+## We start tomorrow at 10AM
diff --git a/2024/QubesOSsummit/qubes-os-summit-2024-day-2-closing-notes.md b/2024/QubesOSsummit/qubes-os-summit-2024-day-2-closing-notes.md
new file mode 100644
index 0000000..a4b44f5
--- /dev/null
+++ b/2024/QubesOSsummit/qubes-os-summit-2024-day-2-closing-notes.md
@@ -0,0 +1,74 @@
+---
+layout: cover
+background: /intro.png
+class: text-center
+routeAlias: closing-day-2
+
+---
+## Qubes OS Summit 2024 Day 2: Closing Notes
+
+### Piotr Król
+
+---
+
+# Platinum Sponsors
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+
+
+
+
+
+
+---
+
+
+
+
+
+
+
+Photo by Maciej Klimiuk
+
+
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+---
+
+
+# Thank you and see you next year
+
+## (or on tomorrows hackathon)
diff --git a/2024/QubesOSsummit/welcome-to-qubes-os-summit-2024-day-1.md b/2024/QubesOSsummit/welcome-to-qubes-os-summit-2024-day-1.md
new file mode 100644
index 0000000..7f5a3ef
--- /dev/null
+++ b/2024/QubesOSsummit/welcome-to-qubes-os-summit-2024-day-1.md
@@ -0,0 +1,370 @@
+---
+layout: cover
+background: /intro.png
+class: text-center
+routeAlias: welcome-day-1
+
+---
+## Welcome to Qubes OS Summit 2024 Day 1
+
+### Piotr Król and Marek Marczykowski-Górecki
+
+
+---
+layout: cover
+background: /2024/QubesOSsummit/qoss_welcome.png
+---
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+---
+
+
+# Platinum Sponsors
+
+---
+
+
+
+
+
+---
+
+# Supporting Contributor
+
+* ## StarApps Ltd
+
+We are grateful for the support from StarApps Ltd., company which use and rely
+on Qubes OS and support FOSS philosophy.
+
+---
+
+
+
+
+
+
+
+
+
+
+
+
+
+---
+
+# Accomplishments - 2023-2024
+
+* Recap of vision and challenges presented last year.
+* We added 50% to Qubes OS Certified Hardware (from 6 to 9)
+ - although we have to admit that some old certified hardware is no longer
+available,
+* Qubes HCL statistics: 1055 (+61)
+* Released Qubes OS 4.2 and three subsequent point releases
+* Greatly improved updates experience
+* Several UX improvements and new GUI tools - including new Qubes Global
+ Config, more to come
+* fwupd integration installed by default
+* Community projects:
+ - Automated configurability extended thanks to community contribution from Ben
+ Grande in form of [qusal](https://github.com/ben-grande/qusal) based on
+ previous unman work.
+
+
+---
+
+# Accomplishments - 2023-2024
+
+* Event organization improved:
+ - A lot external talks in CfP, we had to reject some.
+* Coming soon:
+ - UEFI Secure Boot integration - more about that in tomorrow's talk.
+ + TL;DR we are not there yet, but we are close. safeboot approach is still
+ alive.
+ - TrenchBoot AEM - we have some exciting news and demo for you.
+ - Certified Hardware with Intel Boot Guard and UEFI Capsule Update coming in
+ following months.
+ - As mentioned last year SMI Transfer Monitor was integrated for Qubes OS
+ Certified Hardware MSI PRO Z690-A by Brian Delgado.
+ + code is PoC, but it was presented at [vPub 0xB](https://youtu.be/3PmOcjQX-9Y)
+ + the challenge would be to make Xen and dom0 aware of that,
+
+
+---
+transition: fade
+---
+
+
+# Accomplishments - 2022-2023
+
+
+
+---
+
+# Accomplishments - 2023-2024
+
+
+
+---
+
+
+
+
+
+
+
+
+
+---
+
+# Vision and challenges - 2024-2025
+
+* Continue growth of number of Qubes OS Certified Hardware
+ - Dell OptiPlex 7010/9010 with AEM
+ - Odroid H4?
+ - Novacustom Laptops
+* Finalize Qubes AEM support for Intel
+ - Legacy BIOS (through SeaBIOS) is close to be completed.
+ - UEFI is planned and founded.
+* Finalize Qubes AEM for AMD
+ - Waiting for release of documentation by AMD
+ - If it would not happen early we have to rely on existing documentation and
+ will adjust after that.
+* UEFI Secure Boot have to become first-class citizen in Qubes OS.
+* Qubes Security Report - road to OSS security leadership.
+* More in Marek's talk dedicated to Qubes OS Project plans.
+
+
+
+---
+
+# What is our lineup this year?
+
+
+
+* ## September 20th: Conference Day 1 and Afterparty
+
+
+
+* ## September 21th: Conference Day 2
+
+
+
+* ## September 22th: Hackathon
+
+
+
+---
+
+# Day 1 agenda
+
+### 10:00-10:25
+
+#### **_Welcome to Qubes OS Summit 2024 Day 1_** - Piotr (3mdeb), Marek (ITL)
+
+### 10:30-11:00
+
+#### **_Qubes OS development status update_** - Marek (ITL)
+
+### 11:10-11:30
+
+#### **_Qubes OS GUI Changes and Future Perspectives_** - Marta (ITL)
+
+### 11:40-12:10
+
+#### **_Enhancing OS Awareness of Hardware Security Capabilities in Qubes OS_** - Piotr (3mdeb)
+
+### 12:15-13:00
+
+#### **_Passwordless encrypted Qubes? Exploring some concepts_** - nestire (Nitrokey)
+
+### 13:00-14:30
+
+#### **_Lunch_**
+
+---
+
+# Day 1 agenda
+
+### 14:30-15:00
+
+#### **_How to architect your Qubes OS with SaltStack_** - Ben (FOSS Maintainer)
+
+### 15:10-15:40
+
+#### **_FlashKeeper: where SpiSpy meets Stateless Laptop jaded dreams: A retrofit plan first_** - Thierry (Heads Maintainer)
+
+### 15:50-16:20
+
+#### **_Anti Evil Maid status and future plans_** - Michał (3mdeb)
+
+### 16:30-17:00
+
+#### **_Rolling out Qubes_** - unman (Qubes OS Maintainer)
+
+### 17:10-17:40
+
+#### **_Update on Qubes Air_** - Marek&Frédéric (ITL/Qubes Team)
+
+### 17:50-18:00
+
+#### **_Closing Notes_** - Piotr (3mdeb)
+
+### 19:30+
+
+#### **_Afterparty_**
+
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+---
+
+## Details on
+
+### https://cfp.3mdeb.com/qubes-os-summit-2024/
+
+### https://vpub.dasharo.com/e/16/qubes-os-summit-2024#schedule
+
+---
+
+
+
+
+
+
+ Photo by Maciej Klimiuk
+
+
+---
+
+
+
+
+
+https://vpub.dasharo.com
+
+
+
+* Respect Code of Conduct.
+* Please follow Safety and Health protocols and respect others.
+* Talks are streamed and recorded and will be published on Youtube.
+* Drinks and sweets are free.
+* Matrix `#qubes-summit:matrix.org` will be used for communication during event.
+* In case of any issues please contact with organizers.
+
+---
+
+# Merchandise
+
+
+
+
+
+
+* Paid and free merchandise available (at location and in 3mdeb Shop).
+* There are also partners selling their merchandise.
+
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+---
+
+
+# Q&A
diff --git a/2024/QubesOSsummit/welcome-to-qubes-os-summit-2024-day-2.md b/2024/QubesOSsummit/welcome-to-qubes-os-summit-2024-day-2.md
new file mode 100644
index 0000000..5a1723e
--- /dev/null
+++ b/2024/QubesOSsummit/welcome-to-qubes-os-summit-2024-day-2.md
@@ -0,0 +1,158 @@
+---
+layout: cover
+background: /intro.png
+class: text-center
+routeAlias: welcome-day-2
+
+---
+## Welcome to Qubes OS Summit 2024 Day 2
+
+### Piotr Król and Marek Marczykowski Górecki
+
+
+---
+layout: cover
+background: /2024/QubesOSsummit/qoss_welcome.png
+---
+
+---
+layout: cover
+background: /intro.png
+class: text-center
+---
+
+
+# Platinum Sponsors
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+---
+transition: fade
+
+---
+
+
+
+
+
+---
+transition: fade
+
+---
+
+
+
+
+
+---
+
+```c {*}{maxHeight:'100px'}
+ switch (GetImageType (File)) {
+ case IMAGE_FROM_FV:
+ Policy = ALWAYS_EXECUTE;
+ break;
+
+ case IMAGE_FROM_OPTION_ROM:
+ Policy = PcdGet32 (PcdOptionRomImageVerificationPolicy);
+ break;
+
+ case IMAGE_FROM_REMOVABLE_MEDIA:
+ Policy = PcdGet32 (PcdRemovableMediaImageVerificationPolicy);
+ break;
+
+ case IMAGE_FROM_FIXED_MEDIA:
+ Policy = PcdGet32 (PcdFixedMediaImageVerificationPolicy);
+ break;
+
+ default:
+ Policy = DENY_EXECUTE_ON_SECURITY_VIOLATION;
+ break;
+ }
+```
+
+Policies:
+`ALWAYS_EXECUTE`,`NEVER_EXECUTE`,`ALLOW_EXECUTE_ON_SECURITY_VIOLATION`,`DEFER_EXECUTE_ON_SECURITY_VIOLATION`,`DENY_EXECUTE_ON_SECURITY_VIOLATION`,
+`QUERY_USER_EXECUTE_ON_SECURITY_VIOLATION`.
+
+
+
+---
+
+# UEFI Secure Boot
+
+UEFI Secure Boot has emerged as a critical feature to protect systems against
+persistent firmware attacks and unauthorized code execution. While Qubes OS is
+renowned for its security-centric approach, the official support for UEFI
+Secure Boot remains a significant milestone yet to be fully realized.
+
+UEFI Secure Boot is really Chain of Trust technology, which covers very
+specific part of x86 UEFI compliant boot process.
+
+By default it covers only transition between UEFI BIOS and OS Loader/OS Kernel.
+Verification of components coming from Firmware Volume, OptionROMs, drivers
+from external media or internally connected are verified only if correct policy
+is set by UEFI BIOS vendor.
+
+
+
+---
+
+
+ 
+
+ 
+
+
+
+ 
+ 
+ 
+ 
+
+ 
+ 
+
+ 
+