- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 5 2021
Mar 9 2021
Mar 7 2021
Mar 4 2021
Feb 28 2021
Feb 3 2021
Feb 1 2021
Jan 31 2021
Jan 30 2021
Jan 26 2021
Jan 23 2021
Jan 22 2021
Jan 19 2021
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.
Jan 14 2021
Remove unused include dir and fix armv8crypto build when included in a kernel config
Jan 13 2021
Sync to the latest HEAD:
- Address mhorne's comments
Jan 6 2021
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.
Jan 4 2021
Dec 30 2020
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.
Dec 15 2020
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.
Dec 14 2020
Move AES-GCM support to armv8crypto acceleration module
Dec 13 2020
Dec 10 2020
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.
Dec 9 2020
Dec 4 2020
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
Dec 3 2020
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.
Dec 1 2020
vm.phys_segs: SEGMENT 0:
Nov 26 2020
In D27152#606416, @mhorne wrote:Looks good to me overall.
Address commends from mhorne@
Nov 25 2020
Nov 9 2020
Nov 4 2020
Oct 26 2020
No longer relevant
Oct 22 2020
Sep 7 2020
Overall it looks OK to me.
Sep 6 2020
Sep 4 2020
Aug 31 2020
- Fix memory leak
- Handle error case
Aug 28 2020
Aug 25 2020
Aug 15 2020
Fix all comments from reviewrs
Aug 14 2020
Aug 10 2020
Aug 8 2020
Fix all issues mentioned by manu@