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.
Make mmap return -ENOTSUP in this case to make sure users don't get
confused and think they're using a private mapping when it's actually
shared. It's currenlty not possible to open a file and mmap it
MAP_PRIVATE, and change the perms of the private mapping to ones that
don't match the permissions of the underlying file.
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.
This allows you to click on the menu, then use the menu keys to browse
the menu. Beforehand, you would click the window, release the button,
and the menu would close :(
Add event handling for key presses for navigating a menu. The currently
hovered menu item is tracked through an index which is either
incremented or decremented on up or down arrow key presses, changing the
hovered item.
Whenever there is a mouse move event, we ensure that the current index
matches the currently hovered item so that the mouse and keyboard do not
get out of sync.
If the right key is pressed, and we are on a submenu menu item, we
'enter' that submenu. While we are currently in a submenu, we forward
all keypress events to that submenu for handling. This allows us to
traverse the heirachy of a menu. While in a submenu, if the left key is
pressed, we leave that submenu and start handling the keypresses
ourselves again.
There is currently a small issue where the mouse hover and key hover can
get out of sync. The mouse can be traversing a submenu, but the parent
menu has no idea that the mouse has 'entered' a submenu, so will handle
the key presses itself, instead of forwarding them to the submenu. One
potential fix for this is for a menu to tell its menu parent that the
submenu is being traversed.
It would be nice to do this in the assembly code, but we have to check
if the feature is available before doing a CLAC, so I've put this in
the C++ code for now.
This patch fixes some issues with the mmap() and mprotect() syscalls,
neither of whom were checking the permission bits of the underlying
files when mapping an inode MAP_SHARED.
This made it possible to subvert execution of any running program
by simply memory-mapping its executable and replacing some of the code.
Test: Kernel/mmap-write-into-running-programs-executable-file.cpp
This encourages callers to strongly reference file descriptions while
working with them.
This fixes a use-after-free issue where one thread would close() an
open fd while another thread was blocked on it becoming readable.
Test: Kernel/uaf-close-while-blocked-in-read.cpp
Instead of using the FIFO's memory address as part of its absolute path
identity, just use an incrementing FIFO index instead.
Note that this is not used for anything other than debugging (it helps
you identify which file descriptors refer to the same FIFO by looking
at /proc/PID/fds
