Current design only supports single source range.
We receive a request with REQ_OP_COPY_DST.
Parse this request which consists of dst(1st) and src(2nd) bios.
Form a copy command (TP 4065)
trace event support for nvme_copy_cmd.
Set the device copy limits to queue limits.
Signed-off-by: Kanchan Jos
Add support for handling nvme_cmd_copy command on target.
For bdev-ns we call into blkdev_copy_offload, which the block layer
completes by a offloaded copy request to backend bdev or by emulating the
request.
For file-ns we call vfs_copy_file_range to service our request.
Currently target always
Hi Nitesh,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 53cdf865f90ba922a854c65ed05b519f9d728424]
url:
https://github.com/intel-lab-lkp/linux/commits/Nitesh-Shetty/block-Introduce-queue-limits-for-copy-offload-support/20230628-163126
base
Hi Nitesh,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 53cdf865f90ba922a854c65ed05b519f9d728424]
url:
https://github.com/intel-lab-lkp/linux/commits/Nitesh-Shetty/block-Introduce-queue-limits-for-copy-offload-support/20230628-163126
base
On Tue, 27 Jun 2023 20:28:01 +, Matthias Kaehlcke wrote:
> Add a NULL check for the 'bdev' parameter of
> dm_verity_loadpin_is_bdev_trusted(). The function is called
> by loadpin_check(), which passes the block device that
> corresponds to the super block of the file system from which
> a fil
From: Deven Bowers
IPE is designed to provide system level trust guarantees, this usually
implies that trust starts from bootup with a hardware root of trust,
which validates the bootloader. After this, the bootloader verifies the
kernel and the initramfs.
As there's no currently supported integ
From: Deven Bowers
As is typical with LSMs, IPE uses securityfs as its interface with
userspace. for a complete list of the interfaces and the respective
inputs/outputs, please see the documentation under
admin-guide/LSM/ipe.rst
Signed-off-by: Deven Bowers
Signed-off-by: Fan Wu
---
v2:
+ Sp
From: Deven Bowers
Some block devices have valuable security properties that is only
accessible during the creation time.
For example, when creating a dm-verity block device, the dm-verity's
roothash and roothash signature, which are extreme important security
metadata, are passed to the kernel.
Overview:
-
IPE is a Linux Security Module which takes a complimentary approach to
access control. Whereas existing mandatory access control mechanisms
base their decisions on labels and paths, IPE instead determines
whether or not an operation should be allowed based on immutable
security
From: Deven Bowers
Enables an IPE policy to be enforced from kernel start, enabling access
control based on trust from kernel startup. This is accomplished by
transforming an IPE policy indicated by CONFIG_IPE_BOOT_POLICY into a
c-string literal that is parsed at kernel startup as an unsigned pol
When deleting a directory in the security file system, the existing
securityfs_remove requires the directory to be empty, otherwise
it will do nothing. This leads to a potential risk that the security
file system might be in an unclean state when the intentded deletion
did not happen.
This commit
From: Deven Bowers
dm-verity provides a strong guarantee of a block device's integrity. As
a generic way to check the integrity of a block device, it provides
those integrity guarantees to its higher layers, including the filesystem
level.
An LSM that control access to a resource on the system b
From: Deven Bowers
IPE, like SELinux, supports a permissive mode. This mode allows policy
authors to test and evaluate IPE policy without it effecting their
programs. When the mode is changed, a 1404 AUDIT_MAC_STATUS
be reported.
This patch adds the following audit records:
audit: MAC_STATU
From: Deven Bowers
Users of IPE require a way to identify when and why an operation fails,
allowing them to both respond to violations of policy and be notified
of potentially malicious actions on their systems with respect to IPE
itself.
This patch introduces 3 new audit events.
AUDIT_IPE_ACCE
From: Deven Bowers
Integrity Policy Enforcement (IPE) is an LSM that provides an
complimentary approach to Mandatory Access Control than existing LSMs
today.
Existing LSMs have centered around the concept of access to a resource
should be controlled by the current user's credentials. IPE's appro
Enable IPE policy authors to indicate trust for a singular fsverity
file, identified by the digest information, through "fsverity_digest"
and all files using fsverity's builtin signatures via
"fsverity_signature".
This enables file-level integrity claims to be expressed in IPE,
allowing individual
From: Deven Bowers
Allows author of IPE policy to indicate trust for a singular dm-verity
volume, identified by roothash, through "dmverity_roothash" and all
signed dm-verity volumes, through "dmverity_signature".
Signed-off-by: Deven Bowers
Signed-off-by: Fan Wu
---
v2:
+ No Changes
v3:
From: Deven Bowers
Add various happy/unhappy unit tests for both IPE's parser.
Signed-off-by: Deven Bowers
Signed-off-by: Fan Wu
---
v1-v6:
+ Not present
v7:
Introduced
v8:
+ Remove the kunit tests with respect to the fsverity digest, as these
require significant changes to work w
From: Deven Bowers
IPE's interpretation of the what the user trusts is accomplished through
its policy. IPE's design is to not provide support for a single trust
provider, but to support multiple providers to enable the end-user to
choose the best one to seek their needs.
This requires the polic
fsverity represents a mechanism to support both integrity and
authenticity protection of a file, supporting both signed and unsigned
digests.
An LSM which controls access to a resource based on authenticity and
integrity of said resource, can then use this data to make an informed
decision on the
From: Deven Bowers
IPE's initial goal is to control both execution and the loading of
kernel modules based on the system's definition of trust. It
accomplishes this by plugging into the security hooks for
bprm_check_security, file_mprotect, mmap_file, kernel_load_data,
and kernel_read_data.
Sign
From: Deven Bowers
IPE must have a centralized function to evaluate incoming callers
against IPE's policy. This iteration of the policy for against the rules
for that specific caller is known as the evaluation loop.
Signed-off-by: Deven Bowers
Signed-off-by: Fan Wu
---
v2:
+ Split evaluation
From: Deven Bowers
Add IPE's admin and developer documentation to the kernel tree.
Co-developed-by: Fan Wu
Signed-off-by: Deven Bowers
Signed-off-by: Fan Wu
---
v2:
+ No Changes
v3:
+ Add Acked-by
+ Fixup code block syntax
+ Fix a minor grammatical issue.
v4:
+ Update documentatio
23 matches
Mail list logo
