Some of the recent refactoring may cause some of the inner error codes
to be eaten or misinterpreted. Restructure fread/fwrite to handle these
a bit more gracefully.
There's some careful use with ssize_t vs size_t here to try to deal with
negatves values properly.
Instead of one large routine that takes a list of optional callbacks,
build some helper routines that do the work that a few platforms have
implemented on their own to share some code between them.
Future enhancements: move some of the helpers out of this library into
the library that implements the thing it's helping with (ie, PCI
bringup, bootstrapping arch specific cores). For now just leave them in
helper.cc which is conditionally compiled.
More code is using it, so try to build a more standardized version of
it. For now, since most of the defines that are needed are similar to
lk/compiler.h, mostly reimplement in terms of those.
Need to move `size_t i` into the correct location. Also, set the
CONSOLE_OUTPUT_TO_PLATFORM_PUTC define in the module makefile.
Change-Id: I732ebbcc43219806d5dfd3b9bdd28bf1811248dc
dw/mw and the sister commands take virtual address as input for display
or modify. Option "-p" to the command signifies the address input is
physical, and the address translation is handled by the command.
Newly added option is available with WITH_KERNEL_VM, usage as follows
] dw 0xffffffff05100000 4
0xffffffff05100000: 0000dead
] dw 0x5100000 4 -p
0xffffffff05100000: 0000dead
Signed-off-by: VAMSHI GAJJELA <vamshigajjela@google.com>
Introduces a flag which allows a project to disable the default output
to platform_dputc. This is useful is the project wants to maintain
`platform_dputc` for panic conditions but otherwise use a registered
callback for console io.
Change-Id: I1362529a6bb40d191ac3f7c6069985c371d9284c
The wrong placement of the increment for index `i` causes an unexpected
behavior, which the `strncpy` writes an extra '\0'.
For example:
The `src` string is "abc". The buffer size of `dest` is 5.
When we call `strncpy(dest, src, 5)`, the first `for` loop copies the
characters, 'a', 'b', and 'c', to the `dest[0:2]`. In the 4th iteration,
however, the `for` loop breaks due to the termination of `src` whereas
the value of `i` stays 3. At the moment, it has copied 4 bytes,
including the '\0' of `src`.
In the second `for` loop, we have `i = 3` and `count = 5`, so the loop
copies two more '\0' to the `dest`. As a result, the `strncpy` copies 6
bytes to the `dest` buffer, leading to buffer overflow.
Fix the issue by increasing the index `i` before every copy.
Signed-off-by: Cody Wong <codycswong@google.com>
Two handlers accidentally had the wrong prototype, called the wrong
thing and/or had the wrong name.
Should only affect divrem_overflow_abort, negate_overflow_abort.
Add an UBSAN implementation and a new UBSAN switch to the make build.
The implementation is taken from Onyx and handles most of the cases
that should be needed for a kernel build. Floating point and fancy
C++ CFI features are not supported yet.
To build with UBSAN, pass UBSAN=1 to make such as:
PROJECT=pc-x86-64-test make -jN UBSAN=1
Accessing un-mapped address/address-range results in data abort. Ensure
the address and all the pages in the requested range are mapped. Mapping
is checked at page size, also adjusts the stop address to the nearest valid
address mapped.
The old method assumed that all of the tables were mapped within the
kmap area of the kernel. This basically works on 64bit machines but on a
32bit x86 its entirely likely the ACPI tables are at higher physical
addresses that can be reached, which is currently limited to 1GB.
By using the VM it means it can individually map the headers and each
individual table.
Have the arch define additional compiler flags to explicit support or
not support a floating point unit.
Add ability for modules to per file or for the whole module mark code
as needing floating point support.
Add default flags for arm64, riscv, and x86 toolchains.
Needed because gcc 12 is getting much more aggressive about using vector
instructions for non float code, so getting away with avoiding it was
no longer working.
Still not perfect: printf code is being compiled with float, so it's
possible to use floating point instructions inside core kernel or
interrupt handling code if a printf is used.
Possibly will have problems on architectures where mixing float and non
float code at the linker generates issues, but so far seems to be okay.
GCC 12 seems to be much more aggressive about warnings about any
dereferences near 0. For this particular piece of code, which is
explicitly trying to force a fault by touching address 1, simply disable
the warning around the block of code.
Move more of the driver into a proper object oriented model.
Start to build the structure to track open file/dirs so as to
allow multiple open instances share the same underlying object.
