applied to the s390 subsystem. This will go upstream with the next kernel merge
window.
Thanks
On 14.12.20 14:43, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/s390/crypto/zcrypt_cex4.c | 2 +-
> 1 file chan
applied to the s390 subsystem. This will go upstream with the next kernel merge
window.
Thanks
On 14.12.20 14:44, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/s390/crypto/zcrypt_cex2a.c | 2 +-
> 1 file cha
red by the function pkey_genprotkey()
which is
called just 2 lines above. An internal function the module should trust here. I
don't think
there is an additional length check needed here.
However, Thanks for your contribution.
Harald Freudenberger
see this function calls another function in the very same file and
fio_ap driver to do a bulk
>> plug of all affected adapters, domains and control domains into
>> affected guests rather than plugging them one at a time when the
>> probe callback is invoked.
>>
>> Please note that changes to the apmask and aqmask do not tri
that changes to the apmask and aqmask do not trigger
> these two callbacks since the bus scan function is not invoked by changes
> to those masks.
>
> Signed-off-by: Harald Freudenberger
Did I really sign-off this ? I know, I saw this code but ...
First of all, please separate the ap
iver)
> @@ -293,6 +294,9 @@ void ap_queue_init_state(struct ap_queue *aq);
> struct ap_card *ap_card_create(int id, int queue_depth, int raw_device_type,
> int comp_device_type, unsigned int functions);
>
> +#define APMASKSIZE (BITS_TO_LONGS(AP_DEVICES) * sizeof(unsigned long))
> +#define AQMASKSIZE (BITS_TO_LONGS(AP_DOMAINS) * sizeof(unsigned long))
> +
> struct ap_perms {
> unsigned long ioctlm[BITS_TO_LONGS(AP_IOCTLS)];
> unsigned long apm[BITS_TO_LONGS(AP_DEVICES)];
I still don't like this code. That's because of what it is doing - not because
of the code quality.
And Halil, you are right. It is adding more pressure to the mutex used for
locking the apmask
and aqmask stuff (and the zcrypt multiple device drivers support code also).
I am very concerned about the in_use callback which is called with the
ap_perms_mutex
held AND during bus_for_each_drv (so holding the overall AP BUS mutex) and then
diving
into the vfio_ap ... with yet another mutex to protect the vfio structs.
Reviewed-by: Harald Freudenberger
:00:00 2001
From: Harald Freudenberger
Date: Thu, 10 Sep 2020 11:32:43 +0200
Subject: [PATCH] s390/zcrypt: remove set_fs() invocation in zcrypt device
driver
This patch reworks the zcrypt device driver so that the set_fs()
invocation is not needed any more. Instead there is a new flag bool
usersp
On 11.09.20 08:21, Christoph Hellwig wrote:
> On Thu, Sep 10, 2020 at 12:28:38PM +0200, Harald Freudenberger wrote:
>> +static inline unsigned long z_copy_from_user(bool userspace,
>> + void *to, const void __user *from,
>> unsigned lo
z_copy_from_user() and z_copy_to_user() which either
invoke copy_from_user (userspace is true) or memcpy (userspace is
false) the zcrypt dd and the AP bus now has no requirement for
the set_fs() functionality any more.
Signed-off-by: Harald Freudenberger
---
drivers/s390/crypto/zcrypt_api.c | 30
On 02.08.20 13:15, Tianjia Zhang wrote:
> In the first place, the initialization value of `rc` is wrong.
> It is unnecessary to initialize `rc` variables, so remove their
> initialization operation.
>
> Fixes: f2bbc96e7cfad ("s390/pkey: add CCA AES cipher key support")
&
On 29.04.20 00:30, Tony Krowiak wrote:
>
>
> On 4/28/20 6:57 AM, Harald Freudenberger wrote:
>> On 28.04.20 12:07, Halil Pasic wrote:
>>> On Mon, 27 Apr 2020 17:48:58 -0400
>>> Tony Krowiak wrote:
>>>
>>>> On 4/27/20 11:17 AM, Halil
On 28.04.20 00:24, Tony Krowiak wrote:
>
>
> On 4/27/20 4:20 AM, Pierre Morel wrote:
>>
>>
>> On 2020-04-07 21:20, Tony Krowiak wrote:
>>> Introduces a new driver callback to prevent a root user from unbinding
>>> an AP queue from its device driver if the queue is in use. The intent of
>>> this cal
On 28.04.20 12:07, Halil Pasic wrote:
> On Mon, 27 Apr 2020 17:48:58 -0400
> Tony Krowiak wrote:
>
>>
>> On 4/27/20 11:17 AM, Halil Pasic wrote:
>>> On Mon, 27 Apr 2020 15:05:23 +0200
>>> Harald Freudenberger wrote:
>>>
>>>> On 24.04.
On 27.04.20 17:17, Halil Pasic wrote:
> On Mon, 27 Apr 2020 15:05:23 +0200
> Harald Freudenberger wrote:
>
>> On 24.04.20 05:57, Halil Pasic wrote:
>>> On Tue, 7 Apr 2020 15:20:01 -0400
>>> Tony Krowiak wrote:
>>>
>>>> Rather than l
r KVM code. However, never used.
So removing the export is the right thing. Thanks Denis
Heiko/Vasily will you pick this patch please?
Reviewed-by: Harald Freudenberger
On 17.06.19 17:07, Tony Krowiak wrote:
> On 6/17/19 6:05 AM, Harald Freudenberger wrote:
>> On 13.06.19 21:39, Tony Krowiak wrote:
>>> The AP architecture does not preclude assignment of AP resources that are
>>> not available. Let's go ahead and implement this face
On 13.06.19 21:39, Tony Krowiak wrote:
> This patch updates the vfio-ap documentation to include the information
> below.
>
> Changes made to the mdev matrix assignment interfaces:
>
> * Allow assignment of APQNs that are not bound to the vfio-ap device
> driver as long as they are not owned by a
On 13.06.19 21:39, Tony Krowiak wrote:
> The AP architecture does not preclude assignment of AP resources that are
> not available. Let's go ahead and implement this facet of the AP
> architecture for linux guests.
>
> The current implementation does not allow assignment of AP adapters or
> domains
On 13.06.19 21:39, Tony Krowiak wrote:
> Introduces a new driver callback to prevent a root user from unbinding
> an AP queue from its device driver if the queue is in use. This prevents
> a root user from inadvertently taking a queue away from a guest and
> giving it to the host, or vice versa. Th
On 13.06.19 21:39, Tony Krowiak wrote:
> Refactors the AP queue reset function to wait until the queue is empty
> after the PQAP(ZAPQ) instruction is executed to zero out the queue as
> required by the AP architecture.
>
> Signed-off-by: Tony Krowiak
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 49
On 13.06.19 21:39, Tony Krowiak wrote:
> In order to limit the number of private mdev functions called from the
> vfio_ap device driver as well as to provide a landing spot for dynamic
> configuration code related to binding/unbinding AP queue devices to/from
> the vfio_ap driver, the following cha
n Control */
> 156, /* etoken facility */
> -1 /* END */
> }
acked-by: Harald Freudenberger
v->kvm->arch.crypto.pqap_hook = NULL;
> + vfio_ap_mdev_reset_queues(mdev);
> + kvm_put_kvm(matrix_mdev->kvm);
> + matrix_mdev->kvm = NULL;
> + }
> + mutex_unlock(&matrix_dev->lock);
>
> - vfio_ap_mdev_reset_queues(mdev);
> vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY,
>&matrix_mdev->iommu_notifier);
> vfio_unregister_notifier(mdev_dev(mdev), VFIO_GROUP_NOTIFY,
>&matrix_mdev->group_notifier);
> - matrix_mdev->kvm = NULL;
> module_put(THIS_MODULE);
> }
>
> @@ -941,6 +1263,7 @@ static ssize_t vfio_ap_mdev_ioctl(struct mdev_device
> *mdev,
> {
> int ret;
>
> + mutex_lock(&matrix_dev->lock);
> switch (cmd) {
> case VFIO_DEVICE_GET_INFO:
> ret = vfio_ap_mdev_get_device_info(arg);
> @@ -952,6 +1275,7 @@ static ssize_t vfio_ap_mdev_ioctl(struct mdev_device
> *mdev,
> ret = -EOPNOTSUPP;
> break;
> }
> + mutex_unlock(&matrix_dev->lock);
>
> return ret;
> }
> diff --git a/drivers/s390/crypto/vfio_ap_private.h
> b/drivers/s390/crypto/vfio_ap_private.h
> index 18dcc4d..f46dde5 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -4,6 +4,7 @@
> *
> * Author(s): Tony Krowiak
> * Halil Pasic
> + * Pierre Morel
> *
> * Copyright IBM Corp. 2018
> */
> @@ -89,5 +90,15 @@ struct ap_matrix_mdev {
>
> extern int vfio_ap_mdev_register(void);
> extern void vfio_ap_mdev_unregister(void);
> +int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
> + unsigned int retry);
>
> +struct vfio_ap_queue {
> + struct ap_matrix_mdev *matrix_mdev;
> + unsigned long saved_pfn;
> + int apqn;
> +#define VFIO_AP_ISC_INVALID 0xff
> + unsigned char saved_isc;
> +};
> +struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q);
> #endif /* _VFIO_AP_PRIVATE_H_ */
acked-by: Harald Freudenberger
be1..18dcc4d 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -81,8 +81,10 @@ struct ap_matrix_mdev {
> struct list_head node;
> struct ap_matrix matrix;
> struct notifier_block group_notifier;
> + struct notifier_block iommu_notifier;
> struct kvm *kvm;
> struct kvm_s390_module_hook pqap_hook;
> + struct mdev_device *mdev;
> };
>
> extern int vfio_ap_mdev_register(void);
acked-by: Harald Freudenberger
(struct kvm_vcpu *vcpu)
> {
> int rc;
> @@ -878,6 +962,8 @@ int kvm_s390_handle_b2(struct kvm_vcpu *vcpu)
> return handle_sthyi(vcpu);
> case 0x7d:
> return handle_stsi(vcpu);
> + case 0xaf:
> + return handle_pqap(vcpu);
> case 0xb1:
> return handle_stfl(vcpu);
> case 0xb2:
> diff --git a/drivers/s390/crypto/vfio_ap_private.h
> b/drivers/s390/crypto/vfio_ap_private.h
> index 76b7f98..a910be1 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ap_bus.h"
>
> @@ -81,6 +82,7 @@ struct ap_matrix_mdev {
> struct ap_matrix matrix;
> struct notifier_block group_notifier;
> struct kvm *kvm;
> + struct kvm_s390_module_hook pqap_hook;
> };
>
> extern int vfio_ap_mdev_register(void);
acked-by: Harald Freudenberger
ers with class_find_device() users.
>
> Cc: Alexander Shishkin
> Cc: Wolfram Sang
> Cc: Jonathan Cameron
> Cc: Hartmut Knaack
> Cc: Grygorii Strashko
> Cc: "David S. Miller"
> Cc: Bjorn Helgaas
> Cc: Sebastian Ott
> Cc: Peter Oberparleiter
> Cc: Hara
On 03.06.19 17:50, Suzuki K Poulose wrote:
> Use the generic helper to find a device matching the devt.
>
> Cc: Harald Freudenberger
> Cc: Heiko Carstens
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/s390/crypto/zcrypt_api.c | 11 +--
> 1 file changed, 1 in
On 03.06.19 17:49, Suzuki K Poulose wrote:
> Use the new class_find_device_by_name() helper.
>
> Cc: Harald Freudenberger
> Cc: Martin Schwidefsky
> Cc: Heiko Carstens
> Signed-off-by: Suzuki K Poulose
> ---
> drivers/s390/crypto/zcrypt_api.c | 12 ++--
> 1
gt; Thanks for the pointer.
> So the preferred way is defining a new crypto algorithm prefixed with
> "p" and reusing setkey to provide the key reference.
The "p" in paes is because we call it "protected key aes". I think you are not
limited
to the "p". What Herbert tries to point out is that you may define your own
cipher with an unique name and there you can handle your secure key references
as you like. You may use the s390 paes implementation as a starting point.
regards Harald Freudenberger
>
> Thanks,
> //richard
>
ng to load the pkey module because of missing HW functionality.
>
> Cc: Harald Freudenberger
> Cc: Heiko Carstens
> Cc: Cornelia Huck
> Cc: Christian Borntraeger
> Signed-off-by: David Hildenbrand
> ---
> drivers/s390/crypto/pkey_api.c | 6 +++---
> 1 file changed, 3 inse
On 11.04.19 23:03, Tony Krowiak wrote:
> Once an APQN is assigned to an mdev device it will remained assigned until
> it is explicitly unassigned from the mdev device. The associated AP queue
> devices, however, can come and go due to failures or deliberate actions by
> a sysadmin. For example, a s
On 11.04.19 23:03, Tony Krowiak wrote:
> Introduces a new driver callback to prevent a root user from unbinding
> an AP queue from its device driver if the queue is in use. This prevents
> a root user from inadvertently taking a queue away from a guest and
> giving it to the host, or vice versa. Th
func_code = -1;
> rc = -EFAULT;
> goto out_free;
> }
Thanks Arnd, but as Nathan already wrote, I'd prefer to have the
variable initialized with 0 instead of -1.
If you agree with this, I'll rewrite the patch and apply it to our
internal git and it will appear at kernel org with the next s390 code merge
then.
regards Harald Freudenberger
On 26.03.19 21:45, Tony Krowiak wrote:
> On 3/22/19 10:43 AM, Pierre Morel wrote:
>> The AP interruptions are assigned on a queue basis and
>> the GISA structure is handled on a VM basis, so that
>> we need to add a structure we can retrieve from both side
>
> s/side/sides/
>
>> holding the informa
On 22.03.19 15:43, Pierre Morel wrote:
> The AP interruptions are assigned on a queue basis and
> the GISA structure is handled on a VM basis, so that
> we need to add a structure we can retrieve from both side
> holding the information we need to handle PQAP/AQIC interception
> and setup the GISA.
On 30.01.19 19:32, Sebastian Ott wrote:
> On Wed, 30 Jan 2019, Tony Krowiak wrote:
>> +#if IS_ENABLED(CONFIG_ZCRYPT)
>> +void ap_bus_cfg_chg(void);
>> +#else
>> +#error "no CONFIG_ZCRYPT"
>^
> I don't think that's the right thing to do here.
>
>
>> +++ b/drivers/s390/cio/chsc.h
>> @@ -9,6 +9,7
On 21.02.19 08:37, Christian Borntraeger wrote:
>
> On 20.02.2019 14:12, Harald Freudenberger wrote:
>> On 18.02.19 19:08, Pierre Morel wrote:
>>> Libudev relies on having a subsystem link for non-root devices. To
>>> avoid libudev (and potentially other userspace to
};
>
> extern struct ap_matrix_dev *matrix_dev;
You are introducing a new bus just for a user space application which is unable
to deal with a device directly attached to the root of devices ? So you are
fixing
kernel code because of disability of userspace code. Hm, you are switching
root cause and effect. However, not my job.
Why do you need this dummy bus ? Did you evaluate using a "class" subsystem
instead ? This is very common and my assumption is that libudev is able to
handle
this. I am using a "zcrypt" class for providing additional zcrypt device nodes
and
this works fine together with udev. I would avoid the introduction and
maintenance
of bus code at any cost.
Btw. having a look onto the naming ... the module is named "vfio_ap", the
driver is named "vfio_ap", the bus is named "vfio_ap", the root bus device is
named "vfio_ap" ... a bunch of vfio_aps naming different things.
regards
Harald Freudenberger
On 01.02.19 15:35, Cornelia Huck wrote:
> On Thu, 31 Jan 2019 18:50:57 -0500
> Tony Krowiak wrote:
>
>> On 1/31/19 4:55 AM, Cornelia Huck wrote:
>>> On Wed, 30 Jan 2019 12:48:46 -0500
>>> Tony Krowiak wrote:
>>> Two questions:
>>> - Does the event cover _any_ change to the AP configuration, or ca
On 01.02.19 16:38, Tony Krowiak wrote:
> On 2/1/19 4:01 AM, Heiko Carstens wrote:
>> On Thu, Jan 31, 2019 at 06:28:39PM -0500, Tony Krowiak wrote:
>>> On 1/30/19 1:32 PM, Sebastian Ott wrote:
On Wed, 30 Jan 2019, Tony Krowiak wrote:
> +#if IS_ENABLED(CONFIG_ZCRYPT)
> +void ap_bus_cfg_c
gt; +
>> + Control domains can similarly be assigned using the
>> assign_control_domain
>> + sysfs file.
>> +
>> + If a mistake is made configuring an adapter, domain or control domain,
>> + you can use the unassign_xxx files to unassign the adapter, domain or
>> + control domain.
>> +
>> + To display the matrix configuration for Guest1:
>> +
>> + cat matrix
>> +
>> + This is how the matrix is configured for Guest2:
>> +
>> + echo 5 > assign_adapter
>> + echo 0x47 > assign_domain
>> + echo 0xff > assign_domain
>> +
>> + This is how the matrix is configured for Guest3:
>> +
>> + echo 6 > assign_adapter
>> + echo 0x47 > assign_domain
>> + echo 0xff > assign_domain
>> +
> I'm curious why this interface didn't adopt the +/- notation invented
> above for consistency. Too difficult to do rollbacks with a string on
> entries?
>
> Looks pretty reasonable other than the points of confusion noted.
> Thanks,
>
> Alex
>
Hello Alex
the AP bus apmask and aqmask interface is not part of this patch series.
It's a general concept not only related to KVM and vfio but may be used
(and will) by other kernel and userspace features.
The bit ordering follows other implementations in the s390 (big endian)
realm where bit counting starts with 0 on the very left side and increases to
the right. All the AP bus stuff obeys to this (maybe historical) scheme.
Please have a look on the patches which introduced this mask API:
- s390/zcrypt: AP bus support for alternate driver(s) :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e0bdbe5c21cb8316a694e46ad5aad339f6894a6
- s390/zcrypt: hex string mask improvements for apmask and aqmask:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3d8f60d38e249f989a7fca9c2370c31c3d5487e1
The patch headers should describe the behavior and the syntax
of the recognized string patterns in more detail.
regards
Harald Freudenberger (maintainer of the s390 AP bus and zcrypt device driver
code)
On 24.09.2018 14:16, Halil Pasic wrote:
>
> On 09/24/2018 01:36 PM, Cornelia Huck wrote:
>> On Wed, 12 Sep 2018 15:43:03 -0400
>> Tony Krowiak wrote:
>>
>>> From: Tony Krowiak
>>>
>>> Let's call PAPQ(ZAPQ) to zeroize a queue for each queue configured
>>> for a mediated matrix device when it is re
On 21.09.2018 11:40, Cornelia Huck wrote:
> On Wed, 12 Sep 2018 15:42:56 -0400
> Tony Krowiak wrote:
>
>> From: Tony Krowiak
>>
>> Introduces two new sysfs attributes for the VFIO mediated
>> matrix device for assigning AP adapters to and unassigning
>> AP adapters from a mediated matrix device.
On 05.09.2018 02:16, Kees Cook wrote:
> On Fri, Aug 24, 2018 at 12:42 AM, Martin Schwidefsky
> wrote:
>> Harald Freudenberger (5):
>> s390/zcrypt: hex string mask improvements for apmask and aqmask.
> This (and an earlier 2017 commit) adds VLAs, which are being
> re
have an empty control domain mask
and the guest should be able to run crypto CPRBs on the usage domain(s) without
any problems. However, nobody has tried this.
regards
Harald Freudenberger
On 21.08.2018 17:53, Cornelia Huck wrote:
> On Tue, 21 Aug 2018 11:00:00 +0200
> Harald Freudenberger wrote:
>
>> On 20.08.2018 18:03, Cornelia Huck wrote:
>>> On Mon, 13 Aug 2018 17:48:19 -0400
>>> Tony Krowiak wrote:
>>>> +* AP Instructions:
&
On 20.08.2018 18:03, Cornelia Huck wrote:
> On Mon, 13 Aug 2018 17:48:19 -0400
> Tony Krowiak wrote:
>
>> From: Tony Krowiak
>>
>> This patch provides documentation describing the AP architecture and
>> design concepts behind the virtualization of AP devices. It also
>> includes an example of how
.
-
>From 9e050f843f3281da1f65292422e30f2dd1fd6d98 Mon Sep 17 00:00:00 2001
From: Harald Freudenberger
Date: Thu, 9 Aug 2018 11:59:34 +0200
Subject: [PATCH] s390/zcrypt: fix ap_instructions_available() returncodes
During review of KVM patches it was complained that the
ap_instructions_availa
On 10.08.2018 10:49, Cornelia Huck wrote:
> On Thu, 9 Aug 2018 12:06:56 -0400
> Tony Krowiak wrote:
>
>> On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
>>> On 09.08.2018 11:06, Cornelia Huck wrote:
>>>> On Wed, 8 Aug 2018 10:44:14 -0400
>>>>
Here is now a reworked version of the integrate ap_asm.h into include/asm/ap.h
patch
which can be used to apply it within the AP virtualisation patch queue for
testing:
>From c81710e7cd073c4f9a904f3539ecf17fd89c9c2d Mon Sep 17 00:00:00 2001
From: Harald Freudenberger
Date: Tue, 12 Jun 2018
On 09.08.2018 11:06, Cornelia Huck wrote:
> On Wed, 8 Aug 2018 10:44:14 -0400
> Tony Krowiak wrote:
>
>> From: Harald Freudenberger
>>
>> Move all the inline functions from the ap bus header
>> file ap_asm.h into the in-kernel api header file
>> arch/s39
On 09.08.2018 10:17, David Hildenbrand wrote:
> On 08.08.2018 16:44, Tony Krowiak wrote:
>> From: Tony Krowiak
>>
>> Introduces a new CPU model feature and two CPU model
>> facilities to support AP virtualization for KVM guests.
>>
>> CPU model feature:
>>
>> The KVM_S390_VM_CPU_FEAT_AP feature in
@ -1242,7 +1242,7 @@ static int __init ap_module_init(void)
>
> /* Create /sys/devices/ap. */
> ap_root_device = root_device_register("ap");
> - rc = PTR_RET(ap_root_device);
> + rc = PTR_ERR_OR_ZERO(ap_root_device);
> if (rc)
> goto out_bus;
>
Reviewed-by: Harald Freudenberger
On 09.07.2018 16:17, Pierre Morel wrote:
> On 29/06/2018 23:11, Tony Krowiak wrote:
>> Registers the matrix device created by the VFIO AP device
>> driver with the VFIO mediated device framework.
>> Registering the matrix device will create the sysfs
>> structures needed to create mediated matrix d
On 03.07.2018 16:56, Tony Krowiak wrote:
> On 07/03/2018 03:46 AM, Harald Freudenberger wrote:
>> On 02.07.2018 18:28, Halil Pasic wrote:
>>>
>>> On 06/29/2018 11:11 PM, Tony Krowiak wrote:
>>>> This patch provides documentation describing the AP architect
On 29.06.2018 23:11, Tony Krowiak wrote:
> This patch provides documentation describing the AP architecture and
> design concepts behind the virtualization of AP devices. It also
> includes an example of how to configure AP devices for exclusive
> use of KVM guests.
>
> Signed-off-by: Tony Krowiak
On 02.07.2018 18:28, Halil Pasic wrote:
>
>
> On 06/29/2018 11:11 PM, Tony Krowiak wrote:
>> This patch provides documentation describing the AP architecture and
>> design concepts behind the virtualization of AP devices. It also
>> includes an example of how to configure AP devices for exclusive
>
t; I'll check with the developer.
The proposal is out on the internal mailing list. I'd like to release it
(internal) tomorrow or start
next week. Already talked with Christian about this because we need to align it
somehow with
kvm and s390 kernel development.
regards
Haral
ric kernel interface for some kind
of key token as a binary blob. I am also open to use the kernel key
ring for future extensions. But please understand we needed a way
to support our hardware keys and I think the chosen design isn't
so bad.
regards Harald Freudenberger
using the kernel key ring in future extensions.
On 02/28/2018 06:41 PM, Cornelia Huck wrote:
> On Tue, 27 Feb 2018 09:28:01 -0500
> Tony Krowiak wrote:
>
>> If the AP instructions are not available on the linux host, then
>> AP devices can not be interpreted by the SIE. The AP bus has a
>> function it uses to determine if the AP instructions ar
s.c
> @@ -211,6 +211,12 @@ int ap_query_configuration(struct ap_config_info *info)
> }
> EXPORT_SYMBOL(ap_query_configuration);
>
> +int ap_instructions_installed(void)
> +{
> + return (ap_instructions_available() == 0);
> +}
> +EXPORT_SYMBOL(ap_instructions_installed);
> +
> /**
> * ap_init_configuration(): Allocate and query configuration array.
> */
Reviewed-by: Harald Freudenberger
On 12/02/2017 02:30 AM, Tony Krowiak wrote:
> On 11/03/2017 04:47 AM, Christian Borntraeger wrote:
>>
>> On 11/02/2017 07:49 PM, Tony Krowiak wrote:
>>> On 11/02/2017 11:53 AM, Christian Borntraeger wrote:
On 11/02/2017 04:36 PM, Tony Krowiak wrote:
> On 11/02/2017 08:08 AM, Christian Born
On 10/11/2017 09:52 PM, Vasyl Gomonovych wrote:
> drivers/s390/crypto/pkey_api.c:128:11-18: WARNING: kzalloc should be used for
> cprbmem, instead of kmalloc/memset
>
> Use kzalloc rather than kmalloc followed by memset with 0
>
> Generated by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci
>
>
' (MCL3 'PK' or CEX2C 'PK')
> * - VUD block
> */
> -static struct CPRBX static_cprbx = {
> +static const struct CPRBX static_cprbx = {
> .cprb_len = 0x00DC,
> .cprb_ver_id= 0x02,
> .func_id= {0x54, 0x32},
Applied. Will be available with the next merge.
Thanks and have a nice day.
Harald Freudenberger
itstream
* (per mill).
*/
...
quality = estimation of true entropy per mill.
I understand this as quality=1000 meaning 100% entropy.
However, the core code currently does not really check this value.
When more than one hwrng sources do register, simple the one with
the higher quality value wins :-) The value is not even checked
to be in a given range.
I searched through some device drivers which do register at
the hwrng and it looks like most of the drivers do not even
set this value. My feeling is, you should use 999 when your
hardware provides 'perfect' random. So there is a chance for
an even 'more perfect' hardware coming up later to overrule
your 'perfect' hardware.
regards
Harald Freudenberger
On 02/13/2017 01:03 PM, Harald Freudenberger wrote:
> On 02/09/2017 03:48 PM, Paul Gortmaker wrote:
>> The Makefile in drivers/s390 has:
>>
>> obj-y += cio/ block/ char/ crypto/ net/ scsi/ virtio/
>>
>> ..and the Makefile in crypto/ has:
>>
>>
e the file does declare
> some module parameters even though it is not modular itself.
>
> Cc: Harald Freudenberger
> Cc: Martin Schwidefsky
> Cc: Heiko Carstens
> Cc: linux-s...@vger.kernel.org
> Signed-off-by: Paul Gortmaker
> ---
> drivers/s390/crypto/ap_bus.
67 matches
Mail list logo
