The new mem pool implementation has a hard minimum block size of 8
bytes, but the macros to statically compute the number of levels
didn't clamp, leading to invalid small allocations being allowed,
which would then corrupt the list pointers of nearby blocks and/or
overflow the buffer entirely and corrupt other memory.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add support to the Configuration Client Model for getting and setting
1-byte states (which can be nicely generalized in code) as well as the
2-byte Relay state.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
As the number of mesh APIs grows it becomes a bit cumbersome to have
everything in a single header file. Split the mesh.h header file into
multiple files in a new mesh subdirectory, and include the new headers
from the old one to retain backwards compatibility and simplicity for
apps (they only need to include <bluetooth/mesh.h>).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
In http_request() a CRLF is added to the header information after
the protocol is added. 2 CRLF in a row means the header information
is done, so following header information will be ignored.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
Add status error string when sending a error message from
HTTP server to client as described in RFC 2616 ch 6.1.
Previously only error code was sent except for 400 (Bad Request).
This also fixes uninitialized memory access in error message.
Coverity-CID: 178792
Fixes#4782
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Avoid applications defining empty model arrays by themselves by
documenting the BT_MESH_MODEL_NONE helper macro (renamed to be more
intuitive) and using it in the mesh sample app.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
It may be useful for the app to know when the provisioning link is
active and when it has been closed. This can be used e.g. to signal
the user the state of the device. Some PTS tests also require
verifying the link state.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The only messages that should be encrypted using the friendship
credentials are those coming through the Friend Queue on the Friend
node, most request-response pairs between LPN & Friend (exceptions are
Friend Request - Friend Offer, and Friend Clear - Friend Clear
Confirm), as well as Model Publication messages when the Friendship
Credentials Flag has been enabled in the model publication.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When sending a packet with AR flag set, the ACK frame that should be
replied to it must holp the same sequence number, so let's verify this
properly.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Added architecture specific support for memory domain destroy
and remove partition for arm and nxp. An optimized version of
remove partition was also added.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This is intended for memory-constrained systems and will save
4K per thread, since we will no longer reserve room for or
activate a kernel stack guard page.
If CONFIG_USERSPACE is enabled, stack overflows will still be
caught in some situations:
1) User mode threads overflowing stack, since it crashes into the
kernel stack page
2) Supervisor mode threads overflowing stack, since the kernel
stack page is marked non-present for non-user threads
Stack overflows will not be caught:
1) When handling a system call
2) When the interrupt stack overflows
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Besides the fact that we did not have that for the current supported
boards, that makes sense for this new, virtualized mode, that is meant
to be run on top of full-fledged x86 64 CPUs.
By having xAPIC mode access only, Jailhouse has to intercept those MMIO
reads and writes, in order to examine what they do and arbitrate if it's
safe or not (e.g. not all values are accepted to ICR register). This
means that we can't run away from having a VM-exit event for each and
every access to APIC memory region and this impacts the latency the
guest OS observes over bare metal a lot.
When in x2APIC mode, Jailhouse does not require VM-exits for MSR
accesses other that writes to the ICR register, so the latency the guest
observes is reduced to almost zero.
Here are some outputs of the the command line
$ sudo ./tools/jailhouse cell stats tiny-demo
on a Jailhouse's root cell console, for one of the Zephyr demos using
LOAPIC timers, left for a couple of seconds:
Statistics for tiny-demo cell (x2APIC root, x2APIC inmate)
COUNTER SUM PER SEC
vmexits_total 7 0
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_msr 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xapic 0 0
vmexits_xsetbv 0 0
Statistics for tiny-demo cell (xAPIC root, xAPIC inmate)
COUNTER SUM PER SEC
vmexits_total 4087 40
vmexits_xapic 4080 40
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_msr 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xsetbv 0 0
Statistics for tiny-demo cell (xAPIC root, x2APIC inmate)
COUNTER SUM PER SEC
vmexits_total 4087 40
vmexits_msr 4080 40
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xapic 0 0
vmexits_xsetbv 0 0
See that under x2APIC mode on both Jailhouse/root-cell and guest, the
interruptions from the hypervisor are minimal. That is not the case when
Jailhouse is on xAPIC mode, though. Note also that, as a plus, x2APIC
accesses on the guest will map to xAPIC MMIO on the hypervisor just
fine.
Signed-off-by: Gustavo Lima Chaves <gustavo.lima.chaves@intel.com>
This is an introductory port for Zephyr to be run as a Jailhouse
hypervisor[1]'s "inmate cell", on x86 64-bit CPUs (running on 32-bit
mode). This was tested with their "tiny-demo" inmate demo cell
configuration, which takes one of the CPUs of the QEMU-VM root cell
config, along with some RAM and serial controller access (it will even
do nice things like reserving some L3 cache for it via Intel CAT) and
Zephyr samples:
- hello_world
- philosophers
- synchronization
The final binary receives an additional boot sequence preamble that
conforms to Jailhouse's expectations (starts at 0x0 in real mode). It
will put the processor in 32-bit protected mode and then proceed to
Zephyr's __start function.
Testing it is just a matter of:
$ mmake -C samples/<sample_dir> BOARD=x86_jailhouse JAILHOUSE_QEMU_IMG_FILE=<path_to_image.qcow2> run
$ sudo insmod <path to jailhouse.ko>
$ sudo jailhouse enable <path to configs/qemu-x86.cell>
$ sudo jailhouse cell create <path to configs/tiny-demo.cell>
$ sudo mount -t 9p -o trans/virtio host /mnt
$ sudo jailhouse cell load tiny-demo /mnt/zephyr.bin
$ sudo jailhouse cell start tiny-demo
$ sudo jailhouse cell destroy tiny-demo
$ sudo jailhouse disable
$ sudo rmmod jailhouse
For the hello_world demo case, one should then get QEMU's serial port
output similar to:
"""
Created cell "tiny-demo"
Page pool usage after cell creation: mem 275/1480, remap 65607/131072
Cell "tiny-demo" can be loaded
CPU 3 received SIPI, vector 100
Started cell "tiny-demo"
***** BOOTING ZEPHYR OS v1.9.0 - BUILD: Sep 12 2017 20:03:22 *****
Hello World! x86
"""
Note that the Jailhouse's root cell *has to be started in xAPIC
mode* (kernel command line argument 'nox2apic') in order for this to
work. x2APIC support and its reasoning will come on a separate commit.
As a reminder, the make run target introduced for x86_jailhouse board
involves a root cell image with Jailhouse in it, to be launched and then
partitioned (with >= 2 64-bit CPUs in it).
Inmate cell configs with no JAILHOUSE_CELL_PASSIVE_COMMREG flag
set (e.g. apic-demo one) would need extra code in Zephyr to deal with
cell shutdown command responses from the hypervisor.
You may want to fine tune CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC for your
specific CPU—there is no detection from Zephyr with regard to that.
Other config differences from pristine QEMU defaults worth of mention
are:
- there is no HPET when running as Jailhouse guest. We use the LOAPIC
timer, instead
- there is no PIC_DISABLE, because there is no 8259A PIC when running
as a Jailhouse guest
- XIP makes no sense also when running as Jailhouse guest, and both
PHYS_RAM_ADDR/PHYS_LOAD_ADD are set to zero, what tiny-demo cell
config is set to
This opens up new possibilities for Zephyr, so that usages beyond just
MCUs come to the table. I see special demand coming from
functional-safety related use cases on industry, automotive, etc.
[1] https://github.com/siemens/jailhouse
Reference to Jailhouse's booting preamble code:
Origin: Jailhouse
License: BSD 2-Clause
URL: https://github.com/siemens/jailhouse
commit: 607251b44397666a3cbbf859d784dccf20aba016
Purpose: Dual-licensing of inmate lib code
Maintained-by: Zephyr
Signed-off-by: Gustavo Lima Chaves <gustavo.lima.chaves@intel.com>
The old HTTP server and client library code is deprecated. The
new HTTP library will be based on net-app API code which requires
changes to function names and parameters that are not compatible
with old library.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Create http library that uses net-app instead of net_context
directly. The old HTTP API is deprecated.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Now that net_buf has "native" support for sys_slist_t in the form of
the sys_snode_t member, there's a danger people will forget to clear
out buf->frags when getting buffers from a list directly with
sys_slist_get(). This is analogous to the reason why we have
net_buf_get/put APIs instead of using k_fifo_get/put.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Rename net_pkt_get_src_addr() to net_pkt_get_addr() and make it able to
handle source or destination address.
Signed-off-by: Aska Wu <aska.wu@linaro.org>
Add support for loading IRKs into the controller as well as the LE
Enhanced Connection Complete HCI event. To simplify things, the old LE
Connection Complete handler translates its event into the new enhanced
one which is then the single place of processing new connection
events.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Kernel object metadata had an extra data field added recently to
store bounds for stack objects. Use this data field to assign
IDs to thread objects at build time. This has numerous advantages:
* Threads can be granted permissions on kernel objects before the
thread is initialized. Previously, it was necessary to call
k_thread_create() with a K_FOREVER delay, assign permissions, then
start the thread. Permissions are still completely cleared when
a thread exits.
* No need for runtime logic to manage thread IDs
* Build error if CONFIG_MAX_THREAD_BYTES is set too low
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
GPIO_PIN_ENABLE, GPIO_PIN_DISABLE configuration constants overlap
functionality provided by pinmux driver. They usage makes the API
inconsistent. They are almost uniformly ignored by the existing device
drivers. Only few of them take these constants into account.
This commit deprecates usage of the two configuration constants.
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
This adds CONFIG_EXECUTE_XOR_WRITE, which is enabled by default on
systems that support controlling whether a page can contain executable
code. This is also known as W^X[1].
Trying to add a memory domain with a page that is both executable and
writable, either for supervisor mode threads, or for user mode threads,
will result in a kernel panic.
There are few cases where a writable page should also be executable
(JIT compilers, which are most likely out of scope for Zephyr), so an
option is provided to disable the check.
Since the memory domain APIs are executed in supervisor mode, a
determined person could bypass these checks with ease. This is seen
more as a way to avoid people shooting themselves in the foot.
[1] https://en.wikipedia.org/wiki/W%5EX
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Headers should only be pulling in other headers if that header
needs it somewhere in its contents. Otherwise, pulling in other
headers should be done by C files to avoid extremely difficult
dependency loops (in this case, the main kernel.h and arch/cpu.h
on ARM)
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We need to start enforcing everywhere that kernel.h depends on
arch/cpu.h and any header included in the arch/cpu.h space cannot
depend on kernel.h.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We were unnecessarily pulling in headers which resulted in kernel.h
being pulled in, which is undesirable since arch/cpu.h pulls in
these headers.
Added integral type headers since we do need those.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
kernel.h depends on arch.h, and reverse dependencies need to be
removed. Define k_tid_t as some opaque pointer type so that arch.h
doesn't have to pull in kernel.h.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This header needs Zephyr's specific type definitions. It also
needs struct k_mem_partition and struct k_mem_domain, but they
are defined opaquely here instead of pulling in kernel.h (which
would create nasty dependency loops)
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This should clear up some of the confusion with random number
generators and drivers that obtain entropy from the hardware. Also,
many hardware number generators have limited bandwidth, so it's natural
for their output to be only used for seeding a random number generator.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Some "random" drivers are not drivers at all: they just implement the
function `sys_rand32_get()`. Move those to a random subsystem in
preparation for a reorganization.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Add a net_buf_id() API which translates a buffer into a zero-based
index, based on its placement in the buffer pool. This can be useful
if you want to associate an external array of meta-data contexts with
the buffers of a pool.
The added value of this API is slightly limited at the moment, since
the net_buf API allows custom user-data sizes for each pool (i.e. the
user data can be used instead of a separately allocated meta-data
array). However, there's some refactoring coming soon which will unify
all net_buf structs to have the same fixed (and typically small)
amount of user data. In such cases it may be desirable to have
external user data in order not to inflate all buffers in the system
because of a single pool needing the extra memory.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Andy Ross