Sergey suggested that having a non-zero O_RDONLY would make some things
less confusing, and it seems like he's right about that.
We can now easily check read/write permissions separately instead of
dancing around with the bits.
This patch also fixes unveil() validation for O_RDWR which previously
forgot to check for "r" permission.
I mistakenly thought that we were keeping the config file open, but we
don't. So we'll need to unveil the config path in case we need to write
out a new configuration.
This app needs ("/bin/Terminal", "x") in order to fork+exec itself when
the user requests a new Terminal window. I really like how this reduces
reduces the impact of pledging "exec". :^)
It also needs ("/res", "r") like all GUI apps. We delay the first call
to unveil until after we've already opened the app's config file, so
there's no need to worry about that.
We don't need to have this method anymore. It was a hack that was used
in many components in the system but currently we use better methods to
create virtual memory mappings. To prevent any further use of this
method it's best to just remove it completely.
Also, the APIC code is disabled for now since it doesn't help booting
the system, and is broken since it relies on identity mapping to exist
in the first 1MB. Any call to the APIC code will result in assertion
failed.
In addition to that, the name of the method which is responsible to
create an identity mapping between 1MB to 2MB was changed, to be more
precise about its purpose.
The problem was mostly in the initialization code, since in that stage
the parser assumed that there is an identity mapping in the first 1MB of
the address space. Now during initialization the parser will create the
correct mappings to locate the required data.
Nord (specifically Polar Night) is a popular soft dark blue/grey theme.
Personally, I find it to be a very nice middle-ground between the contrast of the
dark and light (default) theme.
Without this, we can't start programs via the system menu. This begs
the question: should WindowServer really be allowed to fork and exec
in the first place?
WindowServer needs persistent access to a few things:
- /res (for themes, fonts, cursors, apps, wallpapers, etc.)
- /etc/passwd (for username lookup, not sure this is actually needed..)
- /home/anon/WindowManager.ini (FIXME: this should not be hard-coded..)
These things are unveiled temporarily, and then dropped:
- /tmp (for setting up sockets)
- /dev (for opening input and framebuffer devices)
This leaves WindowServer running with a very limited view of the file
system, how neat is that!
This syscall is a complement to pledge() and adds the same sort of
incremental relinquishing of capabilities for filesystem access.
The first call to unveil() will "drop a veil" on the process, and from
now on, only unveiled parts of the filesystem are visible to it.
Each call to unveil() specifies a path to either a directory or a file
along with permissions for that path. The permissions are a combination
of the following:
- r: Read access (like the "rpath" promise)
- w: Write access (like the "wpath" promise)
- x: Execute access
- c: Create/remove access (like the "cpath" promise)
Attempts to open a path that has not been unveiled with fail with
ENOENT. If the unveiled path lacks sufficient permissions, it will fail
with EACCES.
Like pledge(), subsequent calls to unveil() with the same path can only
remove permissions, not add them.
Once you call unveil(nullptr, nullptr), the veil is locked, and it's no
longer possible to unveil any more paths for the process, ever.
This concept comes from OpenBSD, and their implementation does various
things differently, I'm sure. This is just a first implementation for
SerenityOS, and we'll keep improving on it as we go. :^)
This allows you to run our build system's Makefiles inside SerenityOS
itself (since they rely on "flock")
Obviously it doesn't do any locking as we don't support that yet.
Background: DoubleBuffer is a handy buffer class in the kernel that
allows you to keep writing to it from the "outside" while the "inside"
reads from it. It's used for things like LocalSocket and TTY's.
Internally, it has a read buffer and a write buffer, but the two will
swap places when the read buffer is exhausted (by reading from it.)
Before this patch, it was internally implemented as two Vector<u8>
that we would swap between when the reader side had exhausted the data
in the read buffer. Now instead we preallocate a large KBuffer (64KB*2)
on DoubleBuffer construction and use that throughout its lifetime.
This removes all the kmalloc heap traffic caused by DoubleBuffers :^)
This broke with the >3GB paging overhaul. It's no longer possible to
write directly to physical addresses below the 8MB mark. Physical pages
need to be mapped into kernel VM by using a Region.
Fixes#1099.
There is no real "read protection" on x86, so we have no choice but to
map write-only pages simply as "present & read/write".
If we get a read page fault in a non-readable region, that's still a
correctness issue, so we crash the process. It's by no means a complete
protection against invalid reads, since it's trivial to fool the kernel
by first causing a write fault in the same region.
uintptr_t is 32-bit or 64-bit depending on the target platform.
This will help us write pointer size agnostic code so that when the day
comes that we want to do a 64-bit port, we'll be in better shape.
A mouse move event needs to do a bit more work than what a mouse wheel event
does. Mouse wheel just needs to update the hovered item, and update for a new
hovered item. This also stops us from calling redraw() twice on a wheel event.
While I really enjoyed having an infinite cycle when I implemented menu
keys (and seeing it wizz around and around :D), menu key movement should
be consistent between menus - and an inifinite cycle does not make much
sense for a scrollable menu.
Menus now have a scroll offset (index based, not pixel based) which is
controlled either with the mouse wheel or with the up/down arrow keys.
This finally allows us to browse all of the fonts that @xTibor has made
avilable through his serenity-fontdev project:
https://github.com/xTibor/serenity-fontdev
I'm not completely sure about the up/down arrows. They feel like maybe
they occupy a bit too much vertical space.
Also FIXME: this mechanism probably won't look completely right for
menus that have separators in them.
Fixes#1043.
The userspace locks are very aggressively calling sys$gettid() to find
out which thread ID they have.
Since syscalls are quite heavy, this can get very expensive for some
programs. This patch adds a fast-path for sys$gettid(), which makes it
skip all of the usual syscall validation and just return the thread ID
right away.
This cuts Kernel/Process.cpp compile time by ~18%, from ~29 to ~24 sec.
Before this, we would end up in memcpy() churn hell when a program was
doing repeated write() calls to a file in /tmp.
An even better solution will be to only grow the VM allocation of the
underlying buffer and keep using the same physical pages. This would
eliminate all the memcpy() work.
I've benchmarked this using g++ to compile Kernel/Process.cpp.
With these changes, compilation goes from ~35 sec to ~31 sec. :^)
Instead of restoring CR3 to the current process's paging scope when a
ProcessPagingScope goes out of scope, we now restore exactly whatever
the CR3 value was when we created the ProcessPagingScope.
This fixes breakage in situations where a process ends up with nested
ProcessPagingScopes. This was making profiling very fragile, and with
this change it's now possible to profile g++! :^)
Previously, when deallocating a range of VM, we would sort and merge
the range list. This was quite slow for large processes.
This patch optimizes VM deallocation in the following ways:
- Use binary search instead of linear scan to find the place to insert
the deallocated range.
- Insert at the right place immediately, removing the need to sort.
- Merge the inserted range with any adjacent range(s) in-line instead
of doing a separate merge pass into a list copy.
- Add Traits<Range> to inform Vector that Range objects are trivial
and can be moved using memmove().
I've also added an assertion that deallocated ranges are actually part
of the RangeAllocator's initial address range.
I've benchmarked this using g++ to compile Kernel/Process.cpp.
With these changes, compilation goes from ~41 sec to ~35 sec.
