Implement a CLI tool for Trento - trentoctl by nkopliku

Description

Implement a trentoctl CLI for interacting with a trento installation

Goals

• learn rust
• implement an initial trentoctl tool to enhance trento automation
• have fun

Resources

trento rust. TUIs listed on this other hackweek project Hack on rich terminal user interfaces

---

Write an url shortener in Rust (And learn in the way) by szarate

So I have 469.icu :), it's currently doing nothing... (and for sale) but in the meantime, I'd like to write an url shortener from scratch and deploy it on my own server

https://github.com/foursixnine/url-manager-rs/tree/main

---

Grapesss: a physical Shamir's Secret Sharing application [ESP32-C3 + Mobile] by ecandino

Description

A couple of years ago I created StegoSecretS, a small cli used to encrypt and split a secret into multiple keys, using the Shamir's Secret Sharing algorithm.

The idea is to re-implement the project using physical devices. One device alone will be useless, but when close together they can be used to decrypt the secret.

On a practical side the user encrypts the secret with a mobile application. The same application is used to split the secret, and load the partial keys into different micro-controllers. Another user will be able to decrypt the secret only having at least N devices close together (using the application).

I'm planning to use a couple of ESP32-C3 I bought, and build a very simple Android mobile application.

Goals

• Learn about Rust and micro-controllers (ESP32-C3)
• Learn about mobile applications (Android and Kotlin)

Resources

• Shamir's Secret Sharing
• The esp-rs Book
• Android - Kotlin

---

SMB3 Server written entirely in Rust by dmulder

Description

Given the number of bugs frequently discovered in the Samba code caused by memory issues, it makes sense to re-write the smbd service purely in Rust code. Meanwhile, it would be wise to abandon backwards compatibility here with insecure protocol versions, and simply implement the SMB3 spec.

Goals

Get a simple server up and running and get it merged into upstream Samba (which now has Rust build support).

Resources

---

Agama installer on-line demo by lslezak

Description

The Agama installer provides a quite complex user interface. We have some screenshots on the web page but as it is basically a web application it would be nice to have some on-line demo where users could click and check it live.

The problem is that the Agama server directly accesses the hardware (storage probing) and loads installation repositories. We cannot easily mock this in the on-line demo so the easiest way is to have just a read-only demo. You could explore the configuration options but you could not change anything, all changes would be ignored.

The read-only demo would be a bit limited but I still think it would be useful for potential users get the feeling of the new Agama installer and get familiar with it before using in a real installation.

As a proof of concept I already created this on-line demo.

The implementation basically builds Agama in two modes - recording mode where it saves all REST API responses and replay mode where it for the REST API requests returns the previously recorded responses. Recording in the browser is inconvenient and error prone, there should be some scripting instead (see below).

Goals

• Create an Agama on-line demo which can be easily tested by users
• The Agama installer is still in alpha phase and in active development, the online demo needs to be easily rebuilt with the latest Agama version
• Ideally there should be some automation so the demo page is rebuilt automatically without any developer interactions (once a day or week?)

TODO

• Use OpenAPI to get all Agama REST API endpoints, write a script which queries all the endpoints automatically and saves the collected data to a file (see this related PR).
• Write a script for starting an Agama VM (use libvirt/qemu?), the script should ensure we always use the same virtual HW so if we need to dump the latest REST API state we get the same (or very similar data). This should ensure the demo page does not change much regarding the storage proposal etc...
• Fix changing the product, currently it gets stuck after clicking the "Select" button.
• Move the mocking data (the recorded REST API responses) outside the Agama sources, it's too big and will be probably often updated. To avoid messing the history keep it in a separate GitHub repository
• Allow changing the UI language
• Display some note (watermark) in the page so it is clear it is a read-only demo (probably with some version or build date to know how old it is)
• Automation for building new demo page from the latest sources. There should be some check which ensures the recorded data still matches the OpenAPI specification.

Changing the UI language

This will be quite tricky because selecting the proper translation file is done on the server side. We would probably need to completely re-implement the logic in the browser side and adapt the server for that.

Also some REST API responses contain translated texts (storage proposal, pattern names in software). We would need to query the respective endpoints in all supported languages and return the correct response in runtime according to the currently selected language.

Resources

• Agama sources
• Experimental proof of concept demo
• The respective source code change

---

toptop - a top clone written in Go by dshah

Description

toptop is a clone of Linux's top CLI tool, but written in Go.

Goals

Learn more about Go (mainly bubbletea) and Linux

Resources

GitHub

---

VulnHeap by r1chard-lyu

Description

The VulnHeap project is dedicated to the in-depth analysis and exploitation of vulnerabilities within heap memory management. It focuses on understanding the intricate workflow of heap allocation, chunk structures, and bin management, which are essential to identifying and mitigating security risks.

Goals

• Familiarize with heap
  • Heap workflow
  • Chunk and bin structure
  • Vulnerabilities
• Vulnerability
  • Use after free (UAF)
  • Heap overflow
  • Double free
• Use Docker to create a vulnerable environment and apply techniques to exploit it

Resources

• https://heap-exploitation.dhavalkapil.com/divingintoglibc_heap
• https://raw.githubusercontent.com/cloudburst/libheap/master/heap.png
• https://github.com/shellphish/how2heap?tab=readme-ov-file

---

Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.

To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
3. Package management (install, remove, update...)
4. Patching
5. Applying any basic salt state (including a formula)
6. Salt remote commands
7. Bonus point: Java part for product identification, and monitoring enablement
8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

• If you don't have knowledge about some of the steps: ask the team
• If you still don't know what to do: switch to another distribution and keep testing.

This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

Pending

FUSS

FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.

https://fuss.bz.it/

Seems to be a Debian 12 derivative, so adding it could be quite easy.

• [ ] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
• [ ] Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
• [ ] Package management (install, remove, update...)
• [ ] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already)
• [ ] Applying any basic salt state (including a formula)
• [ ] Salt remote commands
• [ ] Bonus point: Java part for product identification, and monitoring enablement

---

Explore simple and distro indipendent declarative Linux starting on Tumbleweed or Arch Linux by janvhs

Description

Inspired by mkosi the idea is to experiment with a declarative approach of defining Linux systems. A lot of tools already make it possible to manage the systems infrastructure by using description files, rather than manual invocation. An example for this are systemd presets for managing enabled services or the /etc/fstab file for describing how partitions should be mounted.

If we would take inspiration from openSUSE MicroOS and their handling of the /etc/ directory, we could theoretically use systemd-sysupdate to swap out the /usr/ partition and create an A/B boot scheme, where the /usr/ partition is always freshly built according to a central system description. In the best case it would be possible to still utilise snapshots, but an A/B root scheme would be sufficient for the beginning. This way you could get the benefit of NixOS's declarative system definition, but still use the distros package repositories and don't have to deal with the overhead of Flakes or the Nix language.

Goals

• A simple and understandable system
• Check fitness of mkosi or write a simple extensible image builder tool for it
• Create a declarative system specification
• Create a system with swappable /usr/ partition
• Create an A/B root scheme
• Swap to the new system without reboot (kexec?)

Resources

• Ideas that have been floating around in my head for a while
• https://0pointer.net/blog/fitting-everything-together.html
• GNOME OS
• MicroOS
• systemd mkosi
• Vanilla OS

---

Contributing to Linux Kernel security by pperego

Description

A couple of weeks ago, I found this blog post by Gustavo Silva, a Linux Kernel contributor.

I always strived to start again into hacking the Linux Kernel, so I asked Coverity scan dashboard access and I want to contribute to Linux Kernel by fixing some minor issues.

I want also to create a Linux Kernel fuzzing lab using qemu and syzkaller

Goals

1. Fix at least 2 security bugs
2. Create the fuzzing lab and having it running

Resources

The dashboard

The serie of blog posts by Gustavo Silva inspiring this project.

An email with some quick "where to start" instructions The patchset philosophy

---

Modernize ocfs2 by goldwynr

Ocfs2 has gone into a stage of neglect and disrepair. Modernize the code to generate enough interest.

Goals: * Change the mount sequence to use fscontext * Move from using bufferhead to bio/folios * Use iomap * Run it through xfstests

---

Improve various phones kernel mainline support (Qualcomm, Exynos, MediaTek) by pvorel

Similar to previous hackweeks ( https://hackweek.opensuse.org/projects/improve-qualcomm-soc-msm8994-slash-msm8992-kernel-mainline-support, https://hackweek.opensuse.org/projects/test-mainline-kernel-on-an-older-qualcomm-soc-msm89xx-explore-mainline-kernel-qualcomm-mainlining) try to improve kernel mainline support of various phones.

---

Improve UML page fault handler by ptesarik

Description

Improve UML handling of segmentation faults in kernel mode. Although such page faults are generally caused by a kernel bug, it is annoying if they cause an infinite loop, or panic the kernel. More importantly, a robust implementation allows to write KUnit tests for various guard pages, preventing potential kernel self-protection regressions.

Goals

Convert the UML page fault handler to use oops_* helpers, go through a few review rounds and finally get my patch series merged in 6.14.

Resources

Wrong initial attempt: https://lore.kernel.org/lkml/20231215121431.680-1-petrtesarik@huaweicloud.com/T/

---

early stage kdump support by mbrugger

Project Description

When we experience a early boot crash, we are not able to analyze the kernel dump, as user-space wasn't able to load the crash system. The idea is to make the crash system compiled into the host kernel (think of initramfs) so that we can create a kernel dump really early in the boot process.

Goal for the Hackweeks

1. Investigate if this is possible and the implications it would have (done in HW21)
2. Hack up a PoC (done in HW22 and HW23)
3. Prepare RFC series (giving it's only one week, we are entering wishful thinking territory here).

update HW23

• I was able to include the crash kernel into the kernel Image.
• I'll need to find a way to load that from init/main.c:start_kernel() probably after kcsan_init()
• I workaround for a smoke test was to hack kexec_file_load() systemcall which has two problems:
  1. My initramfs in the porduction kernel does not have a new enough kexec version, that's not a blocker but where the week ended
  2. As the crash kernel is part of init.data it will be already stale once I can call kexec_file_load() from user-space.

The solution is probably to rewrite the POC so that the invocation can be done from init.text (that's my theory) but I'm not sure if I can reuse the kexec infrastructure in the kernel from there, which I rely on heavily.

update HW24

• Day1
  • rebased on v6.12 with no problems others then me breaking the config
  • setting up a new compilation and qemu/virtme env
  • getting desperate as nothing works that used to work
• Day 2
  • getting to call the invocation of loading the early kernel from __init after kcsan_init()

• Day 3

  • fix problem of memdup not being able to alloc so much memory... use 64K page sizes for now
  • code refactoring
  • I'm now able to load the crash kernel
  • When using virtme I can boot into the crash kernel, also it doesn't boot completely (major milestone!), crash in elfcorehdr_read_notes()

• Day 4

  • crash systems crashes (no pun intended) in copy_old_mempage() link; will need to understand elfcorehdr...
  • call path vmcore_init() -> parse_crash_elf_headers() -> elfcorehdr_read() -> read_from_oldmem() -> copy_oldmem_page() -> copy_to_iter()

• Day 5

  • hacking arch/arm64/kernel/crash_dump.c:copy_old_mempage() to see if crash system really starts. It does.
  • fun fact: retested with more reserved memory and with UEFI FW, host kernel crashes in init but directly starts the crash kernel, so it works (somehow) \o/

• TODOs

  • fix elfcorehdr so that we actually can make use of all this...
  • test where in the boot __init() chain we can/should call kexec_early_dump()

---

Create DRM drivers for VESA and EFI framebuffers by tdz

Description

We already have simpledrm for firmware framebuffers. But the driver is originally for ARM boards, not PCs. It is already overloaded with code to support both use cases. At the same time it is missing possible features for VESA and EFI, such as palette modes or EDID support. We should have DRM drivers for VESA and EFI interfaces. The infrastructure exists already and initial drivers can be forked from simpledrm.

Goals

• Initially, a bare driver for VESA or EFI should be created. It can take functionality from simpledrm.
• Then we can begin to add additional features. The boot loader can provide EDID data. With VGA hardware, VESA can support paletted modes or color management. Example code exists in vesafb.

---