Commit Graph

22 Commits

Author SHA1 Message Date
Harald Freudenberger
2004b57cde s390/zcrypt: code cleanup
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->work
  CHECK: Avoid CamelCase: <xcRB>

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 <freude@linux.ibm.com>
Reviewed-by: Jürgen Christ <jchrist@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2022-04-25 13:54:14 +02:00
Harald Freudenberger
3f74eb5f78 s390/zcrypt: rework of debug feature messages
This patch reworks all the debug feature invocations to be
more uniform. All invocations now use the macro with the
level already part of the macro name. All messages now start
with %s filled with __func__ (well there are still some
exceptions), and some message text has been shortened or
reworked.

There is no functional code touched with this patch.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-10-26 15:21:27 +02:00
Harald Freudenberger
e0332629e3 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>
2020-10-07 21:50:01 +02:00
Harald Freudenberger
74ecbef7b9 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>
2020-07-03 10:49:34 +02:00
Harald Freudenberger
6733775a92 s390/zcrypt: handle new reply code FILTERED_BY_HYPERVISOR
This patch introduces support for a new architectured reply
code 0x8B indicating that a hypervisor layer (if any) has
rejected an ap message.

Linux may run as a guest on top of a hypervisor like zVM
or KVM. So the crypto hardware seen by the ap bus may be
restricted by the hypervisor for example only a subset like
only clear key crypto requests may be supported. Other
requests will be filtered out - rejected by the hypervisor.
The new reply code 0x8B will appear in such cases and needs
to get recognized by the ap bus and zcrypt device driver zoo.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-11-30 10:52:44 +01:00
Harald Freudenberger
be53479101 s390/zcrypt: improve special ap message cmd handling
There exist very few ap messages which need to have the 'special' flag
enabled. This flag tells the firmware layer to do some pre- and maybe
postprocessing. However, it may happen that this special flag is
enabled but the firmware is unable to deal with this kind of message
and thus returns with reply code 0x41. For example older firmware may
not know the newest messages triggered by the zcrypt device driver and
thus react with reject and the named reply code. Unfortunately this
reply code is not known to the zcrypt error routines and thus default
behavior is to switch the ap queue offline.

This patch now makes the ap error routine aware of the reply code and
so userspace is informed about the bad processing result but the queue
is not switched to offline state any more.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-11-30 07:22:05 +01:00
Harald Freudenberger
a17b92e048 s390/zcrypt: provide apfs failure code on type 86 error reply
The apfs field (AP final status) is set on transport
protocol failures (reply code 0x90) for type 86 replies.
For CCA cprbs this value is copied into the xcrb status
field which gives userspace a hint for the failure reason.
However, for EP11 cprbs there is no such status field
in the xcrb struct. So now regardless of the request
type, if a reply type 86 with transport protocol failure
is seen, the apfs value is printed as part of the debug
message. So the user has a chance to see the apfs value
without using a special build kernel.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:36 +02:00
Harald Freudenberger
ee410de890 s390/zcrypt: zcrypt device driver cleanup
Some cleanup in the s390 zcrypt device driver:
- Removed fragments of pcixx crypto card code. This code
  can't be reached anymore because the hardware detection
  function does not recognize crypto cards < CEX2 since
  commit f56545430736 ("s390/zcrypt: Introduce QACT support
  for AP bus devices.")
- Rename of some files and driver names which where still
  reflecting pcixx support to cex2a/cex2c.
- Removed all the zcrypt version strings in the file headers.
  There is only one place left - the zcrypt.h header file is
  now the only place for zcrypt device driver version info.
- Zcrypt version pump up from 2.2.0 to 2.2.1.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:35 +02:00
Harald Freudenberger
ac2b96f351 s390/zcrypt: code beautify
Code beautify by following most of the checkpatch suggestions:
 - SPDX license identifier line complains by checkpatch
 - missing space or newline complains by checkpatch
 - octal numbers for permssions complains by checkpatch
 - renaming of static sysfs functions complains by checkpatch
 - fix of block comment complains by checkpatch
 - fix printf like calls where function name instead of %s __func__
   was used
 - __packed instead of __attribute__((packed))
 - init to zero for static variables removed
 - use of DEVICE_ATTR_RO and DEVICE_ATTR_RW macros

No functional code changes or API changes!

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-08-20 16:02:11 +02:00
Greg Kroah-Hartman
0b622e60bc s390: crypto: Remove redundant license text
Now that the SPDX tag is in all drivers/s390/crypto/ files, that
identifies the license in a specific and legally-defined manner.  So the
extra GPL text wording can be removed as it is no longer needed at all.

This is done on a quest to remove the 700+ different ways that files in
the kernel describe the GPL license text.  And there's unneeded stuff
like the address (sometimes incorrect) for the FSF which is never
needed.

No copyright headers or other non-license-description text was removed.

Cc: Harald Freudenberger <freude@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-11-24 14:28:46 +01:00
Greg Kroah-Hartman
812141a9fe s390: crypto: add SPDX identifiers to the remaining files
It's good to have SPDX identifiers in all files to make it easier to
audit the kernel tree for correct licenses.

Update the drivers/s390/crypto/ files with the correct SPDX license
identifier based on the license text in the file itself.  The SPDX
identifier is a legally binding shorthand, which can be used instead of
the full boiler plate text.

This work is based on a script and data from Thomas Gleixner, Philippe
Ombredanne, and Kate Stewart.

Cc: Harald Freudenberger <freude@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2017-11-24 14:28:39 +01:00
Harald Freudenberger
cccd85bfb7 s390/zcrypt: Rework debug feature invocations.
Rework the debug feature calls and initialization.  There
are now two debug feature entries used by the zcrypt code.
The first is 'ap' with all the AP bus related stuff and the
second is 'zcrypt' with all the zcrypt and devices and
driver related entries. However, there isn't much traffic on
both debug features. The ap bus code emits only some debug
info and for zcrypt devices on appearance and disappearance
there is an entry written.

The new dbf invocations use the sprintf buffer layout,
whereas the old implementation used the ascii dbf buffer.
There are now 5*8=40 bytes used for each entry, resulting in
5 parameters per call. As the sprintf buffer needs a format
string the first parameter provides this and so up to 4 more
parameters can be used. Alltogehter the new layout should be
much more human readable for customers and test.

Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-12-14 16:33:39 +01:00
Harald Freudenberger
bf9f31190a s390/zcrypt: Improved invalid domain response handling.
Add defines and switch case code to handle the two invalid
domain response codes better. Until now these two response
codes are handled via default resulting in -EAGAIN and
switching the processed queue to offline.  So this kind of
malformed request bounced through all suitable queues and
switched them off. Now this kind of malformed request is
just rejected with EINVAL without switching off the queue.

Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-12-14 16:33:39 +01:00
Ingo Tuchscherer
e28d2af436 s390/zcrypt: add multi domain support
Currently the ap infrastructure only supports one domain at a time.
This feature extends the generic cryptographic device driver to
support multiple cryptographic domains simultaneously.

There are now card and queue devices on the AP bus with independent
card and queue drivers. The new /sys layout is as follows:

/sys/bus/ap
    devices
        <xx>.<yyyy> -> ../../../devices/ap/card<xx>/<xx>.<yyyy>
        ...
        card<xx> -> ../../../devices/ap/card<xx>
        ...
    drivers
        <drv>card
            card<xx> -> ../../../../devices/ap/card<xx>
        <drv>queue
            <xx>.<yyyy> -> ../../../../devices/ap/card<xx>/<xx>.<yyyy>
            ...

/sys/devices/ap
    card<xx>
        <xx>.<yyyy>
            driver -> ../../../../bus/ap/drivers/<zzz>queue
            ...
        driver -> ../../../bus/ap/drivers/<drv>card
        ...

The two digit <xx> field is the card number, the four digit <yyyy>
field is the queue number and <drv> is the name of the device driver,
e.g. "cex4".

For compatability /sys/bus/ap/card<xx> for the old layout has to exist,
including the attributes that used to reside there.

With additional contributions from Harald Freudenberger and
Martin Schwidefsky.

Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-12-14 16:33:38 +01:00
Ingo Tuchscherer
d8f51227f3 s390/zcrypt: Fix cryptographic device id in kernel messages
Currently, on card response failures a combination of card domain and
domain id is recorded in the kernel messages.

According to the message description only the card id will be recorded.
The domain id is not relevant, since the whole card including all domains
is set offline.

Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2016-01-26 12:46:58 +01:00
Ingo Tuchscherer
91f3e3eaba s390/zcrypt: add support for EP11 coprocessor cards
This feature extends the generic cryptographic device driver (zcrypt)
with a new capability to service EP11 requests for the Crypto Express4S
card in EP11 (Enterprise PKCS#11 mode) coprocessor mode.

Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2013-12-18 17:37:15 +01:00
Holger Dengler
dabecb2933 s390/zcryt: Handle AP configuration changes
Detect external AP bus configuration changes and request
an AP device rescan.

Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2012-09-26 15:45:17 +02:00
Heiko Carstens
a53c8fab3f s390/comments: unify copyright messages and remove file names
Remove the file name from the comment at top of many files. In most
cases the file name was wrong anyway, so it's rather pointless.

Also unify the IBM copyright statement. We did have a lot of sightly
different statements and wanted to change them one after another
whenever a file gets touched. However that never happened. Instead
people start to take the old/"wrong" statements to use as a template
for new files.
So unify all of them in one go.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2012-07-20 11:15:04 +02:00
Felix Beck
1a89dd8f0b [S390] Cleanup zcrypt printk messages.
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>
2008-07-14 10:02:19 +02:00
Felix Beck
1749a81d62 [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>
2008-04-17 07:47:06 +02:00
Ralph Wuerthner
5432114baf [S390] zcrypt secure key cryptography extension.
Allow the user space to send extended cprb messages directly to the
PCIXCC / CEX2C cards. This allows the CCA library to construct special
crypto requests that use "secure" keys that are stored on the card.

Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2006-09-20 15:58:36 +02:00
Martin Schwidefsky
963ed931c3 [S390] zcrypt CEX2A, CEX2C, PCICA accelerator card ap bus drivers.
Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2006-09-20 15:58:29 +02:00