But if kernel can access it - then it's not secure? I thought PSCI and secure monitors were supposed to be handled at a boot loader stage and be inaccessible even to the running kernel. FDT reservations were more like advisory thing (at least on RPi) to keep kernel from trampling over data in them. If kernel/module can access it, there is no reason not to provide access through /dev/mem.

Remove unused include dir and fix armv8crypto build when included in a kernel config

Sync to the latest HEAD:

• Address mhorne's comments

In D27454#624438, @mhorne wrote:

Hi @gonzo,

I'm looking at D21017, which adds AES-XTS support to armv8_crypto, and has been sitting in review for some time.

I am hoping to get it committed soon, but wanted to get your attention here as it will create some small conflicts with this patch. Let me know if you have any major concerns about that, I'm happy to accommodate so that we might get both of these patches in before 13 branches.

Revert back to the correct diff

• Add Allwinner codecs and I2S driver as an example for the framework usage
• simple-amplifier: make gpio-enable optional

• Add Allwinner codecs and I2S driver as an example for the framework usage
• simple-amplifier: make gpio-enable optional

Committed to main: https://reviews.freebsd.org/R10:e523262107865130e40fb19f7c3c571c8dd0b252

Since there seem to be no low-impact fix for this in pmap,
I think the way to go is to introduce stricter dmap check that
should be used to verify addresses that are not allocated
by the kernel's VM subsystem.

Check if region in dmap is actually present and not a "hole". Also
use pmap_mapdev to handle non-dmap physical addr accesses (as in amd64 code)
because uiomove_fromphys also avoid creating ephemeral mappings using
a check that fails on sparse dmap.

Remove check for dmap in pmap_kextract so it can handle
faults in the missing regions of the sparse dmap.

Move AES-GCM support to armv8crypto acceleration module

Ah, I think I misunderstood. By removing DMAP check, did you mean the one in pmap_kextract?

Thanks for the explanation. It's more complex than I expected then. So far this issue was relevant only for the /dev/mem scenario, where acpidump -dt was getting stuck in an unkillable state. If /dev/mem can avoid this situation then the fix is not strictly required.

pmap_kextract does not do any checks if the area belongs to the sparse map or not, it just does arithmetic based on the base addresses.

In D27528#615421, @andrew wrote:

What will happen if we try to access a DMAP page during the break-before-make sequence while it is being demoted?

In D27529#615463, @andrew wrote:

I would prefer we don't map memory marked as noalloc in the DMAP. If we need to read it in /dev/mem then mem.c should handle unmapped memory within the DMAP region.

Both patches, updated to the latest HEAD:
https://people.freebsd.org/~gonzo/patches/D21636-updated.diff
https://people.freebsd.org/~gonzo/patches/D21648-updated.diff

In D27454#613768, @jhb wrote:

You would be better off adding AES-GCM support to an OCF driver for arm64 instead. I'm currently looking at retiring the software interface for KTLS and instead only using OCF for software KTLS. In addition, AES-GCM support in OCF would also benefit other use cases like IPsec and ZFS.

That said, my thoughts for arm64 AES-GCM support was to extend ossl(4) to support AES-GCM and use that. However, you could take your AES-GCM implementation and add it to armv8crypto(4).

Hello, any chance of this patch and D21648 getting committed before 13.0 freeze is in effect? I tested both changes against the latest HEAD (with some minor clean-up) and the functionality seems to work.

This is an almost ready version to get the initial discussion going. I'd like to get it in shape for HEAD before 13.0 freeze. There are still some issues.

In D27152#606416, @mhorne wrote:

Looks good to me overall.

Address commends from mhorne@

No longer relevant

Overall it looks OK to me.

• Fix memory leak
• Handle error case

Fix all comments from reviewrs

Fix all issues mentioned by manu@