This code had been misinterpreting the Multiboot ELF section headers
since the beginning. Furthermore QEMU wasn't even passing us any
headers at all, so this wasn't checking anything.
If we pass a null path to these syscall wrappers, just return EFAULT
directly from the wrapper instead of segfaulting by calling strlen().
This is a compromise, since we now have to pass the path length to the
kernel, so we can't rely on the kernel to tell us that the path is at
a bad memory address.
I often keep my terminal camped in the project root directory and run
`make && ./Kernel/sync.sh && ./Kernel/run`
This change allows me to not feel like a doofus when I do that :^)
This patch introduces a helpful copy_string_from_user() function
that takes a bounded null-terminated string from userspace memory
and copies it into a String object.
Supervisor Mode Access Prevention (SMAP) is an x86 CPU feature that
prevents the kernel from accessing userspace memory. With SMAP enabled,
trying to read/write a userspace memory address while in the kernel
will now generate a page fault.
Since it's sometimes necessary to read/write userspace memory, there
are two new instructions that quickly switch the protection on/off:
STAC (disables protection) and CLAC (enables protection.)
These are exposed in kernel code via the stac() and clac() helpers.
There's also a SmapDisabler RAII object that can be used to ensure
that you don't forget to re-enable protection before returning to
userspace code.
THis patch also adds copy_to_user(), copy_from_user() and memset_user()
which are the "correct" way of doing things. These functions allow us
to briefly disable protection for a specific purpose, and then turn it
back on immediately after it's done. Going forward all kernel code
should be moved to using these and all uses of SmapDisabler are to be
considered FIXME's.
Note that we're not realizing the full potential of this feature since
I've used SmapDisabler quite liberally in this initial bring-up patch.
I though it would be nice to also show the style that the browser uses
to display an element.
In order to do that, in place of the styles table I've put a tab widget,
with tabs for both element and computed element styles.
This was tripping up CObject which interprets timer ID 0 as "no timer".
Once we got ID 0 assigned, it was impossible to turn it off and it
would fire on every event loop iteration, causing CPU churn.
The clock menu applet was causing pixel ghosting at some seemingly
arbitrary location on the desktop because the background paint logic
tries to avoid painting any part of the background that's covered by
an opaque window.
Since the code was using any_opaque_window_contains_rect() to check
this, we were not considering the window's *type*. (Menu applets are
still windows, but they are of the special type "MenuApplet" and do
not participate in normal compositing.)
The fix is to use for_each_visible_window_from_back_to_front() instead
of for_each_window() :^)
Fixes#1022.
Our syscall calling convention only allows passing up to 3 arguments in
registers. For syscalls that take more arguments, we bake them into a
struct and pass a pointer to that struct instead.
When doing pointer validation, this is what we would do:
1) Validate the "params" struct
2) Validate "params->some_pointer"
3) ... other stuff ...
4) Use "params->some_pointer"
Since the parameter struct is stored in userspace, it can be modified
by userspace after validation has completed.
This was a recurring pattern in many syscalls that was further hidden
by me using structured binding declarations to give convenient local
names to things in the parameter struct:
auto& [some_pointer, ...] = *params;
memcpy(some_pointer, ...);
This devilishly makes "some_pointer" look like a local variable but
it's actually more like an alias for "params->some_pointer" and will
expand to a dereference when accessed!
This patch fixes the issues by explicitly copying out each member from
the parameter structs before validating them, and then never using
the "param" pointers beyond that.
Thanks to braindead for finding this bug! :^)
LibHTML will now use the palette colors for the default document background and
the text. As always, a page can override this default styling with CSS if it
really wants a specific color or style.
Fixes https://github.com/SerenityOS/serenity/issues/963
Menus are now owned by menu manager instead of being split between the
window manager and menu manager. If the window server wants to change
a menu, or call menu related functionality, this will need to be done
through the menu manager.
Further refactoring is likely needed, but this seems like a good start
for seperating menu logic from window logic.
