The NMI IRQ (-14) is denied run-time registration

[sherrellbc]

Some platforms, like the K64F development kit, have mapped hardware buttons to the NMI (IRQ# -14). The current uVisor implementation has defined unvic_default_check which performs an unsigned comparison against the architecture-specific constant NVIC_VECTORS.

static void unvic_default_check(uint32_t irqn)
{
    /* IRQn goes from 0 to (NVIC_VECTORS - 1) */
    if(irqn >= NVIC_VECTORS)
    {
        HALT_ERROR(NOT_ALLOWED,
                   "Not allowed: IRQ %d is out of range\n\r", irqn);
    }

    /* check if uvisor does not already own the IRQn slot */
    if(g_isr_vector[NVIC_OFFSET + irqn] != &isr_default_handler)
    {
        HALT_ERROR(PERMISSION_DENIED,
                   "Permission denied: IRQ %d is owned by uVisor\n\r", irqn);
    }
}

The unsigned comparison, by definition, assumes the requested registration is for a positive entry. Although interrupts -1 through -13 are critical to system integrity and should be managed by uVisor, the NMI interrupt, in this case, should have a special case exception.

[AlessandroA]

Hi @sherrellbc, this is intentional. For the moment, we decided not to support the NMI as it does not follow the general priority rules of other user IRQs (from 0 up). Interrupts with special features should be treated with special care as they represent a security threat (in this case, the IRQ cannot be pre-empted, so a malicious box owning it would starve the rest of the system).

On the K64F, the current workaround is to use the SW2 push-button, as usually done by our sample apps, like here.

Since it's still desirable to support the NMI at some point, I'll leave this issue open and mark it as a feature request.