aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-05-09KEYS: trusted: Add session encryption protection to the seal/unseal pathJames Bottomley1-27/+61
If some entity is snooping the TPM bus, the can see the data going in to be sealed and the data coming out as it is unsealed. Add parameter and response encryption to these cases to ensure that no secrets are leaked even if the bus is snooped. As part of doing this conversion it was discovered that policy sessions can't work with HMAC protected authority because of missing pieces (the tpm Nonce). I've added code to work the same way as before, which will result in potential authority exposure (while still adding security for the command and the returned blob), and a fixme to redo the API to get rid of this security hole. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: add session encryption protection to tpm2_get_random()James Bottomley1-4/+17
If some entity is snooping the TPM bus, they can see the random numbers we're extracting from the TPM and do prediction attacks against their consumers. Foil this attack by using response encryption to prevent the attacker from seeing the random sequence. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: add hmac checks to tpm2_pcr_extend()James Bottomley1-17/+10
tpm2_pcr_extend() is used by trusted keys to extend a PCR to prevent a key from being re-loaded until the next reboot. To use this functionality securely, that extend must be protected by a session hmac. This patch adds HMAC protection so tampering with the tpm2_pcr_extend() command in flight is detected. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Add the rest of the session HMAC APIJames Bottomley2-0/+469
The final pieces of the HMAC API are for manipulating the session area of the command. To add an authentication HMAC session tpm_buf_append_hmac_session() is called where tpm2_append_auth() would go. If a non empty password is passed in, this is correctly added to the HMAC to prove knowledge of it without revealing it. Note that if the session is only used to encrypt or decrypt parameters (no authentication) then tpm_buf_append_hmac_session_opt() must be used instead. This functions identically to tpm_buf_append_hmac_session() when TPM_BUS_SECURITY is enabled, but differently when it isn't, because effectively nothing is appended to the session area. Next the parameters should be filled in for the command and finally tpm_buf_fill_hmac_session() is called immediately prior to transmitting the command which computes the correct HMAC and places it in the command at the session location in the tpm buffer Finally, after tpm_transmit_cmd() is called, tpm_buf_check_hmac_response() is called to check that the returned HMAC matched and collect the new state for the next use of the session, if any. The features of the session are controlled by the session attributes set in tpm_buf_append_hmac_session(). If TPM2_SA_CONTINUE_SESSION is not specified, the session will be flushed and the tpm2_auth structure freed in tpm_buf_check_hmac_response(); otherwise the session may be used again. Parameter encryption is specified by or'ing the flag TPM2_SA_DECRYPT and response encryption by or'ing the flag TPM2_SA_ENCRYPT. the various encryptions will be taken care of by tpm_buf_fill_hmac_session() and tpm_buf_check_hmac_response() respectively. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> # crypto API parts Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Add HMAC session name/handle appendJames Bottomley2-0/+155
Add tpm2_append_name() for appending to the handle area of the TPM command. When TPM_BUS_SECURITY is enabled and HMAC sessions are in use this adds the standard u32 handle to the buffer but additionally records the name of the object which must be used as part of the HMAC computation. The name of certain object types (volatile and permanent handles and NV indexes) is a hash of the public area of the object. Since this hash is not known ahead of time, it must be requested from the TPM using TPM2_ReadPublic() (which cannot be HMAC protected, but if an interposer lies about it, the HMAC check will fail and the problem will be detected). Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> # crypto API parts Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Add HMAC session start and end functionsJames Bottomley5-0/+325
Add session based HMAC authentication plus parameter decryption and response encryption using AES. The basic design is to segregate all the nasty crypto, hash and hmac code into tpm2-sessions.c and export a usable API. The API first of all starts off by gaining a session with tpm2_start_auth_session() which initiates a session with the TPM and allocates an opaque tpm2_auth structure to handle the session parameters. The design is that session use will be single threaded from start to finish under the ops lock, so the tpm2_auth structure is stored in struct tpm2_chip to simpify the externally visible API. The session can be ended with tpm2_end_auth_session() which is designed only to be used in error legs. Ordinarily the further session API (future patches) will end or continue the session appropriately without having to call this. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> # crypto API parts Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Add TCG mandated Key Derivation Functions (KDFs)James Bottomley2-0/+106
The TCG mandates two Key derivation functions called KDFa and KDFe used to derive keys from seeds and elliptic curve points respectively. The definitions for these functions are found in the TPM 2.0 Library Specification Part 1 - Architecture Guide https://trustedcomputinggroup.org/resource/tpm-library-specification/ Implement a cut down version of each of these functions sufficient to support the key derivation needs of HMAC sessions. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Add NULL primary creationJames Bottomley6-0/+418
The session handling code uses a "salted" session, meaning a session whose salt is encrypted to the public part of another TPM key so an observer cannot obtain it (and thus deduce the session keys). This patch creates and context saves in the tpm_chip area the primary key of the NULL hierarchy for this purpose. [[email protected]: fixed documentation errors] Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: export the context save and load commandsJames Bottomley2-4/+8
The TPM2 session HMAC and encryption handling code needs to save and restore a single volatile context for the elliptic curve version of the NULL seed, so export the APIs which do this for internal use. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: add buffer function to point to returned parametersJames Bottomley2-0/+30
Replace all instances of &buf.data[TPM_HEADER_SIZE] with a new function tpm_buf_parameters() because encryption sessions change where the return parameters are located in the buffer since if a return session is present they're 4 bytes beyond the header with those 4 bytes giving the parameter length. If there is no return session, then they're in the usual place immediately after the header. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09crypto: lib - implement library version of AES in CFB modeArd Biesheuvel4-0/+270
Implement AES in CFB mode using the existing, mostly constant-time generic AES library implementation. This will be used by the TPM code to encrypt communications with TPM hardware, which is often a discrete component connected using sniffable wires or traces. While a CFB template does exist, using a skcipher is a major pain for non-performance critical synchronous crypto where the algorithm is known at compile time and the data is in contiguous buffers with valid kernel virtual addresses. Tested-by: James Bottomley <[email protected]> Reviewed-by: James Bottomley <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: James Bottomley <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09KEYS: trusted: tpm2: Use struct tpm_buf for sized buffersJarkko Sakkinen1-23/+31
Take advantage of the new sized buffer (TPM2B) mode of struct tpm_buf in tpm2_seal_trusted(). This allows to add robustness to the command construction without requiring to calculate buffer sizes manually. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Add tpm_buf_read_{u8,u16,u32}Jarkko Sakkinen2-1/+83
Declare reader functions for the instances of struct tpm_buf. If the read goes out of boundary, TPM_BUF_BOUNDARY_ERROR is set, and subsequent read will do nothing. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: TPM2B formatted buffersJarkko Sakkinen2-3/+39
Declare tpm_buf_init_sized() and tpm_buf_reset_sized() for creating TPM2B formatted buffers. These buffers are also known as sized buffers in the specifications and literature. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Store the length of the tpm_buf data separately.Jarkko Sakkinen5-20/+47
TPM2B buffers, or sized buffers, have a two byte header, which contains the length of the payload as a 16-bit big-endian number, without counting in the space taken by the header. This differs from encoding in the TPM header where the length includes also the bytes taken by the header. Unbound the length of a tpm_buf from the value stored to the TPM command header. A separate encoding and decoding step so that different buffer types can be supported, with variant header format and length encoding. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Update struct tpm_buf documentation commentsJarkko Sakkinen1-5/+4
Remove deprecated portions and document enum values. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Move buffer handling from static inlines to real functionsJames Bottomley3-71/+97
separate out the tpm_buf_... handling functions from static inlines in tpm.h and move them to their own tpm-buf.c file. This is a precursor to adding new functions for other TPM type handling because the amount of code will grow from the current 70 lines in tpm.h to about 200 lines when the additions are done. 200 lines of inline functions is a bit too much to keep in a header file. Signed-off-by: James Bottomley <[email protected]> Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Remove tpm_send()Jarkko Sakkinen3-32/+12
Open code the last remaining call site for tpm_send(). Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm: Remove unused tpm_buf_tag()Jarkko Sakkinen1-7/+0
The helper function has no call sites. Thus, remove it. Signed-off-by: James Bottomley <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09char: tpm: Keep TPM_INF_IO_PORT define for HAS_IOPORT=nNiklas Schnelle2-3/+1
The recent change to handle HAS_IOPORT removed the TPM_INF_IO_PORT define for the HAS_IOPORT=n case despite the define being used in sections of code not covered by the same ifdef check. This was missed because at the moment TCG_INFINEON indirectly depends on HAS_IOPORT via PNP which depends on ACPI || ISA. As TCG_INFINEON does in principle support MMIO only use add it for COMPILE_TEST to cover the HAS_IOPORT=n case. Link: https://lore.kernel.org/lkml/[email protected]/ Fixes: dab56f80e7f9 ("char: tpm: handle HAS_IOPORT dependencies") Signed-off-by: Niklas Schnelle <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09dt-bindings: tpm: Add st,st33ktpm2xi2cMichael Haener1-0/+1
Add the ST chip st33ktpm2xi2c to the supported compatible strings of the TPM TIS I2C schema. The Chip is compliant with the TCG PC Client TPM Profile specification. For reference, a datasheet is available at: https://www.st.com/resource/en/data_brief/st33ktpm2xi2c.pdf Reviewed-by: Alexander Sverdlin <[email protected]> Signed-off-by: Michael Haener <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09Documentation: tpm_tisJarkko Sakkinen2-0/+47
Based recent discussions on LKML, provide preliminary bits of tpm_tis_core dependent drivers. Includes only bare essentials but can be extended later on case by case. This way some people may even want to read it later on. Reviewed-by: Bagas Sanjaya <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09tpm/eventlog: remove redundant assignment to variabel retColin Ian King1-1/+0
Variable ret is being assigned and error code that is never read, it is either being re-assigned in an error exit path or never referenced again on the non-error path. The assignment is redundant and can be removed. Cleans up clang scan build warning: drivers/char/tpm/eventlog/acpi.c:145:2: warning: Value stored to 'ret' is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09char: tpm: handle HAS_IOPORT dependenciesNiklas Schnelle3-15/+21
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at compile time. We thus need to add this dependency and ifdef sections of code using inb()/outb() as alternative access methods. Reviewed-by: Jarkko Sakkinen <[email protected]> Co-developed-by: Arnd Bergmann <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Niklas Schnelle <[email protected]> Acked-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09io_uring/net: add IORING_ACCEPT_POLL_FIRST flagJens Axboe2-1/+9
Similarly to how polling first is supported for receive, it makes sense to provide the same for accept. An accept operation does a lot of expensive setup, like allocating an fd, a socket/inode, etc. If no connection request is already pending, this is wasted and will just be cleaned up and freed, only to retry via the usual poll trigger. Add IORING_ACCEPT_POLL_FIRST, which tells accept to only initiate the accept request if poll says we have something to accept. Signed-off-by: Jens Axboe <[email protected]>
2024-05-09io_uring/net: add IORING_ACCEPT_DONTWAIT flagJens Axboe2-6/+10
This allows the caller to perform a non-blocking attempt, similarly to how recvmsg has MSG_DONTWAIT. If set, and we get -EAGAIN on a connection attempt, propagate the result to userspace rather than arm poll and wait for a retry. Suggested-by: Norman Maurer <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2024-05-09Merge tag 'nvme-6.9-2024-05-09' of git://git.infradead.org/nvme into block-6.9Jens Axboe6-20/+25
Pull NVMe fixes from Keith: "nvme fixes for Linux 6.9 - nvme target fixes (Sagi, Dan, Maurizo) - new vendor quirk for broken MSI (Sean)" * tag 'nvme-6.9-2024-05-09' of git://git.infradead.org/nvme: nvmet-rdma: fix possible bad dereference when freeing rsps nvmet: prevent sprintf() overflow in nvmet_subsys_nsid_exists() nvmet: make nvmet_wq unbound nvmet-auth: return the error code to the nvmet_auth_ctrl_hash() callers nvme-pci: Add quirk for broken MSIs
2024-05-09Merge tag 'hwmon-for-v6.9-rc8' of ↵Linus Torvalds2-16/+35
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - pmbus/ucd9000: Increase chip access delay to avoid random access errors - corsair-cpro: Protect kernel code against parallel hidraw access from userspace * tag 'hwmon-for-v6.9-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (pmbus/ucd9000) Increase delay from 250 to 500us hwmon: (corsair-cpro) Protect ccp->wait_input_report with a spinlock hwmon: (corsair-cpro) Use complete_all() instead of complete() in ccp_raw_event() hwmon: (corsair-cpro) Use a separate buffer for sending commands
2024-05-09cgroup: Add documentation for missing zswap memory.statUsama Arif1-0/+9
This includes zswpin, zswpout and zswpwb. Signed-off-by: Usama Arif <[email protected]> Acked-by: Nhat Pham <[email protected]> Acked-by: Johannes Weiner <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]> Message-ID: <[email protected]>
2024-05-09hwmon: (pmbus/ucd9000) Increase delay from 250 to 500usLakshmi Yadlapati1-3/+3
Following the failure observed with a delay of 250us, experiments were conducted with various delays. It was found that a delay of 350us effectively mitigated the issue. To provide a more optimal solution while still allowing a margin for stability, the delay is being adjusted to 500us. Signed-off-by: Lakshmi Yadlapati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 8d655e6523764 ("hwmon: (ucd90320) Add minimum delay between bus accesses") Reviewed-by: Eddie James <[email protected]> Cc: [email protected] Signed-off-by: Guenter Roeck <[email protected]>
2024-05-09Merge tag 'net-6.9-rc8' of ↵Linus Torvalds47-205/+519
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from bluetooth and IPsec. The bridge patch is actually a follow-up to a recent fix in the same area. We have a pending v6.8 AF_UNIX regression; it should be solved soon, but not in time for this PR. Current release - regressions: - eth: ks8851: Queue RX packets in IRQ handler instead of disabling BHs - net: bridge: fix corrupted ethernet header on multicast-to-unicast Current release - new code bugs: - xfrm: fix possible bad pointer derferencing in error path Previous releases - regressionis: - core: fix out-of-bounds access in ops_init - ipv6: - fix potential uninit-value access in __ip6_make_skb() - fib6_rules: avoid possible NULL dereference in fib6_rule_action() - tcp: use refcount_inc_not_zero() in tcp_twsk_unique(). - rtnetlink: correct nested IFLA_VF_VLAN_LIST attribute validation - rxrpc: fix congestion control algorithm - bluetooth: - l2cap: fix slab-use-after-free in l2cap_connect() - msft: fix slab-use-after-free in msft_do_close() - eth: hns3: fix kernel crash when devlink reload during initialization - eth: dsa: mv88e6xxx: add phylink_get_caps for the mv88e6320/21 family Previous releases - always broken: - xfrm: preserve vlan tags for transport mode software GRO - tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets - eth: hns3: keep using user config after hardware reset" * tag 'net-6.9-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (47 commits) net: dsa: mv88e6xxx: read cmode on mv88e6320/21 serdes only ports net: dsa: mv88e6xxx: add phylink_get_caps for the mv88e6320/21 family net: hns3: fix kernel crash when devlink reload during initialization net: hns3: fix port vlan filter not disabled issue net: hns3: use appropriate barrier function after setting a bit value net: hns3: release PTP resources if pf initialization failed net: hns3: change type of numa_node_mask as nodemask_t net: hns3: direct return when receive a unknown mailbox message net: hns3: using user configure after hardware reset net/smc: fix neighbour and rtable leak in smc_ib_find_route() ipv6: prevent NULL dereference in ip6_output() hsr: Simplify code for announcing HSR nodes timer setup ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action() dt-bindings: net: mediatek: remove wrongly added clocks and SerDes rxrpc: Only transmit one ACK per jumbo packet received rxrpc: Fix congestion control algorithm selftests: test_bridge_neigh_suppress.sh: Fix failures due to duplicate MAC ipv6: Fix potential uninit-value access in __ip6_make_skb() net: phy: marvell-88q2xxx: add support for Rev B1 and B2 appletalk: Improve handling of broadcast packets ...
2024-05-09blk-throttle: delay initialization until configurationYu Kuai4-53/+88
Other cgroup policy like bfq, iocost are lazy-initialized when they are configured for the first time for the device, but blk-throttle is initialized unconditionally from blkcg_init_disk(). Delay initialization of blk-throttle as well, to save some cpu and memory overhead if it's not configured. Noted that once it's initialized, it can't be destroyed until disk removal, even if it's disabled. Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-05-09blk-throttle: remove CONFIG_BLK_DEV_THROTTLING_LOWYu Kuai9-918/+42
One the one hand, it's marked EXPERIMENTAL since 2017, and looks like there are no users since then, and no testers and no developers, it's just not active at all. On the other hand, even if the config is disabled, there are still many fields in throtl_grp and throtl_data and many functions that are only used for throtl low. At last, currently blk-throtl is initialized during disk initialization, and destroyed during disk removal, and it exposes many functions to be called directly from block layer. Remove throtl low to make code much more cleaner and follow up work much easier. Signed-off-by: Yu Kuai <[email protected]> Acked-by: Tejun Heo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-05-09Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linuxLinus Torvalds1-0/+4
Pull ARM fix from Russell King: - clear stale KASan stack poison when a CPU resumes * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux: ARM: 9381/1: kasan: clear stale stack poison
2024-05-09regulator: core: fix debugfs creation regressionJohan Hovold1-11/+16
regulator_get() may sometimes be called more than once for the same consumer device, something which before commit dbe954d8f163 ("regulator: core: Avoid debugfs: Directory ... already present! error") resulted in errors being logged. A couple of recent commits broke the handling of such cases so that attributes are now erroneously created in the debugfs root directory the second time a regulator is requested and the log is filled with errors like: debugfs: File 'uA_load' in directory '/' already present! debugfs: File 'min_uV' in directory '/' already present! debugfs: File 'max_uV' in directory '/' already present! debugfs: File 'constraint_flags' in directory '/' already present! on any further calls. Fixes: 2715bb11cfff ("regulator: core: Fix more error checking for debugfs_create_dir()") Fixes: 08880713ceec ("regulator: core: Streamline debugfs operations") Cc: [email protected] Cc: Geert Uytterhoeven <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]>
2024-05-09Merge tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds1-0/+1
Pull dentry leak fix from Al Viro: "Dentry leak fix in the qibfs driver that I forgot to send a pull request for ;-/ My apologies - it actually sat in vfs.git#fixes for more than two months..." * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: qibfs: fix dentry leak
2024-05-09docs: trusted-encrypted: add DCP as new trust sourceDavid Gstir2-0/+72
Update the documentation for trusted and encrypted KEYS with DCP as new trust source: - Describe security properties of DCP trust source - Describe key usage - Document blob format Co-developed-by: Richard Weinberger <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Co-developed-by: David Oberhollenzer <[email protected]> Signed-off-by: David Oberhollenzer <[email protected]> Signed-off-by: David Gstir <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Reviewed-by: Bagas Sanjaya <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09docs: document DCP-backed trusted keys kernel paramsDavid Gstir1-0/+13
Document the kernel parameters trusted.dcp_use_otp_key and trusted.dcp_skip_zk_test for DCP-backed trusted keys. Co-developed-by: Richard Weinberger <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Co-developed-by: David Oberhollenzer <[email protected]> Signed-off-by: David Oberhollenzer <[email protected]> Signed-off-by: David Gstir <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09MAINTAINERS: add entry for DCP-based trusted keysDavid Gstir1-0/+9
This covers trusted keys backed by NXP's DCP (Data Co-Processor) chip found in smaller i.MX SoCs. Signed-off-by: David Gstir <[email protected]> Acked-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09KEYS: trusted: Introduce NXP DCP-backed trusted keysDavid Gstir5-1/+339
DCP (Data Co-Processor) is the little brother of NXP's CAAM IP. Beside of accelerated crypto operations, it also offers support for hardware-bound keys. Using this feature it is possible to implement a blob mechanism similar to what CAAM offers. Unlike on CAAM, constructing and parsing the blob has to happen in software (i.e. the kernel). The software-based blob format used by DCP trusted keys encrypts the payload using AES-128-GCM with a freshly generated random key and nonce. The random key itself is AES-128-ECB encrypted using the DCP unique or OTP key. The DCP trusted key blob format is: /* * struct dcp_blob_fmt - DCP BLOB format. * * @fmt_version: Format version, currently being %1 * @blob_key: Random AES 128 key which is used to encrypt @payload, * @blob_key itself is encrypted with OTP or UNIQUE device key in * AES-128-ECB mode by DCP. * @nonce: Random nonce used for @payload encryption. * @payload_len: Length of the plain text @payload. * @payload: The payload itself, encrypted using AES-128-GCM and @blob_key, * GCM auth tag of size AES_BLOCK_SIZE is attached at the end of it. * * The total size of a DCP BLOB is sizeof(struct dcp_blob_fmt) + @payload_len + * AES_BLOCK_SIZE. */ struct dcp_blob_fmt { __u8 fmt_version; __u8 blob_key[AES_KEYSIZE_128]; __u8 nonce[AES_KEYSIZE_128]; __le32 payload_len; __u8 payload[]; } __packed; By default the unique key is used. It is also possible to use the OTP key. While the unique key should be unique it is not documented how this key is derived. Therefore selection the OTP key is supported as well via the use_otp_key module parameter. Co-developed-by: Richard Weinberger <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Co-developed-by: David Oberhollenzer <[email protected]> Signed-off-by: David Oberhollenzer <[email protected]> Signed-off-by: David Gstir <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09KEYS: trusted: improve scalability of trust source configDavid Gstir1-2/+8
Enabling trusted keys requires at least one trust source implementation (currently TPM, TEE or CAAM) to be enabled. Currently, this is done by checking each trust source's config option individually. This does not scale when more trust sources like the one for DCP are added, because the condition will get long and hard to read. Add config HAVE_TRUSTED_KEYS which is set to true by each trust source once its enabled and adapt the check for having at least one active trust source to use this option. Whenever a new trust source is added, it now needs to select HAVE_TRUSTED_KEYS. Signed-off-by: David Gstir <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> # for TRUSTED_KEYS_TPM Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09crypto: mxs-dcp: Add support for hardware-bound keysDavid Gstir2-11/+113
DCP (Data Co-Processor) is able to derive private keys for a fused random seed, which can be referenced by handle but not accessed by the CPU. Similarly, DCP is able to store arbitrary keys in four dedicated key slots located in its secure memory area (internal SRAM). These keys can be used to perform AES encryption. Expose these derived keys and key slots through the crypto API via their handle. The main purpose is to add DCP-backed trusted keys. Other use cases are possible too (see similar existing paes implementations), but these should carefully be evaluated as e.g. enabling AF_ALG will give userspace full access to use keys. In scenarios with untrustworthy userspace, this will enable en-/decryption oracles. Co-developed-by: Richard Weinberger <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Co-developed-by: David Oberhollenzer <[email protected]> Signed-off-by: David Oberhollenzer <[email protected]> Signed-off-by: David Gstir <[email protected]> Acked-by: Herbert Xu <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
2024-05-09drm/xe: Use ordered WQ for G2H handlerMatthew Brost3-1/+8
System work queues are shared, use a dedicated work queue for G2H processing to avoid G2H processing getting block behind system tasks. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 50aec9665e0babd62b9eee4e613d9a1ef8d2b7de) Signed-off-by: Lucas De Marchi <[email protected]>
2024-05-09drm/xe/guc: Check error code when initializing the CT mutexDaniele Ceraolo Spurio1-1/+4
The initialization via drmm_mutex_init can fail, so we need to check the return code and escalate the failure. The mutex initialization has been moved after all the other init steps that can't fail, so we're always guaranteed to have those done and don't have to check in the cleanup code. Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Vinay Belgaumkar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit b4abeb5545bb3ddcdda3c19067680ad0b2259be4) Signed-off-by: Lucas De Marchi <[email protected]>
2024-05-09drm/xe/ads: Use flexible-arrayLucas De Marchi1-1/+1
Zero-length arrays are deprecated and flexible arrays should be used instead: https://www.kernel.org/doc/html/v6.9-rc7/process/deprecated.html#zero-length-and-one-element-arrays Reported-by: kernel test robot <[email protected]> Reported-by: Julia Lawall <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> (cherry picked from commit ee7284230644e21fef0e38fc5bf8f907b6bb7f7c) Signed-off-by: Lucas De Marchi <[email protected]>
2024-05-09gpiolib: cdev: Fix use after free in lineinfo_changed_notifyZhongqiu Han1-1/+1
The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines. Here is the typical stack when issue happened: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway. To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain. Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by: Zhongqiu Han <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
2024-05-09block: fix that util can be greater than 100%Yu Kuai1-10/+2
util means the percentage that disk has IO, and theoretically it should not be greater than 100%. However, there is a gap for rq-based disk: io_ticks will be updated when rq is allocated, however, before such rq dispatch to driver, it will not be account as inflight from blk_mq_start_request() hence diskstats_show()/part_stat_show() will not update io_ticks. For example: 1) at t0, issue a new IO, rq is allocated, and blk_account_io_start() update io_ticks; 2) something is wrong with drivers, and the rq can't be dispatched; 3) at t0 + 10s, drivers recovers and rq is dispatched and done, io_ticks is updated; Then if user is using "iostat 1" to monitor "util", between t0 - t0+9s, util will be zero, and between t0+9s - t0+10s, util will be 1000%. Fix this problem by updating io_ticks from diskstats_show() and part_stat_show() if there are rq allocated. Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-05-09block: support to account io_ticks preciselyYu Kuai5-5/+13
Currently, io_ticks is accounted based on sampling, specifically update_io_ticks() will always account io_ticks by 1 jiffies from bdev_start_io_acct()/blk_account_io_start(), and the result can be inaccurate, for example(HZ is 250): Test script: fio -filename=/dev/sda -bs=4k -rw=write -direct=1 -name=test -thinktime=4ms Test result: util is about 90%, while the disk is really idle. This behaviour is introduced by commit 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting"), however, there was a key point that is missed that this patch also improve performance a lot: Before the commit: part_round_stats: if (part->stamp != now) stats |= 1; part_in_flight() -> there can be lots of task here in 1 jiffies. part_round_stats_single() __part_stat_add() part->stamp = now; After the commit: update_io_ticks: stamp = part->bd_stamp; if (time_after(now, stamp)) if (try_cmpxchg()) __part_stat_add() -> only one task can reach here in 1 jiffies. Hence in order to account io_ticks precisely, we only need to know if there are IO inflight at most once in one jiffies. Noted that for rq-based device, iterating tags should not be used here because 'tags->lock' is grabbed in blk_mq_find_and_get_req(), hence part_stat_lock_inc/dec() and part_in_flight() is used to trace inflight. The additional overhead is quite little: - per cpu add/dec for each IO for rq-based device; - per cpu sum for each jiffies; And it's verified by null-blk that there are no performance degration under heavy IO pressure. Fixes: 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting") Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-05-09block: add plug while submitting IOYu Kuai1-0/+6
So that if caller didn't use plug, for example, __blkdev_direct_IO_simple() and __blkdev_direct_IO_async(), block layer can still benefit from caching nsec time in the plug. Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2024-05-09keys: Fix overwrite of key expiration on instantiationSilvio Gissi1-1/+2
The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry. Fixes: 39299bdd2546 ("keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry") Signed-off-by: Silvio Gissi <[email protected]> cc: David Howells <[email protected]> cc: Hazem Mohamed Abuelfotoh <[email protected]> cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>