ProcFS /proc/<pid>/vm map info no longer contains two `purgeable` keys.
The second `purgeable` key has been removed and replaced with keys for
`kernel` and `cacheable`.
Browser supports very few protocols (http, https, gemini, file) at the
moment, so there's no point in using it as a catch-all and default
protocol handler. I added an explicit association for gemini to
/bin/Browser instead.
This stops Desktop::Launcher::open() from reporting success for any URL,
which really isn't the case (Browser shows an error page...).
open(1) was able to handle most URLs as well as paths, but not file://
URLs (which occur when dragging something from the output of ls, for
example). We have to create an URL from the user-supplied argument using
create_with_url_or_path(), check whether it's a file:// URL or not and
*then* use real_path_for() on the URL's path().
Problem:
- File globbing is performed at the time of build system
generation. Any files which are not there at that time are not
included. So, when a new file is added it is not built unless the
build system is recreated.
Solution:
- Remove globbing from AK/Tests directory in favor of explicitly
listing the files.
We were casting the address to Userspace<T> without validating it first
which is no good and will trap an assertion soon after.
Let's catch this sooner with an ASSERT in the Userspace<T> constructor
and update the PT_PEEK and PT_POKE handlers to avoid it.
Fixes#4505.
This is a crude protection against IOPL elevation attacks. If for
any reason we find ourselves about to switch to a user mode thread
with IOPL != 0, we'll now simply panic the kernel.
If this happens, it basically means that something tricked the kernel
into incorrectly modifying the IOPL of a thread, so it's no longer
safe to trust the kernel anyway.
Calling the file MainWindow.gml (and subsequently using MainWindowGML.h
for the generated file's name) suggests that's possible for every
application, but having a second one anywhere results in the following
CMake error:
add_custom_target cannot create target "generate_MainWindowGML.h"
because another target with the same name already exists. The
existing target is a custom target created in source directory [...]
It's now also more consistent with the other applications already using
GML, namely "BrowserWindow.gml" and "FileManagerWindow.gml".
Also simplify the file copying logic a bit to avoid two syscalls
per file. We now create the file with the right mode right away
instead of creating it first, and then fchmod'ing it later.
Fixes#4479.
I think this is okay, the main thing to protect against is new versions
of the format that we don't know about yet.
This happens because an .S file compiled into libc.so has version 2
instead of version 4 like everything else.
Fixes#4491.
POSIX allows the default streams (stdin, stdout and stderr) to be
macros, which means that on such systems (musl libc is one) building
Lagom will fail due to the File::std*() names.
Also fix any files that use these identifiers.
There's no need to leave the cell dirty when not updating it, and
there's definitely no need to update the cells as we're selecting them.
This makes navigating a sheet and selecting cells significantly faster
as we no longer update unrelated cells just because they appear to have
a cyclic update dependency :^)
...and don't let them leak out of their evaluation contexts.
Also keep the exceptions separate from the actual values.
This greatly reduces the number of assertions hit while entering random
data into a sheet.
Hide private members, and make the odd update() -> sheet->update(cell)
-> update(Badge<Sheet>) -> update_data() less odd by removing the
update(Badge<Sheet>) step.
LibC stdlib `arc4random()` uses the `getrandom` system call which
uses `KernelRng::get_good_random_bytes`.
This ensures that filenames generated using functions such as
`mkstemp()` are suitably randomised and are no longer predictable.
Problem:
- Modifying CXXFLAGS directly is an old CMake style.
- The giant and ever-growing list of `*_DEBUG` macros clutters the
top-level CMakeLists.txt.
Solution:
- Use the more current `add_compile_definitions` function.
- Sort all the debug options so that they are easy to view.
- Move the `*_DEBUG` macros to their own file which can be included
directly.
It was possible to overwrite the entire EFLAGS register since we didn't
do any masking in the ptrace and sigreturn syscalls.
This made it trivial to gain IO privileges by raising IOPL to 3 and
then you could talk to hardware to do all kinds of nasty things.
Thanks to @allesctf for finding these issues! :^)
Their exploit/write-up: https://github.com/allesctf/writeups/blob/master/2020/hxpctf/wisdom2/writeup.md
Since they're all covered by the same spec sheet, we can expect
the same code to cover most of the devices.
It can't currently differentiate between them, which would be nice to
add for determining what registers we can access.
And make an effort to propagate errors out from the inner parts.
This fixes an issue where the kernel would infinitely loop in coredump
generation if the TmpFS filled up.
It was possible to go outside the interlacing row strid/offset arrays.
Just fail the decode if this is about to happen. I've added a FIXME
about rejecting such images earlier, since it's a bit sad to only do
this once we realize the pass index is about to overflow.
Found by oss-fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28239
When enumerating the hardware using MMIO mode, it would attempt to
create a physical ID first. To create a physical ID, it needs to
retrieve the capabilities of the device.
When enumerating the first device, there would be no device
configuration space mappings. Access::get_capabilities_pointer
calls PCI::read16, which in turn goes to MMIOAccess::read16_field.
MMIOAccess::read16_field attempts to get a device configuration space
and fully expects to get one. However, since this is the first device,
there are none and it crashes with an m_has_value assertion failure.
This fixes this by creating the device configuration space mapping
before creating the physical ID.
Testing with VMware Player 16.1.0.
Problem:
- Functions are duplicated in [PBM,PGM,PPM]Loader class
implementations. They are functionally equivalent. This does not
follow the DRY (Don't Repeat Yourself) principle.
Solution:
- Factor out the common functions into a separate file.
- Refactor common code to generic functions.
- Change `PPM_DEBUG` macro to be `PORTABLE_IMAGE_LOADER_DEBUG` to work
with all the supported types. This requires adding the image type to
the debug log messages for easier debugging.
Problem:
- Appending to CMAKE_CXX_FLAGS for everything is cumbersome.
Solution:
- Use the `add_compile_options` built-in function to handle adding
compiler options (and even de-duplicating).
Problem:
- Setting `CMAKE_CXX_FLAGS` directly to effect the version of the C++
standard being used is no longer the recommended best practice.
Solution:
- Set C++20 mode in the compiler by setting `CMAKE_CXX_STANDARD`.
- Force the build system generator not to fallback to the latest
standard supported by the compiler by enabling
`CMAKE_CXX_STANDARD_REQUIRED`. This shouldn't ever be a problem
though since the toolchain is tightly controlled.
- Disable GNU compiler extensions by disabling `CMAKE_CXX_EXTENSIONS`
to preserve the previous flags.
