QEMU was crashing since when setting the DSS divider we were _clearing_
the TV divider, and QEMU did not check for a divide by zero.
This "fixes" the QEMU crash and gets us a working framebuffer on Beagle ;)
* Added VFS helper function check_access_permissions() that combines
several partially correct versions to the one true version (tm).
* All but BFS (since recently) missed the S_IXOTH for root on directories,
and all but packagefs missed proper group handling.
When the address is not page aligned, not only adjust the address
to start mapping, but also take the "overflow" on the last page
into account.
This makes the bootloader boot again ;)
* When you change the current working directory, you actually
should have the permission to enter that directory.
* This gives us a 0.04% better score on the perl test suite :-)
The BOOT_GDT_SEGMENT_COUNT was based on USER_DATA_SEGMENT on both
x86 and x86_64. However, on x86_64 the order of the segments is
different, leading to a too small gBootGDT array. Move the define to
the arch specific headers so they can be setup correctly in either case.
Also add a STATIC_ASSERT() to check that the descriptors fit into the
array.
Pointed out by CID 1210898.
Due to the missing include, the builtin new and delete operators were
used in those two files instead of the ones from the include used
everywhere else in the runtime_loader.
The POSIX locale has gLocaleRoster = NULL and relies on the non-wide
version of the implementation. However it doesn't check that the
characters are actually in range which leads to out of bound access and
crashes in __isctype.
Fixes#11322.
Source or destination buffers passed to pagecache functions may belong
to kernel memory (e.g. when the caller is packagefs). Because of that
we should tell vm_memcpy_{from, to}_physical() truth, not assume that all
buffers are in user memory. That's important because user memory page fault
handlers cannot be nested and these functions may be used while handling
a page fault.
With high probability fixes#11246.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
This patch adds user_access() which can be used to gracefully handle
page faults that may happen when accessing user memory. It is used
by arch_cpu_user{memcpy, memset, strlcpy}() to allow using optimized
functions from the standard library.
Currently only x64 uses this, but nothing really is arch specific here.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
As Alex pointed out we can leak possibly sensitive data in xmm registers
when returning from the kernel. To prevent that xmm0-15 are zeroed
before sysret or iret. The cost is negligible.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
The kernel is allowed to use fpu anywhere so we must make sure that
user state is not clobbered by saving fpu state at interrupt entry.
There is no need to do that in case of system calls since all fpu
data registers are caller saved.
We do not need, though, to save the whole fpu state at task swich
(again, thanks to calling convention). Only status and control
registers are preserved. This patch actually adds xmm0-15 register
to clobber list of task swich code, but the only reason of that is
to make sure that nothing bad happens inside the function that
executes that task swich. Inspection of the generated code shows
that no xmm registers are actually saved.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Enable SSE as a part of the "preparation of the environment to run any
C or C++ code" in the entry points of stage2 bootloader.
SSE2 is going to be used by memset() and memcpy().
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
Just following the path of least resistance and adding andq $~15, %rsp
where appropriate. That should also make things harder to break
when changing the amount of stuff placed on stack before calling the
actual syscall routine.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
There is absolutely no reason for these functions to be in commpage,
they don't do anything that involves the kernel in any way.
Additionaly, this patch rewrites memset and memcpy to C++, current
implementation is quite simple (though it may perform surprisingly
well when dealing with large buffers on cpus with ermsb). Better
versions are coming soon.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
The possibility to specify custom memcpy and memset implementations
in cpu modules is currently unused and there is generally no point
in such feature.
There are only 2 x86 vendors that really matter and there isn't
very big difference in performance of the generic optmized versions
of these funcions across different models. Even if we wanted different
versions of memset and memcpy depending on the processor model or
features much better solution would be to use STT_GNU_IFUNC and save
one indirect call.
Long story short, we don't really benefit in any way from
get_optimized_functions and the feature it implements and it only adds
unnecessary complexity to the code.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
* Before, it would just overwrite the previous name, leaving extra
bytes from the previous name (they wouldn't become part of the
host name, but it just didn't look that nice).
long_mmu_init() prepares initial paging structures for 64 bit kernel.
Once that function completes bootloader cannot allocate any memory
that needs to be passed to the kernel.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
* VT100 is much more common than VT52 which the u-boot port was
previously using (a legacy of the Atari m68k port)
* Implement serial_getc (again, code is identical to raspberry port...)
so the boot menu can be used over the serial port. The enter key is
recognized, arrows currently aren't.
* Cursor coordinates are 1-based, not 0-based
* Color change was disabled and broken
This implementation of our console over VT100 is generic and should be
moved out of the raspberry-pi specific folder. However, leaving it there
for now as we will have some bigger reorganization a swe add FDT support
here.
No big functional reason for this, but rather keep it in sync now
then have to do lots of work later on, when there are major changes.
Once I have it fully fleshed out for ARM, I might take a look if
we can generalise it a little more, as there's lots of code
_exactly_ the same for both platforms (and other platforms in
progress using the same code).
* Removes default mapping of a portion of the RAM (will be done
as needed)
* Passes on the page directory area to kernel, so on early vm init
the kernel can use the area for pagetable allocation.
* Leaves it to the platform to pass in physical memory range(s). This
will ultimately come from FDT.
* Fix long standing issue with allocation of the heap, potentially
causing other part of the bootloader to overwrite the heap.
* Implements pagetable allocator in kernel for early vm mapping.
This fixes the first PANIC seen, we now just get the same one later
on when the VM is up... more to come...
We have _start/_end symbols to mark our start and end, use those
to determine where we are loaded. We're slowly getting closer to
a fully dynamic handling of our memory map!
Let the platform mmu_map_physical_memory the initrd region, and
reserve it before calling mmu_init. This removes another hardcoded
address, since e.g. U-Boot gets the address from the uImage file.
This reverts commit 3fbb24680c.
As I mentioned in #11131, this fix is not correct, and works around
the problem. The real reason was that arch_debug_call_with_fault_handler
was not working properly, so the fault handler went crazy.
With commit eb92810 that is fixed so this can be reverted.
This fixes the problem with KDL freaking out when doing a stacktrace
and having its fault handler triggered. Have no clue how this could
have worked before, but it did :P
As discussed on the ML the limitation of the gap between segments
imposed by this check is completely artifical and pointless.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
cpuid is available in user mode as well and it doesn't look like there
are going to be any x86 platforms with significantly different CPUs anytime
soon.
Signed-off-by: Paweł Dziepak <pdziepak@quarnos.org>
