Handle HCR_EL2.E2H RES1 behaviour
An implementation is allowed to make HCR_EL2.E2H RES1, which means
that the CPU behaves as if this bit was 1, even if it reads as 0
or can be written with 0.
While the architecture advertises this via ID_AA64MMFR4_EL1.E2H0,
hypervisors cannot always expose this to a guest if the hardware
doesn't implemtn FEAT_FGT.
Instead, detect the effects of HCR_EL2.E2H being RES1 by checking
for the aliasing property between accessors targetting the same
register (FAR_ELx in this case). This gives a reliable litmus test
for CPUs that are stuck in VHE mode.
From Marc Zyngier <maz at kernel.org>
When running in VHE host mode, HCR_EL2.TGE must be set, as otherwise
a bunch of problems occur:
- EL0 is guest EL0, not host, and the kernel will catch fire on the
first ERET to EL0
- EL1 TLB invalidations target the guest, and not the host
Make sure that HCR_EL2.TGE is set, instead of relying on firmware
to have set it (when booting with UEFI, only the first CPU is
correctly configured).
From Marc Zyngier <maz at kernel.org>
When printing a CCR's ManifestState, sort the entries by AKI
Sorting this particular listing by AKI (instead of by hash of the
Manifest object) makes diffs between CCRs much more readable.
With & OK tb@
Add checks for invalid dir count and max size for readdir/readdirplus.
A zero count or max size value is now rejected early instead of
relying on VOP_GETATTR to return an error. Also verify that the
max size after rounding up to a multiple of DIRBLKSIZ is positive.
A negative value would turn into a large allocation, causing the
malloc() to fail.
From an LLM bug report. With help from miod@ and kirill@.
verifier: re-enable the callback override for depth
kirill reported that his nginx reverse proxy setup stopped working
with x509_verify.c r1.74 and r1.75. It turns out that nginx relies
on a verify callback that always returns 1.
In revision 1.74 we removed the possibility of the verify_cb() to
override X509_V_ERR_CERT_CHAIN_TOO_LONG, which is what breaks the
config in kirill's setup since it used to use the nginx default of
setting the depth to 1. Re-enable this to make the new scenario
"2a with depth 1 and depth callback" pass.
As shown by the other new test scenario "14b with yolo calback"
with a "just say yes" cb, the guard added in r1.74 still prevents
the overwrite.
This makes kirill's reproducer work as verified by kirill and myself.
It was also tested by kirill in the real life setup.
[2 lines not shown]
libcrypto: extend verify and callback regress
Add three more test variants for scenario 2a:
1) verify that a chain of length 3 validates with depth 2.
2) verify that a chain of length 3 fails to validate with depth 1.
3) verify that a chain of length 3 validates with depth 1 if we
allow the callback to override the depth.
Variant 3) fails in -current and reproduces a scenario reported
by kirill.
Also add two test variants for the scenarios in 14:
4): run the chain of length 32 with a yolo callback returning 1
5): run the chain of length 33 with a yolo callback returning 1
Test 5) fails because we currently bail out at the wrong depth.
The verify callback should allow overriding the failure and will
[7 lines not shown]
verify regress: allow setting verify depth and callback
This is pretty ugly and probably the the vct should be handed down to
the verify_cert*() functions, but this works and doesn't make these
tests any uglier than they already are.
The callback regress was modified with a least effort approach.
Prevent unsigned underflow leading to a crash.
An IA_PD option contains one or more nested dhcp options.
We first need to make sure that the length field of the option header
does not point outside of the encapsulating option, which we did.
When we then parse the nested options we need to make sure that nested
option header length field is large enough for the nested option, not
that the encapsulating option length is large enough for the
encapsulated option.
Otherwise opt_hdr.len - 2 can underflow, which strvisx(3) interprets
as a size_t, i.e. a very large number, leading to a crash once we hit
a guard.
Underflow pointed out by an AI tool (sorry, don't know which one) in a
somewhat convoluted way. It also provided an reproducer for the issue
which was more helpful.
[6 lines not shown]
