RISC-V emulator in GLSL capable of running Linux by favogt

Description

There are already numerous ways to run Linux and some programs through emulation in a web browser (e.g. x86 and riscv64 on https://bellard.org/jslinux/), but none use WebGL/WebGPU to run the emulation on the GPU.

I already made a PoC of an AArch64 (64-bit Arm) emulator in OpenCL which is unfortunately hindered by a multitude of OpenCL compiler bugs on all platforms (Intel with beignet or the new compute runtime and AMD with Mesa Clover and rusticl). With more widespread and thus less broken GLSL vs. OpenCL and the less complex implementation requirements for RV32 (especially 32bit integers instead of 64bit), that should not be a major problem anymore.

Goals

Write an RISC-V system emulator in GLSL that is capable of booting Linux and run some userspace programs interactively. Ideally it is small enough to work on online test platforms like Shaderoo with a custom texture that contains bootstrap code, kernel and initrd.

Minimum:

riscv32 without FPU (RV32 IMA) and MMU (µClinux), running Linux in M-mode and userspace in U-mode.

Stretch goals:

FPU support, S-Mode support with MMU, SMP. Custom web frontend with more possibilities for I/O (disk image, network?).

Resources

RISC-V ISA Specifications
Shaderoo
OpenGL 4.5 Quick Reference Card

---

Explore Microchip PIC64GX1000 Curiosity board (riscv64) by a_faerber

Description

The Microchip PIC64 family of RISC-V chipsets was announced this summer, with PIC64GX as first subfamily (with SiFive U54 CPU cores, same as Microchip PolarFire). Later families (PIC64-HPSC and PIC64HX) were announced to feature the long-awaited RISC-V Hypervisor Extension.

My pre-ordered PIC64GX1000 Curiosity board arrived the week before Hackweek 24.

Goals

I intend to investigate enabling openSUSE Tumbleweed riscv64 on this new chipset and board.

Resources

• Microchip Curiosity PIC64GX1000 Kit ES

Progress

• Created udev rules for Curiosity board's FTDI based debug UARTs on USB-C - UART B has output from HSS / OpenSBI, UART C has output from U-Boot and kernel
• Modified the image https://download.opensuse.org/ports/riscv/tumbleweed/images/openSUSE-Tumbleweed-RISC-V-JeOS-efi.riscv64-2024.11.10-Build1.13.raw.xz (20241118) with gdisk to prepend a bootloader partition (copying the binary bootloader from the vendor-supplied microSD, ignoring excess partition size) and added the microchip/pic64gx-curiosity-kit.dtb file to the EFI System Partition (again from the vendor-supplied microSD)
• This boots into Tumbleweed! with ttyS1 by default (UART C)

---

FizzBuzz OS by mssola

Project Description

FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).

This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.

This project is free software and you can find it here.

Goal for this Hackweek

• Better understand the RISC-V SBI interface.
• Better understand RISC-V in privileged mode.
• Have fun.

Resources

• SBI v2.0 ratified specification
• Blog post on SBI
• mssola/fbos

---

Create openSUSE images for Arm/RISC-V boards by avicenzi

Project Description

Create openSUSE images (or test generic EFI images) for Arm and/or RISC-V boards that are not yet supported.

Goal for this Hackweek

Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.

Consider generic EFI images where possible, as some boards can hold a bootloader.

Document in the openSUSE Wiki how to flash and use the image for a given board.

Boards that I have around and there are no images:

• Rock 3B
• Nano PC T3 Plus
• Lichee RV D1
• StartFive VisionFive (has some image needs testing)

Hack Week 22

• NanoPC T4

Hack Week 21

• NanoPi M4B
• Radxa Zero

Resources

• https://en.opensuse.org/Portal:Arm
• https://en.opensuse.org/Portal:RISC-V

---

Tumbleweed on Mars-CM (RISC-V board) by ph03nix

RISC-V is awesome, Tumbleweed is awesome, chocolate cake is awesome. I'm planning to combine all of them in one project.

Project Description

I recently purchased a MILK-V Mars CM and managed to setup it up already using Debian Linux. My project for this Hackweek is to see how far I can get to run Tumbleweed on this compute module board.

Goal for this Hackweek

• Run Tumbleweed on the Compute Module

Resources

• http://milkv.io/mars-cm
• https://en.opensuse.org/HCL:VisionFive2

---

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.

---

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

---

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

---

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

---

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

---