When CP has a secure channel active, it should never receive a
REPLY_CCRYPT or REPLY_RMAC_I. Since these responses change the SC state,
let's also make sure that they are accepted only when they are
expected: in response to commands CMD_CHLNG and CMD_SCRYPT respectively.
Reported-by: Eran Jacob <eran.jacob@otorio.com>
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
In an effort to shave off code size, remove out-of-the-box
enabling of crypto features (except SHA-256).
Configurations are adjusted to enable what they need.
Bonuses:
- When enabled, AES now defaults to using a smaller version
(`CONFIG_MBEDTLS_AES_ROM_TABLES` isn't default enabled anymore,
and if enabled, `CONFIG_MBEDTLS_AES_FEWER_TABLES` defaults to y).
- Conditions around Mbed TLS Kconfig options have been improved
to reflect the reality of the dependencies.
Signed-off-by: Tomi Fontanilles <tomi.fontanilles@nordicsemi.no>
The 2 issues were found after CONFIG_OSDP_SC_ENABLED was enabled:
- missing curly brace after if
- typo in type name
Signed-off-by: Arkadiusz Wadowski <wadowski.arkadiusz@gmail.com>
slab_buff size is calculated based on size of osdp_ephemeral_data union
so it is safer to use same structure for slab init.
Changes in osdp_event or osd_cmd structures can cause crashes without this.
Signed-off-by: Arkadiusz Wadowski <wadowski.arkadiusz@gmail.com>
Initially, the command/reply ID byte was not part of the data length
macros. But later, when it was changed to include it, the buffer length
checks was not adjusted. Due to this, we were not using the last byte in
the buffer. Fix this issue by correcting the condition.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
Commit c7fec71193 ("mgmt/osdp: Add length checks for commands and
replies") attempted to remove code duplication by adding a macro to perform
a length check. At the time, a CI linter did not like macros with control
flow so the code was switched to a method which called __ASSERT() on this
condition.
The __ASSERT() macro is a nop if CONFIG_ASSERT=n (which is the default) and
causes the buffer access to be unguarded which may lead to OOB accesses.
This patch fixes the issue by reintroducing the if check.
Fixes: c7fec71193.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
rand32.h does not make much sense, since the random subsystem
provides more APIs than just getting a random 32 bits value.
Rename it to random.h and get consistently with other
subsystems.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Modify the signature of the k_mem_slab_free() function with a new one,
replacing the old void **mem with void *mem as a parameter.
The following function:
void k_mem_slab_free(struct k_mem_slab *slab, void **mem);
has the wrong signature. mem is only used as a regular pointer, so there
is no need to use a double-pointer. The correct signature should be:
void k_mem_slab_free(struct k_mem_slab *slab, void *mem);
The issue with the current signature, although functional, is that it is
extremely confusing. I myself, a veteran Zephyr developer, was confused
by this parameter when looking at it recently.
All in-tree uses of the function have been adapted.
Fixes#61888.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Secure Channel Base Key (SCBK) is a secret key used to derive the session
keys used to encrypt and decrypt OSDP packets. Secure coding practice
requires us to clear such sensitive data from stack once we are done
needing it. This patch addresses this issue.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
OSDP secure channel message blocks are terminated with a 0x80. This means
that even for zero length messages, we would have at least one block of
encrypted data to decrypt (since message blocks are rounded up to the next
16 byte boundary). The current length assertion checks for 16 byte
alignment but a malicious peer could send a specially crafted packet with
zero length blocks. Fix this issue by adding check for length == 0 case.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
HID readers are responding to a KEYSET command with an ACK in plaintext
instead of using the current session keys to acknowledge this command
(which is the reasonable thing to do as the command itself was received
encrypted with the old key). Since the spec doesn't say anything about
this, both methods are technically correct.
Make changes to CP so it allows ACKs in plaintext for KEYSET command in
particular and make the PD implementation do this too as it makes the code
look cleaner there (perhaps HID did it for the same reasons :D).
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
If command or reply has no data, PD "should" use secure message types
SCS_15 or SCS_16. But some PD seem to not implement this correctly. We
will be tolerant towards those faulty implementations.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
OSDP command KEYSET is used to set the secure channel base key for all
connected PDs. This key is then used to derive the session keys for each
secure channel session. When the app wants to set the this key, it has
to issue a command and then both the CP/PD has to be notified of this
change so they can store this key in a non-volatile medium for future
operations across power cycles.
The current implementation of OSDP had limited support for key
management. This patch adds all the bells and whistles needed to handle
keyset command/event in the CP/PD application.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
Hoisting a `length--` helps simplify a lot of code which has ad-hoc -1s
in a bunch of places. Also, fix some formatting issues and remove
unnecessary log lines.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
cp_build_command returns the length of the built packet and early
returns for errors. This means there is no need to keep track of return
code in a separate variable -- if we reached the end, we succeeded.
Along with this change, some more changes to enhance maintainability and
readability are also done.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
With changes to the phy layer and the way we build and dispatch
commands, we can now simplify some parts of CP state machine. This patch
builds on previous patches to reduce some state transitions and fixes
some bugs in those paths.
While at it, also implement an exponential back-off for PD offline after
a timeout. This is useful when there is a transient PD timeout but the
PD itself is not totally dead.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
After the check_packet() split from decode_packet() for handling multiple
packets in the RX buffer, PD state machine needed to me modified to
start handling it correctly. While at it, simplify the states as PD does
not have as much state anyways.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
The method send_command was building the packet and also sending it.
This is a problem because even command build failures are reported as
command send failures; although the former can be mitigated by changing
kconfig parameters depending on use cases.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
To handle multiple packets in RX buffer, we need to perform checks on
the buffer first and determine the length of one packet and extact only
that many bytes from the RX buffer instead of pulling everything at
once and failing if there are bytes from the next packet in the buffer.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
When a PD is set online, we need to do other actions along with it. To
make this easier in future, move cp_set_state(pd, OSDP_CP_STATE_ONLINE)
to it's own method cp_set_online(pd).
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
This patch replaces many instances where raw loops were used to copy bytes
with memcpy calls.
No functional change intended.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
Do not check or send the first entry in the pd->cp[] device capability
table which is for function code 0 which is not a defined function code.
Signed-off-by: David Vucich <dave@alcatraz.ai>
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
By default, on errors, pd_decode_command replies with osdp_NAK with
sub-error code set to OSDP_PD_NAK_CMD_LEN (achieved using the ret ==
OSDP_PD_ERR_GENERIC check before return). This is works for all packet
framing errors; but when a more specific error code needs to be sent, ret
has to be set to something other than OSDP_PD_ERR_GENERIC (a suitable error
code happens to be OSDP_PD_ERR_REPLY) to prevent the tail check from
overwriting the error info.
In CMD_KEYSET, we fill a more specific error code but do not set the ret to
OSDP_PD_ERR_REPLY. It causes this error to be reported as a framing
error hence loosing some extended info about the error. Fix this issue by
reordering the checks a bit.
Fixes: 7f4d2c741b "mgmt/osdp: Add support for Secure Channel"
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
Initially, subsys/mgmt had its own STR() macro for string pasting which was
replaced with the zephry provided STRINGIFY(). The definition of this macro
seems to have lingered on so remove it.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
During handshake, only certain types of secure block types (<= SCS_14)
are allowed. A rouge CP/PD can try to bypass the handshake by directly
sending a secure block type ahead of the sequence and gain a secure
channel. Fix this by adding a check in packet decode time.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
OSDP specification section 5.7 states that a transmitting device has to
drive the transmission line to a marking state for a period of one char
in the current baud rate. This can be achieved by sending 0xFF. Since
this is not mentioned in the packet structure definition, many commercial
implementations of OSDP out in the wild do not send/expect this byte.
To work with such non-conforming devices, we will try to be as flexible
as possible in the PD: send mark byte only if the other side sent one. In
case of CP, we have no option but to send the mark byte to be as close
to the specification as possible. If a particular use case needs the CP
to not send it, we will provide a Kconfig option to disable it.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
Now that we have the necessary infrastructure to collect events from PD
apps, we can use them to translate it to OSDP packet sequence for card
reads and key press events.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
OSDP compliant devices communicate their capabilities and discover what
their peer can and cannot do. Right now, PD advertises these capabilities
and expects CP to honor them. Although this is not known to cause any
issues, it is not desirable to allow such accesses.
Add a check of incoming commands to to validate that the corresponding
capability was enabled and advertised.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
Since cmd_data member is used by both commands and events to store the
contents of current transaction, rename it to ephemeral_data which
better reflects the purpose of the variable.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
The CP app sends PD a "command" and the PD responds to it. Some times,
the PD has something that it wants to tell the PD which it does so in
response to POLL command. Both CP and PD apps need a way to exchange
these info over the OSDP bus. To archive this we will introduce what are
called "events" that allow the PD app to enqueue and CP app to get
notified.
This is analogous to the incumbent "commands" abstraction where, the CP
app enqueues a command and the PD app gets notified of it.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
For all commands and replies, the buffer length needed to build or the
length of data needed to decode needs to be checked and asserted. Right now
we do this by ad-hoc if-s. Add macros that do this at a common location.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
The raw, flags check has become a bit excessive and has begun to affect
code readability. Provide inline functions for those accesses that are
frequent. Also, get rid of `struct osdp_cp` as it can be fully represented
by `struct osdp` itself.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
CP has an array of PDs and pd->offset was the position of the PD in CP's
list. Since offset has many meanings, rename it to pd->idx.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
Partial packets in the RX buffers cause the subsequent packet to be
treated as malformed. The RX buffer can have partial data if the sender
is too slow in sending the packet of if there is an interruption in
transmission mid-way.
To avoid any issues due to such partials, flush the uart channel before
sending the command/response.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
The log lines in CP and PD had a prefix such as "CP: " and "PD: " that
does not add too much value as a given device an either be CP or PD
only. This patch removes those and enhances some other log lines while
at it.
It also adds a enum for return values throughout the module to improve
code quality.
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
Add CONFIG_CRC for building CRC related routines.
CRC routines are now being built for each application, whether used or
not and are add in the build system unconditionally.
Keep CONFIG_CRC enabled by default for now and until all users have
converted to use the new option.
Partial fix for #50654
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Move from using Kconfig OSDP_UART_DEV_NAME to a devicetree
chosen property ("zephyr,osdp-uart"). This is similar to a number
of other functions like "zephyr,shell-uart" or "zephyr,bt-uart".
Changed the integration platform for the osdp samples to
stm32_min_dev_black as it already has zephyr,osdp-uart set.
Signed-off-by: Kumar Gala <galak@kernel.org>
Files including <zephyr/kernel.h> do not have to include
<zephyr/zephyr.h>, a shim to <zephyr/kernel.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
According to Kconfig guidelines, boolean prompts must not start with
"Enable...". The following command has been used to automate the changes
in this patch:
sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig*
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This file defines the crypto driver API, cipher is supposed to be just
one type of capability (other can be hash) of these drivers, just
change the file name to be consistent with it.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Since 581c20e242 ("drivers: uart: Cleanup not supported API handling")
uart_fifo_read() returns -ve on errors. Correct the check on its return
value to work with this new API.
CID: 240662
Fixes: #39840
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
A previous check and return for (maxlen <= 0) makes manlen at least 1 so
checks for (maxlen < 1) would never evaluate to true. Remove these
checks and merge those cases into one.
CID: 215392
Fixes: #33092
Signed-off-by: Siddharth Chandrasekaran <siddharth@embedjournal.com>
