Improve UML page fault handler
a project by ptesarik
Updated about 1 month ago. 1 hackers ♥️. 2 followers.

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/

Join this project

Looking for hackers with the skills:

kernel

This project is part of:

Hack Week 24

Activity

  • about 1 month ago: michals liked this project.
  • about 1 month ago: ptesarik added keyword "kernel" to this project.
  • about 1 month ago: ptesarik started this project.
  • about 1 month ago: ptesarik originated this project.


    • Comments

    • ptesarik
      about 1 month ago by ptesarik | Reply

      I intend to work on this project whenever I get stuck with https://hackweek.opensuse.org/24/projects/kill-dma-and-dma32-memory-zones So, it you like the idea, feel free to grab it, just add a comment here.

    Similar Projects

    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

    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()

    Kill DMA and DMA32 memory zones by ptesarik

    Description

    Provide a better allocator for DMA-capable buffers, making the DMA and DMA32 zones obsolete.

    Goals

    Make a PoC kernel which can boot a x86 VM and a Raspberry Pi (because early RPi4 boards have some of the weirdest DMA constraints).

    Resources

    • LPC2024 talk:
    • video:

    Officially Become a Kernel Hacker! by m.crivellari

    Description

    My studies as well my spare time are dedicated to the Linux Kernel. Currently I'm focusing on interrupts on x86_64, but my interests are not restricted to one specific topic, for now.

    I also "played" a little bit with kernel modules (ie lantern, a toy packet analyzer) and I've added a new syscall in order read from a task A, the memory of a task B.

    Maybe this will be a good chance to...

    Goals

    • create my first kernel patch

    Resources

    Achivements

    Modularization and Modernization of cifs.ko for Enhanced SMB Protocol Support by hcarvalho

    Creator:
    Enzo Matsumiya ematsumiya@suse.de @ SUSE Samba team
    Members:
    Henrique Carvalho henrique.carvalho@suse.com @ SUSE Samba team

    Description

    Split cifs.ko in 2 separate modules; one for SMB 1.0 and 2.0.x, and another for SMB 2.1, 3.0, and 3.1.1.

    Goals

    Primary

    Start phasing out/deprecation of older SMB versions

    Secondary

    • Clean up of the code (with focus on the newer versions)
    • Update cifs-utils
    • Update documentation
    • Improve backport workflow (see below)

    Technical details

    Ideas for the implementation.

    • fs/smb/client/{old,new}.c to generate the respective modules
      • Maybe don't create separate folders? (re-evaluate as things progresses!)
    • Remove server->{ops,vals} if possible
    • Clean up fs_context.* -- merge duplicate options into one, handle them in userspace utils
    • Reduce code in smb2pdu.c -- tons of functions with very similar init/setup -> send/recv -> handle/free flow
    • Restructure multichannel
      • Treat initial connection as "channel 0" regardless of multichannel enabled/negotiated status, proceed with extra channels accordingly
      • Extra channel just point to "channel 0" as the primary server, no need to allocate an extra TCPServerInfo for each one
    • Authentication mechanisms
      • Modernize algorithms (references: himmelblau, IAKERB/Local KDC, SCRAM, oauth2 (Azure), etc.