s390/ap: move receive callback to message struct

Move the receive callback from zdev_driver to ap_message structure to
get a more flexible asynchronous ap message handling.

Signed-off-by: Holger De

s390/ap: move receive callback to message struct

Move the receive callback from zdev_driver to ap_message structure to
get a more flexible asynchronous ap message handling.

Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] ap: toleration support for ap device type 10

Add toleration support for ap devices with device type 10.

Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsk

[S390] ap: toleration support for ap device type 10

Add toleration support for ap devices with device type 10.

Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] zcrypt: Introduce check for 4096 bit support.

Implemented an asm in the ap bus and made it accessible for the card
specific parts of the zcrypt driver. Thus when a cex3a is recognized
a check

[S390] zcrypt: Introduce check for 4096 bit support.

Implemented an asm in the ap bus and made it accessible for the card
specific parts of the zcrypt driver. Thus when a cex3a is recognized
a check can be performed to dermine whether the card supports 4096 bit
RSA keys.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] zcrypt: add support for cex3 device types

This patch renames the CEX2C2 and CEX2A2 types to CEX3 device types.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Ralph Wuerthne

[S390] zcrypt: add support for cex3 device types

This patch renames the CEX2C2 and CEX2A2 types to CEX3 device types.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Ralph Wuerthner <ralph.wuerthner@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] zcrypt: special command support for cex3 exploitation

Support for special command is implemented in the AP Bus in the NQAP
function __ap_send. This is extended for a further parameter special

[S390] zcrypt: special command support for cex3 exploitation

Support for special command is implemented in the AP Bus in the NQAP
function __ap_send. This is extended for a further parameter special.
When set, the special bit, in GR0 will be set. Therefor the ap_message
struct is extended for a further bit. Thus calling functions of
__ap_send can use the special parameter in ap_message to give to
__ap_send. Affected is in the first place ap_queue_message, which is
called by the actual card driver. The second part of this support is
that the card driver for the CEX3C needs to set this special bit, when
an according CPRB is sent to the driver.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Ralph Wuerthner <ralph.wuerthner@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] zcrypt: initialize ap_messages for cex3 exploitation

AP messages need to be initialized, before they will be used. Values
will be zeroized. This will be needed later when introducing support

[S390] zcrypt: initialize ap_messages for cex3 exploitation

AP messages need to be initialized, before they will be used. Values
will be zeroized. This will be needed later when introducing support
for the special commands.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Ralph Wuerthner <ralph.wuerthner@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] zcrypt: Use of Thin Interrupts

When the machine supports AP adapter interrupts polling will be
switched off at module initialization and the driver will work in
interrupt mode.

Signed-off-by

[S390] zcrypt: Use of Thin Interrupts

When the machine supports AP adapter interrupts polling will be
switched off at module initialization and the driver will work in
interrupt mode.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] zcrypt: Add additional card IDs to CEX2C and CEX2A

Add support for new micro code load of CEX2C and CEX2A adapters,
which uses different IDs. This patch just adds the IDs to the
existing dri

[S390] zcrypt: Add additional card IDs to CEX2C and CEX2A

Add support for new micro code load of CEX2C and CEX2A adapters,
which uses different IDs. This patch just adds the IDs to the
existing drivers.

Signed-off-by: Ralph Wuerthner <ralph.wuerthner@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>

show more ...

[S390] zcrypt: Comments and kernel-doc cleanup

Comments, which suggested to be kernel-doc but were not in the right
formatting, have been corrected. Additionally some minor cleanup in
the comments h

[S390] zcrypt: Comments and kernel-doc cleanup

Comments, which suggested to be kernel-doc but were not in the right
formatting, have been corrected. Additionally some minor cleanup in
the comments has been done.

Signed-off-by: Felix Beck <felix.beck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>

show more ...

[S390] zcrypt: fix request timeout handling

Under very high load zcrypt requests may timeout while waiting on the
request queue. Modify zcrypt that timeouts are based on crypto adapter
responses. A

[S390] zcrypt: fix request timeout handling

Under very high load zcrypt requests may timeout while waiting on the
request queue. Modify zcrypt that timeouts are based on crypto adapter
responses. A timeout occurs only if a crypto adapter does not respond
within a given time frame to sumitted requests.

Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] zcrypt: fix possible dead lock in AP bus module

AP bus module uses bus_for_each_dev() in software interrupt context to
poll for completed requests which might cause dead locks. Solution: use

[S390] zcrypt: fix possible dead lock in AP bus module

AP bus module uses bus_for_each_dev() in software interrupt context to
poll for completed requests which might cause dead locks. Solution: use
private AP device list for polling in software interrupt context.

Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] zcrypt adjunct processor bus.

Add a bus for the adjunct processor interface. Up to 64 devices can
be connect to the ap bus interface, each device with 16 domains. That
makes 1024 message queu

[S390] zcrypt adjunct processor bus.

Add a bus for the adjunct processor interface. Up to 64 devices can
be connect to the ap bus interface, each device with 16 domains. That
makes 1024 message queues. The interface is asynchronous, the answer
to a message sent to a queue needs to be received at some later point
in time. Unfortunately the interface does not provide interrupts when
a message reply is pending. So the ap bus needs to implement some
fancy polling, each active queue is polled once per 1/HZ second or
continuously if an idle cpus exsists and the poll thread is activ
(see poll_thread parameter).

The ap bus uses the sysfs path /sys/bus/ap and has two bus attributes,
ap_domain and config_time. The ap_domain selects one of the 16 domains
to be used for this system. This limits the maximum number of ap devices
to 64. The config_time attribute contains the number of seconds between
two ap bus scans to find new devices.

The ap bus uses the modalias entries of the form "ap:tN" to autoload
the ap driver for hardware type N. Currently known types are:
3 - PCICC, 4 - PCICA, 5 - PCIXCC, 6 - CEX2A and 7 - CEX2C.

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

s390/ap: fix state machine hang after failure to enable irq

[ Upstream commit cabebb697c98fb1f05cc950a747a9b6ec61a5b01 ]

If for any reason the interrupt enable for an ap queue fails

s390/ap: fix state machine hang after failure to enable irq

[ Upstream commit cabebb697c98fb1f05cc950a747a9b6ec61a5b01 ]

If for any reason the interrupt enable for an ap queue fails the
state machine run for the queue returned wrong return codes to the
caller. So the caller assumed interrupt support for this queue in
enabled and thus did not re-establish the high resolution timer used
for polling. In the end this let to a hang for the user space process
waiting "forever" for the reply.

This patch reworks these return codes to return correct indications
for the caller to re-establish the timer when a queue runs without
interrupt support.

Please note that this is fixing a wrong behavior after a first
failure (enable interrupt support for the queue) failed. However,
looks like this occasionally happens on KVM systems.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

s390/zcrypt: Introduce Failure Injection feature

Introduce a way to specify additional debug flags with an crpyto
request to be able to trigger certain failures within the zcrypt
dev

s390/zcrypt: Introduce Failure Injection feature

Introduce a way to specify additional debug flags with an crpyto
request to be able to trigger certain failures within the zcrypt
device drivers and/or ap core code.

This failure injection possibility is only enabled with a kernel debug
build CONFIG_ZCRYPT_DEBUG) and should never be available on a regular
kernel running in production environment.

Details:

* The ioctl(ICARSAMODEXPO) get's a struct ica_rsa_modexpo. If the
leftmost bit of the 32 bit unsigned int inputdatalength field is
set, the uppermost 16 bits are separated and used as debug flag
value. The process is checked to have the CAP_SYS_ADMIN capability
enabled or EPERM is returned.

* The ioctl(ICARSACRT) get's a struct ica_rsa_modexpo_crt. If the
leftmost bit of the 32 bit unsigned int inputdatalength field is set,
the uppermost 16 bits are separated and used als debug flag
value. The process is checked to have the CAP_SYS_ADMIN capability
enabled or EPERM is returned.

* The ioctl(ZSECSENDCPRB) used to send CCA CPRBs get's a struct
ica_xcRB. If the leftmost bit of the 32 bit unsigned int status
field is set, the uppermost 16 bits of this field are used as debug
flag value. The process is checked to have the CAP_SYS_ADMIN
capability enabled or EPERM is returned.

* The ioctl(ZSENDEP11CPRB) used to send EP11 CPRBs get's a struct
ep11_urb. If the leftmost bit of the 64 bit unsigned int req_len
field is set, the uppermost 16 bits of this field are used as debug
flag value. The process is checked to have the CAP_SYS_ADMIN
capability enabled or EPERM is returned.

So it is possible to send an additional 16 bit value to the zcrypt API
to be used to carry a failure injection command which may trigger
special behavior within the zcrypt API and layers below. This 16 bit
value is for the rest of the test referred as 'fi command' for Failure
Injection.

The lower 8 bits of the fi command construct a numerical argument in
the range of 1-255 and is the 'fi action' to be performed with the
request or the resulting reply:

* 0x00 (all requests): No failure injection action but flags may be
provided which may affect the processing of the request or reply.
* 0x01 (only CCA CPRBs): The CPRB's agent_ID field is set to
'FF'. This results in an reply code 0x90 (Transport-Protocol
Failure).
* 0x02 (only CCA CPRBs): After the APQN to send to has been chosen,
the domain field within the CPRB is overwritten with value 99 to
enforce an reply with RY 0x8A.
* 0x03 (all requests): At NQAP invocation the invalid qid value 0xFF00
is used causing an response code of 0x01 (AP queue not valid).

The upper 8 bits of the fi command may carry bit flags which may
influence the processing of an request or response:

* 0x01: No retry. If this bit is set, the usual loop in the zcrypt API
which retries an CPRB up to 10 times when the lower layers return
with EAGAIN is abandoned after the first attempt to send the CPRB.
* 0x02: Toggle special. Toggles the special bit on this request. This
should result in an reply code RY~0x41 and result in an ioctl
failure with errno EINVAL.

This failure injection possibilities may get some further extensions
in the future. As of now this is a starting point for Continuous Test
and Integration to trigger some failures and watch for the reaction of
the ap bus and zcrypt device driver code.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/ap/zcrypt: revisit ap and zcrypt error handling

Revisit the ap queue error handling: Based on discussions and
evaluatios with the firmware folk here is now a rework of the response

s390/ap/zcrypt: revisit ap and zcrypt error handling

Revisit the ap queue error handling: Based on discussions and
evaluatios with the firmware folk here is now a rework of the response
code handling for all the AP instructions. The idea is to distinguish
between failures because of some kind of invalid request where a retry
does not make any sense and a failure where another attempt to send
the very same request may succeed. The first case is handled by
returning EINVAL to the userspace application. The second case results
in retries within the zcrypt API controlled by a per message retry
counter.

Revisit the zcrpyt error handling: Similar here, based on discussions
with the firmware people here comes a rework of the handling of all
the reply codes. Main point here is that there are only very few
cases left, where a zcrypt device queue is switched to offline. It
should never be the case that an AP reply message is 'unknown' to the
device driver as it indicates a total mismatch between device driver
and crypto card firmware. In all other cases, the code distinguishes
between failure because of invalid message (see above - EINVAL) or
failures of the infrastructure (see above - EAGAIN).

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/ap: add card/queue deconfig state

This patch adds a new config state to the ap card and queue
devices. This state reflects the response code
0x03 "AP deconfigured" on TQAP invoc

s390/ap: add card/queue deconfig state

This patch adds a new config state to the ap card and queue
devices. This state reflects the response code
0x03 "AP deconfigured" on TQAP invocation and is tracked with
every ap bus scan.

Together with this new state now a card/queue device which
is 'deconfigured' is not disposed any more. However, for backward
compatibility the online state now needs to take this state into
account. So a card/queue is offline when the device is not configured.
Furthermore a device can't get switched from offline to online state
when not configured.

The config state is shown in sysfs at
/sys/devices/ap/cardxx/config
for the card and
/sys/devices/ap/cardxx/xx.yyyy/config
for each queue within each card.
It is a read-only attribute reflecting the negation of the
'AP deconfig' state as it is noted in the AP documents.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/ap: add error response code field for ap queue devices

On AP instruction failures the last response code is now
kept in the struct ap_queue. There is also a new sysfs
attribute

s390/ap: add error response code field for ap queue devices

On AP instruction failures the last response code is now
kept in the struct ap_queue. There is also a new sysfs
attribute showing this field (enabled only on debug kernels).

Also slight rework of the AP_DBF macros to get some more
content into one debug feature message line.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/ap: split ap queue state machine state from device state

The state machine for each ap queue covered a mixture of
device states and state machine (firmware queue state) states.

s390/ap: split ap queue state machine state from device state

The state machine for each ap queue covered a mixture of
device states and state machine (firmware queue state) states.

This patch splits the device states and the state machine
states into two different enums and variables. The major
state is the device state with currently these values:

AP_DEV_STATE_UNINITIATED - fresh and virgin, not touched
AP_DEV_STATE_OPERATING - queue dev is working normal
AP_DEV_STATE_SHUTDOWN - remove/unbind/shutdown in progress
AP_DEV_STATE_ERROR - device is in error state

only when the device state is > UNINITIATED the state machine
is run. The state machine represents the states of the firmware
queue:

AP_SM_STATE_RESET_START - starting point, reset (RAPQ) ap queue
AP_SM_STATE_RESET_WAIT - reset triggered, waiting to be finished
if irqs enabled, set up irq (AQIC)
AP_SM_STATE_SETIRQ_WAIT - enable irq triggered, waiting to be
finished, then go to IDLE
AP_SM_STATE_IDLE - queue is operational but empty
AP_SM_STATE_WORKING - queue is operational, requests are stored
and replies may wait for getting fetched
AP_SM_STATE_QUEUE_FULL - firmware queue is full, so only replies
can get fetched

For debugging each ap queue shows a sysfs attribute 'states' which
displays the device and state machine state and is only available
when the kernel is build with CONFIG_ZCRYPT_DEBUG enabled.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

mm, treewide: rename kzfree() to kfree_sensitive()

As said by Linus:

A symmetric naming is only helpful if it implies symmetries in use.
Otherwise it's actively misleading.

mm, treewide: rename kzfree() to kfree_sensitive()

As said by Linus:

A symmetric naming is only helpful if it implies symmetries in use.
Otherwise it's actively misleading.

In "kzalloc()", the z is meaningful and an important part of what the
caller wants.

In "kzfree()", the z is actively detrimental, because maybe in the
future we really _might_ want to use that "memfill(0xdeadbeef)" or
something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the recently
added kvfree_sensitive() and make the intention of the API more explicit.
In addition, memzero_explicit() is used to clear the memory to make sure
that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

git grep -w --name-only kzfree |\
xargs sed -i 's/kzfree/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.

[akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
[akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]

Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: David Howells <dhowells@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Joe Perches <joe@perches.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Jason A . Donenfeld" <Jason@zx2c4.com>
Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

s390/ap: rename and clarify ap state machine related stuff

There is a state machine held for each ap queue device.
The states and functions related to this where somethimes
noted wit

s390/ap: rename and clarify ap state machine related stuff

There is a state machine held for each ap queue device.
The states and functions related to this where somethimes
noted with _sm_ somethimes without. This patch clarifies
and renames all the ap queue state machine related functions,
enums and defines to have a _sm_ in the name.

There is no functional change coming with this patch - it's
only beautifying code.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>

show more ...

s390/zcrypt: code beautification and struct field renames

Some beautifications related to the internal only used
struct ap_message and related code. Instead of one int carrying
only

s390/zcrypt: code beautification and struct field renames

Some beautifications related to the internal only used
struct ap_message and related code. Instead of one int carrying
only the special flag now a u32 flags field is used.

At struct CPRBX the pointers to additional data are now marked
with __user. This caused some changes needed on code, where
these structs are also used within the zcrypt misc functions.

The ica_rsa_* structs now use the generic types __u8, __u32, ...
instead of char, unsigned int.

zcrypt_msg6 and zcrypt_msg50 use min_t() instead of min().

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>

show more ...

s390/ap: introduce new ap function ap_get_qdev()

Provide a new interface function to be used by the ap drivers:
struct ap_queue *ap_get_qdev(ap_qid_t qid);
Returns ptr to the struc

s390/ap: introduce new ap function ap_get_qdev()

Provide a new interface function to be used by the ap drivers:
struct ap_queue *ap_get_qdev(ap_qid_t qid);
Returns ptr to the struct ap_queue device or NULL if there
was no ap_queue device with this qid found. When something is
found, the reference count of the embedded device is increased.
So the caller has to decrease the reference count after use
with a call to put_device(&aq->ap_dev.device).

With this patch also the ap_card_list is removed from the
ap core code and a new hashtable is introduced which stores
hnodes of all the ap queues known to the ap bus.

The hashtable approach and a first implementation of this
interface comes from a previous patch from
Anthony Krowiak and an idea from Halil Pasic.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Suggested-by: Tony Krowiak <akrowiak@linux.ibm.com>
Suggested-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/ap: remove power management code from ap bus and drivers

The s390 power management support has been removed. So the
api registration and the suspend and resume callbacks and
all

s390/ap: remove power management code from ap bus and drivers

The s390 power management support has been removed. So the
api registration and the suspend and resume callbacks and
all the code related to this for the ap bus and the ap drivers
is removed with this patch.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/zcrypt: fix card and queue total counter wrap

The internal statistic counters for the total number of
requests processed per card and per queue used integers. So they do
wrap af

s390/zcrypt: fix card and queue total counter wrap

The internal statistic counters for the total number of
requests processed per card and per queue used integers. So they do
wrap after a rather huge amount of crypto requests processed. This
patch introduces uint64 counters which should hold much longer but
still may wrap. The sysfs attributes request_count for card and queue
also used only %ld and now display the counter value with %llu.

This is not a security relevant fix. The int overflow which happened
is not in any way exploitable as a security breach.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/zcrypt: move ap device reset from bus to driver code

This patch moves the reset invocation of an ap device when
fresh detected from the ap bus to the probe() function of
the dri

s390/zcrypt: move ap device reset from bus to driver code

This patch moves the reset invocation of an ap device when
fresh detected from the ap bus to the probe() function of
the driver responsible for this device.

The virtualisation of ap devices makes it necessary to
remove unconditioned resets on fresh appearing apqn devices.
It may be that such a device is already enabled for guest
usage. So there may be a race condition between host ap bus
and guest ap bus doing the reset. This patch moves the
reset from the ap bus to the zcrypt drivers. So if there
is no zcrypt driver bound to an ap device - for example
the ap device is bound to the vfio device driver - the
ap device is untouched passed to the vfio device driver.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...