jotaOS TODO list


This file is an automated ORG export, so it's pretty convenient for me.

This is not exactly a TODO list but more of a file to keep my thoughts sorted. Some parts have just the title, some parts are explained in depth so I don't forget about the specifics.

1 New TODO

1.1 TSS

1.2 ELF

1.3 Tasks

1.4 Syscalls

1.5 Scheduler

1.6 MPI

1.7 IDE

1.8 ATA

1.9 FAT32


2.1 STL in std namespace

2.2 COW

Copy-on-write would improve the process creation a whole lot. Also, it's really easy to do on shared libraries.

2.3 My own allocator

Will stop using liballoc and make my own, even though it will probably be worse.

2.4 Multicore

2.4.1 Change PIT to some other thing

2.5 Smash stack protection

Should just be a really simple library.

2.6 Simplify JOTAFS

Remove FIFO and suction pipe and socket. All of them, gone.

The kernel of jotaOS is a microkernel. Therefore, IPC is critical and will be built directly on the methodology, not as a special file.

2.7 Fix keyboard bug with latin-1

2.8 A boolean

That checks if the current filesystem has been written into since boot. Should be part of the DMA implementation.

This could make it really more resistant to mistakes.

2.9 Arguments library (for managing arguments in a somewhat standard way)

Something that allows «-a -b» and «-ab» and sometimes «ab»…

2.10 Good coreutils

2.10.1 pwd

2.10.2 cd (shell)

2.10.3 ls

2.10.4 nef (New Empty File)

2.10.5 mkd (Make directory)

2.10.6 rd (Read file)

2.10.7 rm (Trash files) and RM (caps, really remove files)

«RM» can be a symlink to «rm», and it should be able to detect what's the name of the binary when called, like «bash» with «rbash».

2.10.8 rmdir (Remove empty directories)

2.10.9 bare (A really simple editor)

I might change the name to something cooler.

It will have its own format (dot something, don't know which one atm) that I will make up.

25x80 editor, similar to the basic interpreter of the C64. There are no "lines" per se but a character stream that fills the whole screen, which will be full with spaces.

The user will be able to change foreground (Ctrl+F) and background (Ctrl+B) and so on.

It will also be not just a file, but more like a package of documents, each linked to others through hyperlinks like a webpage. In each document the user will be able to set a custom font (but not in a part of a document, as that's impossible to do in text mode).

2.10.10 And a bunch more that I'll be writing here when come to mind

2.11 Improve paging allocator

Do not kernel panic immediately if low on memory, start killing low priority processes.

2.12 Users, groups, and permissions

Users and groups have granular syscall permissions. If a user has the bit of managing the other bits high, it can only enable and disable those it has to high. I think it's a great design!

Superuser will be «high», as it has access to all syscalls (all bits set to high, that is, one). It will be the only user created at installation.

Also, permissions; in the neat way I've designed. Don't copy it here because it's in Spanish and it's a long explanation I am not willing to translate.


2.14 KPTI

2.15 COW in "string".

2.16 Lock interface

For making locks easily. All siblings share the same "lock space", and can lock/unlock IDs (0, 1…).

2.17 Cool MSS

The shell will have cool syntax. Curly braces will copy the contents to a temporal file, pass the defined context (variables) and execute it. On return, context is updated. This way, for can be an actual program, and we can do something like:

for i in [0 1 2 3] {
    echo $i

Which will actually run:

for i in [0 1 2 3] /tmp/MSS/curly-INCREMENTAL_ID.mss

Don't know if variables will be with $ tho. Have to think about what makes sense the most.

Code blocks will also be able to be assigned to variables, and this way I will create functions.

hello = {
    echo $1

This will make very intuitive passing function as arguments to another function and such.

For this, a specific curly variable type must be implemented.

2.18 SWAP

Page faults and such.

2.19 Time (RTC)

JOTAFS needs it lmao.

2.20 Registry

Kind of like in Windows, or maybe like a database out of the box, for letting applications store data encrypted with a key only "one" knows. Have to think more about it, don't know how it will be nor whether it will have any use at all.

2.21 Math library

2.21.1 BigInt

Karatsuba, of course.

2.21.2 GCD - Euclidean algorithm

2.21.3 Montgomery reduction

Enter and leave montgomery representation.

When leaving montgomery representation, always substract something. Zero in case n < p, p otherwise. This should be implemented in assembly so no compiler optimization is performed.

2.21.4 modpow(a, b, m)

Do repeated squaring:

Do not do sliding windows. Maybe implement it as optional? In that case, I should get clear that is not suitable for cryptographic use.

2.21.5 unsecure_random() - MT19937

2.21.6 Primality tests

Make an interface «PrimalityTest» and implement the following:

  1. Slow (don't know how it's called right now)

    The one which checks all numbers below sqrt(n).

  2. Fermat's

    Just for completeness. It's easy to implement so it would be nice to have it even though it's mostly useless for the crypto library.

  3. Miller-Rabin
  4. AKS

2.22 Network

2.22.1 Network driver - RTL8139

2.22.2 ARP

2.22.3 IP

2.22.4 ICMP

2.22.5 UDP

2.22.6 DHCP

2.22.7 Program: connect

Sets up a connection (loads drivers and stuff, they do not need to be loaded with the system at boot).

connect <profile>

2.22.8 DNS

2.22.9 TCP

2.22.10 Network driver - Intel Ethernet i217

2.22.11 Network driver - Am79c970A

2.23 HTTP

2.24 Crypto library

Write in the README that I'm a hobbyist, that I don't know what I'm doing, and warn that this must not be used in real scenarios.

2.24.1 Hashing

  1. Pearson hashing

    You know, for starting easy.

  2. MD5
  3. SHA
    1. SHA-2
    2. Maybe SHA-3?

2.24.2 Utils


    This will NOT be in the crypto library. I put it here for keeping the step-by-step thingy. This will be part of the kernel.

    I want several entropy pools of n bits each, and I must focus on the topic of joining them together. Linux's «random» uses a CRC-like approach. I might just XOR them together.

    Stuff to keep in mind:

    1. Standard whitening (Von Neumann - drop 00 and 11, 01=0, 10=1)
    2. rdrand only in conjunction to the other stuff, never by itself
    3. Latency of hard disk accesses.
    4. [Maybe a bad idea] DakaRand:
    5. SipHash:
    6. Measure the real time clock (KHz) with the CPU (GHz)
    7. «My preferred CSPRNG»

      According to Dan Kaminsky: SipHash(Secret || Counter++ || PreviousOutput || ShiftedTime)

      ShiftedTime is CLOCK_MONOTONIC shifted by some absolute amount so the attacker can't just look up the global time and predict bits

      PreviousOutput means if ShiftedTime only has one shot to repeat

  2. nextPrime()

    Receives a «PrimalityTest» object. It's really simple.

    1. Even? Add one.
    2. Call the primality test.
    3. Not prime? Add 2. Go to 2.
  3. Prime number generator (of at least n bytes)

    Trivial, should be an inline function. nextPrime(random(), test). Where random() is the really nice kernel CSPRNG, and test is the «PrimalityTest» object received as a parameter.

  4. Curve25519

2.24.3 Encryption algorithms

  1. RSA (PKCS #1 v2.2)

    Receives an OPTIONAL «PrimalityTest» object. Default will be Miller-Rabin. I should learn OAEP in depth, and read the PKCS #1 standard if it's not too long.

    1. CRT optimization
  2. Diffie-Hellman
  3. ECDH
  4. AES

    If AES-NI check turns out positive, we're mostly done. I could just rely solely on AES-NI and fail miserably otherwise. How common is that set of instructions in CPUs? I don't care about supporting really old systems.

    1. AES-NI check
    2. Only GCM

2.25 ASLR

Easy once I have the CSPRNG.

2.26 Certificates

Include just jotaOS' CA. There will be then a package for installing the commonly trusted CAs.

2.27 Package manager

Wanna call it tusm (The Unified Software Manager). HTTP based with signed packages, or directly HTTPS. Made in MSS (rather than C++) so that I am forced to extend the capabilities of the shell.

2.28 Seck

Security check. Checks if installed packages are vulnerable.

2.29 HTTPS

2.30 SSH server

At this point, I will mark jotaOS as finished. I will probably still add new stuff (see below), but when I have an SSH server I'll be done.


2.32 Fusion trees and tries for specific cases of "set" in the STL

2.33 SFTP?

2.34 Sound

2.35 Tetris

2.36 DMA

Not a priority since I have my new cool IDE driver. I don't know where to put this, so I might do it earlier, or never. Who knows.

2.37 GUI?

2.38 Web browser?

This would be a huge lot of effort.

3 Notes (outside the TODO)

3.1 Directory structure

3.1.1 /bin (binaries)

3.1.2 /cnf (global config files)

3.1.3 /home (for users and local configs)

Author: José Luis

Created: 2021-02-18 Thu 19:00