Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #79093 > unrolled thread

Bug#1036543: linux: WARNING at drivers/crypto/ccp/sev-dev.c:168 __sev_do_cmd_locked+0x31b/0x350 [ccp]

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1036543: linux: WARNING at drivers/crypto/ccp/sev-dev.c:168 __sev_do_cmd_locked+0x31b/0x350 [ccp] Julien Cristau <jcristau@debian.org> - 2023-05-22 11:00 +0200
    Processed: linux: WARNING at drivers/crypto/ccp/sev-dev.c:168  __sev_do_cmd_locked+0x31b/0x350 [ccp] "Debian Bug Tracking System" <owner@bugs.debian.org> - 2023-05-22 11:00 +0200
    Bug#1036543: [PATCH 5.10 076/529] crypto: ccp: Use the stack for small SEV command buffers Ben Hutchings <ben@decadent.org.uk> - 2023-05-26 17:40 +0200
      Bug#1036543: [PATCH 5.10 076/529] crypto: ccp: Use the stack for small SEV command buffers Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2023-06-07 20:10 +0200

#79093 — Bug#1036543: linux: WARNING at drivers/crypto/ccp/sev-dev.c:168 __sev_do_cmd_locked+0x31b/0x350 [ccp]

Source: linux
Version: 5.10.179-1
Severity: normal
Tags: upstream
Control: found -1 5.10.178-3
User: debian-admin@lists.debian.org
Usertags: needed-by-DSA-Team
X-Debbugs-Cc: debian-admin@lists.debian.org, jcristau@debian.org

Hi,

We're seeing a new WARNING in kernel logs on several Lenovo servers
since the latest bullseye point release, when the ccp module gets
loaded:

> ccp 0000:44:00.1: no command queues available
> ccp 0000:44:00.1: sev enabled
> ccp 0000:44:00.1: psp enabled
> ------------[ cut here ]------------
> WARNING: CPU: 87 PID: 1534 at drivers/crypto/ccp/sev-dev.c:168 __sev_do_cmd_locked+0x31b/0x350 [ccp]
> Modules linked in: ccp(+) rng_core kvm irqbypass ip6t_REJECT nf_reject_ipv6 ip6table_filter ip6_tables nfnetlink_log nfnetlink xt_hashlimit ipt_REJECT nf_reject_ipv4 xt_NFLOG xt_multiport xt_tcpudp xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter loop tun sch_fq tcp_bbr usbhid uas usb_storage sr_mod cdrom joydev hid_generic hid cdc_ether usbnet mii drbd drm lru_cache fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 raid10 raid1 raid0 multipath linear dm_mod raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor sd_mod raid6_pq libcrc32c crc32c_generic crc32_pclmul crc32c_intel md_mod ahci libahci xhci_pci xhci_hcd libata tg3 nvme usbcore nvme_core libphy t10_pi bnxt_en scsi_mod crc_t10dif crct10dif_generic usb_common i2c_piix4 ptp crct10dif_pclmul crct10dif_common pps_core
> CPU: 87 PID: 1534 Comm: systemd-modules Not tainted 5.10.0-23-amd64 #1 Debian 5.10.179-1
> Hardware name: Lenovo ThinkSystem SR635 -[7Y99CTO1WW]-/-[7Y99CTO1WW]-, BIOS CFE126V 06/23/2021
> RIP: 0010:__sev_do_cmd_locked+0x31b/0x350 [ccp]
> Code: 31 ed e9 a1 fd ff ff 48 8b 33 44 89 e9 48 c7 c2 f8 fb c4 c0 48 c7 c7 a0 2c c5 c0 e8 8f d9 28 de b8 fb ff ff ff e9 3b fe ff ff <0f> 0b b8 ea ff ff ff e9 34 fe ff ff 44 89 fd e9 f4 fe ff ff b8 f0
> RSP: 0018:ffffb75f82c0fcf8 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff90986ef00e98 RCX: 0000000000000000
> RDX: 000000000004d908 RSI: 00000000000009b2 RDI: ffffb76002c0fd6c
> RBP: ffffffffc0c59000 R08: 0000000000000000 R09: ffffb75f82c0fc90
> R10: ffff9098c49bb000 R11: ffffffffa02153e0 R12: ffffb75f82c0fd6c
> R13: 0000000000000004 R14: ffffb75f82c0fd68 R15: 0000000000000000
> FS:  00007f3466446900(0000) GS:ffff90f60e5c0000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000557be22d1c98 CR3: 0000000131af8000 CR4: 0000000000350ee0
> Call Trace:
>  ? kobject_uevent_env+0x11f/0x6a0
>  ? kfree+0xba/0x490
>  ? 0xffffffffc0c59000
>  sev_get_api_version+0x4a/0xa0 [ccp]
>  sev_pci_init+0x46/0x300 [ccp]
>  ? bus_add_driver+0x1a8/0x200
>  ? 0xffffffffc0c59000
>  sp_mod_init+0x18/0x1000 [ccp]
>  do_one_initcall+0x44/0x1e0
>  ? do_init_module+0x23/0x250
>  ? kmem_cache_alloc_trace+0xf5/0x200
>  do_init_module+0x4c/0x250
>  __do_sys_finit_module+0xb1/0x120
>  do_syscall_64+0x33/0x80
>  entry_SYSCALL_64_after_hwframe+0x61/0xc6
> RIP: 0033:0x7f3466d15f29
> Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 37 8f 0d 00 f7 d8 64 89 01 48
> RSP: 002b:00007ffcbd5be308 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
> RAX: ffffffffffffffda RBX: 0000557be22ca9c0 RCX: 00007f3466d15f29
> RDX: 0000000000000000 RSI: 00007f3466e09e2d RDI: 0000000000000008
> RBP: 0000000000020000 R08: 0000000000000000 R09: 0000557be22ca9c0
> R10: 0000000000000008 R11: 0000000000000246 R12: 00007f3466e09e2d
> R13: 0000000000000000 R14: 0000557be22ca970 R15: 0000557be22ca9c0
> ---[ end trace e089f2660ccf25dd ]---
> ccp 0000:44:00.1: SEV: failed to get status. Error: 0x0

Ben forwarded the report to
https://lore.kernel.org/stable/2023051729-jumbo-uncolored-05c1@gregkh/T/#mf89c978a24a0297b279e87de5fa19741f2c63980
after I mentioned it on IRC.

Cheers,
Julien

[toc] | [next] | [standalone]

#79094 — Processed: linux: WARNING at drivers/crypto/ccp/sev-dev.c:168 __sev_do_cmd_locked+0x31b/0x350 [ccp]

Processing control commands:

> found -1 5.10.178-3
Bug #1036543 [src:linux] linux: WARNING at drivers/crypto/ccp/sev-dev.c:168 __sev_do_cmd_locked+0x31b/0x350 [ccp]
Marked as found in versions linux/5.10.178-3.

-- 
1036543: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036543
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#79155 — Bug#1036543: [PATCH 5.10 076/529] crypto: ccp: Use the stack for small SEV command buffers

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2023-05-17 at 16:06 +0200, Greg Kroah-Hartman wrote:
> On Wed, May 17, 2023 at 04:02:35PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 17, 2023 at 02:56:21PM +0200, Ben Hutchings wrote:
> > > On Fri, 2023-03-10 at 14:33 +0100, Greg Kroah-Hartman wrote:
> > > > From: Sean Christopherson <seanjc@google.com>
> > > > 
> > > > [ Upstream commit e4a9af799e5539b0feb99571f0aaed5a3c81dc5a ]
> > > > 
> > > > For commands with small input/output buffers, use the local stack to
> > > > "allocate" the structures used to communicate with the PSP.   Now that
> > > > __sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no
> > > > reason to avoid using the stack, e.g. CONFIG_VMAP_STACK=y will just work.
> > > [...]
> > > 
> > > Julien Cristau reported a regression in ccp - the
> > > WARN_ON_ONCE(!virt_addr_valid(data)) is now being triggered.  I believe
> > > this was introduced by the above commit, which depends on:
> > > 
> > > commit 8347b99473a313be6549a5b940bc3c56a71be81c
> > > Author: Sean Christopherson <seanjc@google.com>
> > > Date:   Tue Apr 6 15:49:48 2021 -0700
> > >  
> > >     crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
> > > 
> > > Ben.
> > > 
> > 
> > Thanks for letting me know, now queued up.
> 
> Nope, now dropped, it breaks the build :(

I've now looked further and found that we need both:

d5760dee127b crypto: ccp: Reject SEV commands with mismatching command buffer
8347b99473a3 crypto: ccp: Play nice with vmalloc'd memory for SEV command structs

(Not yet tested; I'll ask Julien if he can do that.)

Ben.

-- 
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.

[toc] | [prev] | [next] | [standalone]

#79238 — Bug#1036543: [PATCH 5.10 076/529] crypto: ccp: Use the stack for small SEV command buffers

On Fri, May 26, 2023 at 05:36:02PM +0200, Ben Hutchings wrote:
> On Wed, 2023-05-17 at 16:06 +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 17, 2023 at 04:02:35PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, May 17, 2023 at 02:56:21PM +0200, Ben Hutchings wrote:
> > > > On Fri, 2023-03-10 at 14:33 +0100, Greg Kroah-Hartman wrote:
> > > > > From: Sean Christopherson <seanjc@google.com>
> > > > > 
> > > > > [ Upstream commit e4a9af799e5539b0feb99571f0aaed5a3c81dc5a ]
> > > > > 
> > > > > For commands with small input/output buffers, use the local stack to
> > > > > "allocate" the structures used to communicate with the PSP.   Now that
> > > > > __sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no
> > > > > reason to avoid using the stack, e.g. CONFIG_VMAP_STACK=y will just work.
> > > > [...]
> > > > 
> > > > Julien Cristau reported a regression in ccp - the
> > > > WARN_ON_ONCE(!virt_addr_valid(data)) is now being triggered.  I believe
> > > > this was introduced by the above commit, which depends on:
> > > > 
> > > > commit 8347b99473a313be6549a5b940bc3c56a71be81c
> > > > Author: Sean Christopherson <seanjc@google.com>
> > > > Date:   Tue Apr 6 15:49:48 2021 -0700
> > > >  
> > > >     crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
> > > > 
> > > > Ben.
> > > > 
> > > 
> > > Thanks for letting me know, now queued up.
> > 
> > Nope, now dropped, it breaks the build :(
> 
> I've now looked further and found that we need both:
> 
> d5760dee127b crypto: ccp: Reject SEV commands with mismatching command buffer
> 8347b99473a3 crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
> 
> (Not yet tested; I'll ask Julien if he can do that.)

Looks sane to me, both now queued up, thanks.

greg k-h

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web