Quoth Anthony Sorace <a...@9srv.net>:
> 1. Project ideas. One of the key parts of the application is the
> project ideas page. If you’ve got ideas that seem like they’d
> be a good fit for the program, and *especially* if you’re up for
> mentoring them, please think about how to describe them in
> sufficient detail for a student to work on (objectives,
> promising starting points, likely challenges, &c).
Here's a partial list of things I've been hoping to find
time for. Some are fuzzy and poorly thought out. I'd be
willing to mentor most of them, given someone that I had
confidence in.
In no particular order:
- Imlementing asan in 6l:
Right now, there's no easy way to detect access
to uninitialized memory on the stack, use after
free, or many other common C errors in plan 9.
Unix has a number of tools like the address
sanitizer and valgrind.
I think it would be possible to make the linkers
instrument programs with checks similar to the
clang address sanitizer.
https://research.google.com/pubs/archive/37752.pdf
This would involve getting a fairly deep
understanding of how the linkers work,
modifying them to add a check before every
memory read and write. It would also involve
writing a runtime library for it, which
could possibly be put into libc besite the
profiling code.
- Improving dtracy:
9front has implemented a dtrace workalike
called dtracy. It's already proved useful
for collecting statistics systemwide, but
has a few annoyances. Namely:
- It does not know how to collect
stack traces.
- It needs manually defined tracepoints.
The first issue would involve teaching
the kernel how to collect the stack trace
of a process -- so, parsing debug info
and packing it up into something that can
be sent back to userspace.
The second can probably be done by marrying
devtrace from 9atom with dtracy:
http://man.postnix.pw/9atom/3/trace
- Implementing fuzzing framework:
Plan 9 programs often handle unexpected
input poorly. A tool that would help root
out crashes and improve reliability of
plan 9 software would be very welcome.
The goal would be to implement a tool
similar to AFL, but running on plan 9,
using the plan 9 toolchain.
https://lcamtuf.coredump.cx/afl/
This may require some changes to the
linker, to make profiling information
granular enough to provide coverage.
- Implementing syzkaller support:
The reasoning is the same as above: The
plan 9 kernel almost certainly has a number
of undiscovered bugs, panics, and issues
around mishanlding of untrusted input.
An attempt to fuzz the kernel would ceratinly
improve software quality.
This may also involve enhancing the linker to
provide more granular coverage information.
https://github.com/google/syzkaller/blob/master/docs/internals.md
- SSH server:
For providing service to unix, this could
be helpful -- at least, git/serve could
use it for push and clone.
This would probably be done by forking the
ssh client (/sys/src/cmd/ssh.c), and making
it handle the server side of communication,
then doing a cleanup pass to pull out the
common code.
- TLS certificate chain verification:
Right now, we rely on thumbprints for
certificate verification. Thumbprints
require manual additions for ever server
that we want to communicate with in a
secure and authenticated manner.
We should instead handle TLS certificate
chain verification in our x509 client.
The LibreSSL people recently put together
a test suite for certificate verification.
This should be used to validate the work.
- Devdraw improvements:
It seems like moving devdraw to userspace
is a good idea. This also allows doing some
vectorized SSE draw ops that would be painful
in the kernel, as well as allowing freer
experimentation with toys like affine transforms,
antialiasing modes, similar.
- Malloc improvemnts:
Our current allocator is slow, and takes
a global lock on every allocation. We're
leaving a lot of performance on the table,
and a faster allocator need not be all that
much more complex.
- Arm64 go support
Seems feasible. May be too small in scope,
since all the code gen is there. If so,
there are a bunch of improvements to the
runtime that could be made.
As a sporadic user of go, I'm probably
not the best choice. It seems that miller
or 0intro are the most prolific plan9 go
committers -- if they are willing.
- Searchable PDFs in page:
Sigrid has done some initial work on writing
the basics of a pdffs; Expanding on it and
implementing plain text output would be a
good first step.
Once plain text is done, implementing rendering
would be the next step. It's an open question
how to do the rendering, and whether it's worth
extending libmemdraw or stealing parts of libttf
as part of the project.
This is a big one, and I'd be happy if we came
out of it with a working pdf2text.
Sigrid is the initial author, and would be the
best choice to mentor, if she is willing.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T00b3dc89a8df295a-M574eab3091a832d9fd544d82
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
