Assign inode values properly in AuthFS

Previously, inode_table provides inode -> entry mapping, and the inode
value is derived from the entry name, which is supposed to be the remote
FD value. That is, remote FD was equal to the filesystem entry name as
string and the actual inode value inside the filesystem.

This change makes inode an internal notion in the filesystem, which is
really the correct way. When a client provides the path -> entry mapping
(root_entries), AuthFS now breaks it into two mappings (see below) and
assigns the inode for its own internal purpose.

To look up an entry in to root directory, we use the path -> inode
table (root_entries) to find the inode, then look for the actual entry
with the inode -> entry table (inode_table).

This gives us the freedom to add more inodes without risking breaking
existing entries. It also makes it possible to create inodes not
backing by a remote FD. For example, later we could open file by path
like "framework/framework.jar" relative to a path FD of /system on the
host side. That is, we wouldn't necessarily need to open
"/system/framework" and create an inode, then use that inode to open
"framework.jar".

Bug: 203251769
Test: atest AuthFsHostTest
Change-Id: I49b222b91002da12a25fbf03b0c6285f0223f16b
2 files changed
tree: 7776d1cbe70242d72bfe77ccbdc4113b61de2717
  1. apex/
  2. apkdmverity/
  3. apkverify/
  4. authfs/
  5. binder_common/
  6. compos/
  7. demo/
  8. docs/
  9. idsig/
  10. javalib/
  11. launcher/
  12. libs/
  13. microdroid/
  14. microdroid_manager/
  15. pvmfw/
  16. tests/
  17. virtualizationservice/
  18. vm/
  19. vmconfig/
  20. zipfuse/
  21. .clang-format
  22. Android.bp
  23. OWNERS
  24. PREUPLOAD.cfg
  25. README.md
  26. TEST_MAPPING
README.md

Virtualization

This repository contains userspace services related to running virtual machines on Android, especially protected virtual machines. See the getting started documentation and Microdroid README for more information.