The userspace execve() wrapper now measures all the strings and puts
them in a neat and tidy structure on the stack.
This way we know exactly how much to copy in the kernel, and we don't
have to use the SMAP-violating validate_read_str(). :^)
When loading a new executable, we now map the ELF image in kernel-only
memory and parse it there. Then we use copy_to_user() when initializing
writable regions with data from the executable.
Note that the exec() syscall still disables SMAP protection and will
require additional work. This patch only affects kernel-originated
process spawns.
Since ELFDynamicObject needs the actual virtual address of the .dynamic
section in the loaded image, and not the file offset like we assumed
before, due to MAP_PRIVATE secretly giving us a MAP_SHARED, we can
remove all of the Dynamic* code from ELFImage.
ELFDynamicLoader only needs ELFImage to get the Program headers at this
point. More consolidation opportunities seem likely in the future.
We need to workaround the fact that MAP_PRIVATE when passed a file
descriptor doesn't work the way we expect. We can't change the
permissions on our mmap to PROT_WRITE if the original executable doesn't
have PROT_WRITE.
Because of this, we need to construct our ELFDynamicObject using the
actual virtual address of the .dynamic section, instead of using the
offset into the ELFImage that was actually getting modified by accident
...somehow. Not clear what was going on.
We were not recomputing the internal dimensions after a font changed,
which caused things to look very off.
It's still not perfect as we're always using the same (small) font for
bold text, which obviously sticks out like a sore pinky when the rest
of the terminal text is large.
Previously if more than one item was selected clicking on one of
them and dragging would de-select everything that is not the one that
was clicked on. Now, if more than one items are selected and there
is a mousedown it goes into a "mightdrag" state.
The user can then perform a drag, if they don't everything that is not
the item being clicked gets unselected in the mouseup event, mimicking
the previous behavior.
Before this, you could make the kernel copy memory from anywhere by
setting up an ELF executable with a program header specifying file
offsets outside the file.
Since ELFImage didn't even know how large it was, we had no clue that
we were copying things from outside the ELF.
Fix this by adding a size field to ELFImage and validating program
header ranges before memcpy()'ing to them.
The ELF code is definitely going to need more validation and checking.
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 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.
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
Previously we would consider anything in the large padded area around
each item to also be part of the item for mouse event purposes.
This didn't feel right when rubberbanding, so this patch factors out
the per-item rect computation into a get_item_rects() helper which can
then be used by the various functions that need it.
Separate some responsibilities:
ELFDynamicLoader is responsible for loading elf binaries from disk and
performing relocations, calling init functions, and eventually calling
finalizer functions.
ELFDynamicObject is a helper class to parse the .dynamic section of an
elf binary, or the table of Elf32_Dyn entries at the _DYNAMIC symbol.
ELFDynamicObject now owns the helper classes for Relocations, Symbols,
Sections and the like that ELFDynamicLoader will use to perform
relocations and symbol lookup.
Because these new helpers are constructed from offsets into the .dynamic
section within the loaded .data section of the binary, we don't need the
ELFImage for nearly as much of the loading processes as we did before.
Therefore we can remove most of the extra DynamicXXX classes and just
keep the one that lets us find the location of _DYNAMIC in the new ELF.
And finally, since we changed the name of the class that dlopen/dlsym
care about, we need to compile/link and use the new ELFDynamicLoader
class in LibC.
