The FPGA gateware region is blocked from trivial readout via USB:
this makes it a tiny bit harder to obtain the gateware image, which
contains the secret keys. This slightly aids users who haven't
burned any efuse keys and are using the default "null" key from
a trivial readout attack, and it also hampers a WBSTAR exploit.
This makes the most convenient path of attack to be loading
a custom xous.img (or otherwise exploiting the kernel) with
a gadget that is capable of reading the gateware region
through priveleged code, and then relaying it over USB through
some run-around of the firewall. This primitive isn't impossible
to create but it doesn't exist and has no use in a normal
operational flow, so, it's going to at least force an attacker
to write some code, as opposed to using off the shelf utilities
we provide.
I had thought there was an issue with heap size limit increases
and multithreading but I think actually the problem is the
PDDB runs pretty close to the stack size limit. This increases
the stack size limit for the PDDB on boot and also bumps up
the heap limit so caching can work more flawlessly.
the core now enumerates after a suspend/resume cycle, although
sometimes it takes two tries for the enumeration to go all the way
through. not sure why, yet.
In retrospect forcing apps to manage their suspend in resume
crosses too many abstraction barriers.
Instead, the app should specify the mode of the hardware, but
then the driver should be responsible for restoring that state
on resume, not the app.
Instead of writing `Some(Opcode::*)` repeatedly, change it to simply
match against `Opcode::*`. This is accomplished by defining a new opcode
`Invalid` that will be matched against as a default.
Signed-off-by: Sean Cross <sean@xobs.io>
The new ordering remains the same size, but is no longer
`#[repr(packed)]`. This allows it to be `#[repr(align(4096))]` which
means we can get away with using a stack page for this struct instead of
allocating a new object every time.
Signed-off-by: Sean Cross <sean@xobs.io>
takes about 1MiB of heap to decode the test PNG.
Putting the heap increase at boot seems to not
work, it causes other processes to not spawn. The condition
is not terribly reproducible, so it's probably a concurrency
issue of some type.
perfomance regression on the PDDB with the latest fixes make
the device stop passing compliance when the database grows
to about 40-ish keys. For now, we set the cred limit to 32,
until the performance issues are addressed. (note that yubico
has a limit of 25 credentials, so, 32 is not insanely low).
The behavior with a secret basis is as follows:
- The key stays in the basis in which it was created.
- So, if you created k1 in .System basis, and k2 in Secret basis,
if you edit k1 while Secret basis is open, k1 stays in .System
basis. it does *not* migrate into Secret basis.
I think this is the "least surprising" behavior. There is an
argument that "maybe I want to keep secret notes in an overlay
on a key" but I feel like creating a second shadow copy of a key
with a different set of notes is not the most desired behavior
for this application (NB: it could be desired for others applications,
and that behavior can be programmed with the PDDB API; which is
why the API is a bit explicit at the moment. This flexibility goes
against the goal of "foolproof deniability", unfortunately, but
I think it is too early to know which default to set for the system).
