<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/s390/crypto/zcrypt_api.h, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/s390/crypto/zcrypt_api.h?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/s390/crypto/zcrypt_api.h?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-04-25T11:54:14Z</updated>
<entry>
<title>s390/zcrypt: code cleanup</title>
<updated>2022-04-25T11:54:14Z</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2022-04-04T15:12:37Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=2004b57cde6b21170d058244b53043105d89f83f'/>
<id>urn:sha1:2004b57cde6b21170d058244b53043105d89f83f</id>
<content type='text'>
This patch tries to fix as much as possible of the
checkpatch.pl --strict findings:
  CHECK: Logical continuations should be on the previous line
  CHECK: No space is necessary after a cast
  CHECK: Alignment should match open parenthesis
  CHECK: 'useable' may be misspelled - perhaps 'usable'?
  WARNING: Possible repeated word: 'is'
  CHECK: spaces preferred around that '*' (ctx:VxV)
  CHECK: Comparison to NULL could be written "!msg"
  CHECK: Prefer kzalloc(sizeof(*zc)...) over kzalloc(sizeof(struct...)...)
  CHECK: Unnecessary parentheses around resp_type-&gt;work
  CHECK: Avoid CamelCase: &lt;xcRB&gt;

There is no functional change comming with this patch, only
code cleanup, renaming, whitespaces, indenting, ... but no
semantic change in any way. Also the API (zcrypt and pkey
header file) is semantically unchanged.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Jürgen Christ &lt;jchrist@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/ap/zcrypt: notify userspace with online, config and mode info</title>
<updated>2021-06-16T21:46:18Z</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2021-04-13T16:11:09Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=df6f508c68dbc65def0098cbdf8de7683ae551d2'/>
<id>urn:sha1:df6f508c68dbc65def0098cbdf8de7683ae551d2</id>
<content type='text'>
This patch brings 3 reworked/new uevent changes:
* All AP uevents caused by an ap card or queue device now carry an
  additional uevent env value MODE=&lt;accel|cca|ep11&gt;. Here is an
  example:
    KERNEL[1267.301292] add	 /devices/ap/card0a (ap)
    ACTION=add
    DEVPATH=/devices/ap/card0a
    SUBSYSTEM=ap
    DEVTYPE=ap_card
    DEV_TYPE=000D
    MODALIAS=ap:t0D
    MODE=ep11			 &lt;- this is new
    SEQNUM=1095
  This is true for bind, unbind, add, remove, and change uevents
  related to ap card or ap queue devices.
* On a change of the soft online attribute on a zcrypt queue or card
  device a new CHANGE uevent is sent with an env value ONLINE=&lt;0|1&gt;.
  Example uevent:
    KERNEL[613.067531] change	/devices/ap/card09/09.0011 (ap)
    ACTION=change
    DEVPATH=/devices/ap/card09/09.0011
    SUBSYSTEM=ap
    ONLINE=0			&lt;- this is new
    DEVTYPE=ap_queue
    DRIVER=cex4queue
    MODE=cca
    SEQNUM=1070
- On a change of the config state of an zcrypt card device a new
  CHANGE uevent is sent with an env value CONFIG=&lt;0|1&gt;.
  Example uevent:
    KERNEL[876.258680] change	/devices/ap/card09 (ap)
    ACTION=change
    DEVPATH=/devices/ap/card09
    SUBSYSTEM=ap
    CONFIG=0			&lt;- this is new
    DEVTYPE=ap_card
    DRIVER=cex4card
    DEV_TYPE=000D
    MODALIAS=ap:t0D
    MODE=cca
    SEQNUM=1073
  Setting a card config on/off causes the dependent queue devices to
  follow the config state change and thus uevents informing about the
  config state change for the queue devices are also emitted.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Ingo Franzki &lt;ifranzki@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: remove zcrypt_device_count</title>
<updated>2021-06-07T15:06:59Z</updated>
<author>
<name>Julian Wiedmann</name>
<email>jwi@linux.ibm.com</email>
</author>
<published>2021-04-16T09:58:41Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3b4dd96854c423bdf20372bbff384c1852862248'/>
<id>urn:sha1:3b4dd96854c423bdf20372bbff384c1852862248</id>
<content type='text'>
It's evidently unused.

Signed-off-by: Julian Wiedmann &lt;jwi@linux.ibm.com&gt;
Reviewed-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt/pkey: introduce zcrypt_wait_api_operational() function</title>
<updated>2020-11-09T10:21:00Z</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2020-09-01T10:48:14Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=43cb5a7c61186cde6eba344c43489b9cf95c68f8'/>
<id>urn:sha1:43cb5a7c61186cde6eba344c43489b9cf95c68f8</id>
<content type='text'>
The zcrypt api provides a new function to wait until the zcrypt
api is operational:

  int zcrypt_wait_api_operational(void);

The AP bus scan and the binding of ap devices to device drivers is
an asynchronous job. This function waits until these initial jobs
are done and so the zcrypt api should be ready to serve crypto
requests - if there are resources available. The function uses an
internal timeout of 60s. The very first caller will either wait for
ap bus bindings complete or the timeout happens. This state will be
remembered for further callers which will only be blocked until a
decision is made (timeout or bindings complete).

Reviewed-by: Ingo Franzki &lt;ifranzki@linux.ibm.com&gt;
Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: Introduce Failure Injection feature</title>
<updated>2020-10-07T19:50:01Z</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2020-09-29T14:07:22Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=27c4f6738bdc535e42dfc1295dadc78ab7582939'/>
<id>urn:sha1:27c4f6738bdc535e42dfc1295dadc78ab7582939</id>
<content type='text'>
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 &lt;freude@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: move ap_msg param one level up the call chain</title>
<updated>2020-10-07T19:50:01Z</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2020-09-26T20:51:38Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=3730f5300b450bc89306c3ab79c254e6039d9197'/>
<id>urn:sha1:3730f5300b450bc89306c3ab79c254e6039d9197</id>
<content type='text'>
Move the creating and disposal of the struct ap_message one
level up the call chain. The ap message was constructed in the
calling functions in msgtype50 and msgtype6 but only for the
ica rsa messages. For CCA and EP11 CPRBs the ap message struct
is created in the zcrypt api functions.

This patch moves the construction of the ap message struct into
the functions zcrypt_rsa_modexpo and zcrypt_rsa_crt. So now all
the 4 zcrypt api functions zcrypt_rsa_modexpo, zcrypt_rsa_crt,
zcrypt_send_cprb and zcrypt_send_ep11_cprb appear and act
similar.

There are no functional changes coming with this patch.
However, the availability of the ap_message struct has
advantages which will be needed by a follow up patch.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: introduce msg tracking in zcrypt functions</title>
<updated>2020-10-07T19:49:59Z</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2020-07-02T09:10:11Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=91ffc519c1997520ff3435ee227d86cfaa30d037'/>
<id>urn:sha1:91ffc519c1997520ff3435ee227d86cfaa30d037</id>
<content type='text'>
Introduce a new internal struct zcrypt_track with an retry counter
field and a last return code field. Fill and update these fields at
certain points during processing of an request/reply. This tracking
info is then used to
- avoid trying to resend the message forever. Now each message is
  tried to be send TRACK_AGAIN_MAX (currently 10) times and then the
  ioctl returns to userspace with errno EAGAIN.
- avoid trying to resend the message on the very same card/domain. If
  possible (more than one APQN with same quality) don't use the very
  same qid as the previous attempt when again scheduling the request.
  This is done by adding penalty weight values when the dispatching
  takes place. There is a penalty TRACK_AGAIN_CARD_WEIGHT_PENALTY for
  using the same card as previously and another penalty define
  TRACK_AGAIN_QUEUE_WEIGHT_PENALTY to be considered when the same qid
  as the previous sent attempt is calculated. Both values make it
  harder to choose the very same card/domain but not impossible. For
  example when only one APQN is available a resend can only address the
  very same APQN.

There are some more ideas for the future to extend the use of this
tracking information. For example the last response code at NQAP and
DQAP could be stored there, giving the possibility to extended tracing
and debugging about requests failing to get processed properly.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: remove set_fs() invocation in zcrypt device driver</title>
<updated>2020-09-17T12:11:03Z</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2020-09-15T15:01:58Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=52f72feba9dbe4fac848ae0d90bc0b85b17f91bc'/>
<id>urn:sha1:52f72feba9dbe4fac848ae0d90bc0b85b17f91bc</id>
<content type='text'>
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
userspace passed through all the functions which tells if the pointer
arguments are userspace or kernelspace. Together with the two new
inline functions 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 &lt;freude@linux.ibm.com&gt;
Reviewed-by: Ingo Franzki &lt;ifranzki@linux.ibm.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: ep11 structs rework, export zcrypt_send_ep11_cprb</title>
<updated>2020-01-30T12:07:55Z</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2019-08-30T13:57:17Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=a7367997abb64b5e5a4f6fe6091629440b10da40'/>
<id>urn:sha1:a7367997abb64b5e5a4f6fe6091629440b10da40</id>
<content type='text'>
Minor rework for struct ep11_cprb and struct ep11_urb. Use of u8, u16,
u32 instead of unsigned char. Declare pointers to mem from userspace
with __user to give sparse a chance to check.

Export zcrypt_send_ep11_cprb() function as this function will be
called by code in progress which will build ep11 cprbs within the
zcrypt device driver zoo and send them to EP11 crypto cards.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: CEX7S exploitation support</title>
<updated>2019-09-19T10:56:06Z</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2019-08-16T09:05:58Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=cf2957f3907e44ca40392ac19a0c22a14e3fdc18'/>
<id>urn:sha1:cf2957f3907e44ca40392ac19a0c22a14e3fdc18</id>
<content type='text'>
This patch adds CEX7 exploitation support for the AP bus code,
the zcrypt device driver zoo and the vfio device driver.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Ingo Franzki &lt;ifranzki@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
</feed>
