From 3ad20df6f3f39be421dfa61d552e8e0468e06961 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 24 May 2021 11:58:37 +0200 Subject: [PATCH] 5.10-stable patches added patches: nvme-tcp-fix-possible-use-after-completion.patch rapidio-handle-create_workqueue-failure.patch revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch x86-sev-es-forward-page-faults-which-happen-during-emulation.patch x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch --- ...cp-fix-possible-use-after-completion.patch | 79 +++++++++ ...idio-handle-create_workqueue-failure.patch | 51 ++++++ ...eference-when-create_workqueue-fails.patch | 52 ++++++ ...a-potential-null-pointer-dereference.patch | 41 +++++ queue-5.10/series | 10 ++ ...-memory-leak-in-error-handling-paths.patch | 50 ++++++ ...n-t-return-null-from-sev_es_get_ghcb.patch | 74 ++++++++ ...faults-which-happen-during-emulation.patch | 37 ++++ ...te-the-ghcb-after-completing-vmgexit.patch | 52 ++++++ ...put_ghcb-in-prep-for-follow-on-patch.patch | 77 +++++++++ ...ut_user-__get_user-for-data-accesses.patch | 159 ++++++++++++++++++ 11 files changed, 682 insertions(+) create mode 100644 queue-5.10/nvme-tcp-fix-possible-use-after-completion.patch create mode 100644 queue-5.10/rapidio-handle-create_workqueue-failure.patch create mode 100644 queue-5.10/revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch create mode 100644 queue-5.10/revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch create mode 100644 queue-5.10/uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch create mode 100644 queue-5.10/x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch create mode 100644 queue-5.10/x86-sev-es-forward-page-faults-which-happen-during-emulation.patch create mode 100644 queue-5.10/x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch create mode 100644 queue-5.10/x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch create mode 100644 queue-5.10/x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch diff --git a/queue-5.10/nvme-tcp-fix-possible-use-after-completion.patch b/queue-5.10/nvme-tcp-fix-possible-use-after-completion.patch new file mode 100644 index 00000000000..c026346f163 --- /dev/null +++ b/queue-5.10/nvme-tcp-fix-possible-use-after-completion.patch @@ -0,0 +1,79 @@ +From 825619b09ad351894d2c6fb6705f5b3711d145c7 Mon Sep 17 00:00:00 2001 +From: Sagi Grimberg +Date: Mon, 17 May 2021 14:07:45 -0700 +Subject: nvme-tcp: fix possible use-after-completion + +From: Sagi Grimberg + +commit 825619b09ad351894d2c6fb6705f5b3711d145c7 upstream. + +Commit db5ad6b7f8cd ("nvme-tcp: try to send request in queue_rq +context") added a second context that may perform a network send. +This means that now RX and TX are not serialized in nvme_tcp_io_work +and can run concurrently. + +While there is correct mutual exclusion in the TX path (where +the send_mutex protect the queue socket send activity) RX activity, +and more specifically request completion may run concurrently. + +This means we must guarantee that any mutation of the request state +related to its lifetime, bytes sent must not be accessed when a completion +may have possibly arrived back (and processed). + +The race may trigger when a request completion arrives, processed +_and_ reused as a fresh new request, exactly in the (relatively short) +window between the last data payload sent and before the request iov_iter +is advanced. + +Consider the following race: +1. 16K write request is queued +2. The nvme command and the data is sent to the controller (in-capsule + or solicited by r2t) +3. After the last payload is sent but before the req.iter is advanced, + the controller sends back a completion. +4. The completion is processed, the request is completed, and reused + to transfer a new request (write or read) +5. The new request is queued, and the driver reset the request parameters + (nvme_tcp_setup_cmd_pdu). +6. Now context in (2) resumes execution and advances the req.iter + +==> use-after-completion as this is already a new request. + +Fix this by making sure the request is not advanced after the last +data payload send, knowing that a completion may have arrived already. + +An alternative solution would have been to delay the request completion +or state change waiting for reference counting on the TX path, but besides +adding atomic operations to the hot-path, it may present challenges in +multi-stage R2T scenarios where a r2t handler needs to be deferred to +an async execution. + +Reported-by: Narayan Ayalasomayajula +Tested-by: Anil Mishra +Reviewed-by: Keith Busch +Cc: stable@vger.kernel.org # v5.8+ +Signed-off-by: Sagi Grimberg +Signed-off-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/tcp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/nvme/host/tcp.c ++++ b/drivers/nvme/host/tcp.c +@@ -940,7 +940,6 @@ static int nvme_tcp_try_send_data(struct + if (ret <= 0) + return ret; + +- nvme_tcp_advance_req(req, ret); + if (queue->data_digest) + nvme_tcp_ddgst_update(queue->snd_hash, page, + offset, ret); +@@ -957,6 +956,7 @@ static int nvme_tcp_try_send_data(struct + } + return 1; + } ++ nvme_tcp_advance_req(req, ret); + } + return -EAGAIN; + } diff --git a/queue-5.10/rapidio-handle-create_workqueue-failure.patch b/queue-5.10/rapidio-handle-create_workqueue-failure.patch new file mode 100644 index 00000000000..a447a114008 --- /dev/null +++ b/queue-5.10/rapidio-handle-create_workqueue-failure.patch @@ -0,0 +1,51 @@ +From 69ce3ae36dcb03cdf416b0862a45369ddbf50fdf Mon Sep 17 00:00:00 2001 +From: Anirudh Rayabharam +Date: Mon, 3 May 2021 13:57:12 +0200 +Subject: rapidio: handle create_workqueue() failure + +From: Anirudh Rayabharam + +commit 69ce3ae36dcb03cdf416b0862a45369ddbf50fdf upstream. + +In case create_workqueue() fails, release all resources and return -ENOMEM +to caller to avoid potential NULL pointer deref later. Move up the +create_workequeue() call to return early and avoid unwinding the call to +riocm_rx_fill(). + +Cc: Alexandre Bounine +Cc: Matt Porter +Cc: Andrew Morton +Cc: Linus Torvalds +Cc: stable +Signed-off-by: Anirudh Rayabharam +Link: https://lore.kernel.org/r/20210503115736.2104747-46-gregkh@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/rapidio/rio_cm.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/rapidio/rio_cm.c ++++ b/drivers/rapidio/rio_cm.c +@@ -2127,6 +2127,14 @@ static int riocm_add_mport(struct device + return -ENODEV; + } + ++ cm->rx_wq = create_workqueue(DRV_NAME "/rxq"); ++ if (!cm->rx_wq) { ++ rio_release_inb_mbox(mport, cmbox); ++ rio_release_outb_mbox(mport, cmbox); ++ kfree(cm); ++ return -ENOMEM; ++ } ++ + /* + * Allocate and register inbound messaging buffers to be ready + * to receive channel and system management requests +@@ -2137,7 +2145,6 @@ static int riocm_add_mport(struct device + cm->rx_slots = RIOCM_RX_RING_SIZE; + mutex_init(&cm->rx_lock); + riocm_rx_fill(cm, RIOCM_RX_RING_SIZE); +- cm->rx_wq = create_workqueue(DRV_NAME "/rxq"); + INIT_WORK(&cm->rx_work, rio_ibmsg_handler); + + cm->tx_slot = 0; diff --git a/queue-5.10/revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch b/queue-5.10/revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch new file mode 100644 index 00000000000..6215895af3c --- /dev/null +++ b/queue-5.10/revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch @@ -0,0 +1,52 @@ +From 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Mon, 3 May 2021 13:57:11 +0200 +Subject: Revert "rapidio: fix a NULL pointer dereference when create_workqueue() fails" + +From: Greg Kroah-Hartman + +commit 5e68b86c7b7c059c0f0ec4bf8adabe63f84a61eb upstream. + +This reverts commit 23015b22e47c5409620b1726a677d69e5cd032ba. + +Because of recent interactions with developers from @umn.edu, all +commits from them have been recently re-reviewed to ensure if they were +correct or not. + +Upon review, this commit was found to be incorrect for the reasons +below, so it must be reverted. It will be fixed up "correctly" in a +later kernel change. + +The original commit has a memory leak on the error path here, it does +not clean up everything properly. + +Cc: Kangjie Lu +Cc: Alexandre Bounine +Cc: Matt Porter +Cc: Andrew Morton +Cc: Linus Torvalds +Fixes: 23015b22e47c ("rapidio: fix a NULL pointer dereference when create_workqueue() fails") +Cc: stable +Link: https://lore.kernel.org/r/20210503115736.2104747-45-gregkh@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/rapidio/rio_cm.c | 8 -------- + 1 file changed, 8 deletions(-) + +--- a/drivers/rapidio/rio_cm.c ++++ b/drivers/rapidio/rio_cm.c +@@ -2138,14 +2138,6 @@ static int riocm_add_mport(struct device + mutex_init(&cm->rx_lock); + riocm_rx_fill(cm, RIOCM_RX_RING_SIZE); + cm->rx_wq = create_workqueue(DRV_NAME "/rxq"); +- if (!cm->rx_wq) { +- riocm_error("failed to allocate IBMBOX_%d on %s", +- cmbox, mport->name); +- rio_release_outb_mbox(mport, cmbox); +- kfree(cm); +- return -ENOMEM; +- } +- + INIT_WORK(&cm->rx_work, rio_ibmsg_handler); + + cm->tx_slot = 0; diff --git a/queue-5.10/revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch b/queue-5.10/revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch new file mode 100644 index 00000000000..bb01d7b6724 --- /dev/null +++ b/queue-5.10/revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch @@ -0,0 +1,41 @@ +From 754f39158441f4c0d7a8255209dd9a939f08ce80 Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Mon, 3 May 2021 13:56:32 +0200 +Subject: Revert "serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference" + +From: Greg Kroah-Hartman + +commit 754f39158441f4c0d7a8255209dd9a939f08ce80 upstream. + +This reverts commit 32f47179833b63de72427131169809065db6745e. + +Because of recent interactions with developers from @umn.edu, all +commits from them have been recently re-reviewed to ensure if they were +correct or not. + +Upon review, this commit was found to be not be needed at all as the +change was useless because this function can only be called when +of_match_device matched on something. So it should be reverted. + +Cc: Aditya Pakki +Cc: stable +Fixes: 32f47179833b ("serial: mvebu-uart: Fix to avoid a potential NULL pointer dereference") +Acked-by: Jiri Slaby +Link: https://lore.kernel.org/r/20210503115736.2104747-6-gregkh@linuxfoundation.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/mvebu-uart.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/drivers/tty/serial/mvebu-uart.c ++++ b/drivers/tty/serial/mvebu-uart.c +@@ -818,9 +818,6 @@ static int mvebu_uart_probe(struct platf + return -EINVAL; + } + +- if (!match) +- return -ENODEV; +- + /* Assume that all UART ports have a DT alias or none has */ + id = of_alias_get_id(pdev->dev.of_node, "serial"); + if (!pdev->dev.of_node || id < 0) diff --git a/queue-5.10/series b/queue-5.10/series index 688fb458ce8..8029ddd1481 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -47,3 +47,13 @@ alsa-hda-realtek-add-some-clove-ssids-of-alc293.patch alsa-hda-realtek-fix-silent-headphone-output-on-asus-ux430ua.patch alsa-hda-realtek-add-fixup-for-hp-omen-laptop.patch alsa-hda-realtek-add-fixup-for-hp-spectre-x360-15-df0xxx.patch +uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch +revert-rapidio-fix-a-null-pointer-dereference-when-create_workqueue-fails.patch +rapidio-handle-create_workqueue-failure.patch +revert-serial-mvebu-uart-fix-to-avoid-a-potential-null-pointer-dereference.patch +nvme-tcp-fix-possible-use-after-completion.patch +x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch +x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch +x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch +x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch +x86-sev-es-forward-page-faults-which-happen-during-emulation.patch diff --git a/queue-5.10/uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch b/queue-5.10/uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch new file mode 100644 index 00000000000..f02b54e3435 --- /dev/null +++ b/queue-5.10/uio_hv_generic-fix-a-memory-leak-in-error-handling-paths.patch @@ -0,0 +1,50 @@ +From 3ee098f96b8b6c1a98f7f97915f8873164e6af9d Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Sun, 9 May 2021 09:13:03 +0200 +Subject: uio_hv_generic: Fix a memory leak in error handling paths + +From: Christophe JAILLET + +commit 3ee098f96b8b6c1a98f7f97915f8873164e6af9d upstream. + +If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be +updated and 'hv_uio_cleanup()' in the error handling path will not be +able to free the corresponding buffer. + +In such a case, we need to free the buffer explicitly. + +Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use") +Cc: stable +Signed-off-by: Christophe JAILLET +Link: https://lore.kernel.org/r/4fdaff557deef6f0475d02ba7922ddbaa1ab08a6.1620544055.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Greg Kroah-Hartman +--- + drivers/uio/uio_hv_generic.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/uio/uio_hv_generic.c ++++ b/drivers/uio/uio_hv_generic.c +@@ -296,8 +296,10 @@ hv_uio_probe(struct hv_device *dev, + + ret = vmbus_establish_gpadl(channel, pdata->recv_buf, + RECV_BUFFER_SIZE, &pdata->recv_gpadl); +- if (ret) ++ if (ret) { ++ vfree(pdata->recv_buf); + goto fail_close; ++ } + + /* put Global Physical Address Label in name */ + snprintf(pdata->recv_name, sizeof(pdata->recv_name), +@@ -316,8 +318,10 @@ hv_uio_probe(struct hv_device *dev, + + ret = vmbus_establish_gpadl(channel, pdata->send_buf, + SEND_BUFFER_SIZE, &pdata->send_gpadl); +- if (ret) ++ if (ret) { ++ vfree(pdata->send_buf); + goto fail_close; ++ } + + snprintf(pdata->send_name, sizeof(pdata->send_name), + "send:%u", pdata->send_gpadl); diff --git a/queue-5.10/x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch b/queue-5.10/x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch new file mode 100644 index 00000000000..e71f62a42a7 --- /dev/null +++ b/queue-5.10/x86-sev-es-don-t-return-null-from-sev_es_get_ghcb.patch @@ -0,0 +1,74 @@ +From b250f2f7792d15bcde98e0456781e2835556d5fa Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Wed, 19 May 2021 15:52:44 +0200 +Subject: x86/sev-es: Don't return NULL from sev_es_get_ghcb() + +From: Joerg Roedel + +commit b250f2f7792d15bcde98e0456781e2835556d5fa upstream. + +sev_es_get_ghcb() is called from several places but only one of them +checks the return value. The reaction to returning NULL is always the +same: calling panic() and kill the machine. + +Instead of adding checks to all call sites, move the panic() into the +function itself so that it will no longer return NULL. + +Fixes: 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler") +Signed-off-by: Joerg Roedel +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org # v5.10+ +Link: https://lkml.kernel.org/r/20210519135251.30093-2-joro@8bytes.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es.c | 25 ++++++++++++------------- + 1 file changed, 12 insertions(+), 13 deletions(-) + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -191,8 +191,18 @@ static __always_inline struct ghcb *sev_ + if (unlikely(data->ghcb_active)) { + /* GHCB is already in use - save its contents */ + +- if (unlikely(data->backup_ghcb_active)) +- return NULL; ++ if (unlikely(data->backup_ghcb_active)) { ++ /* ++ * Backup-GHCB is also already in use. There is no way ++ * to continue here so just kill the machine. To make ++ * panic() work, mark GHCBs inactive so that messages ++ * can be printed out. ++ */ ++ data->ghcb_active = false; ++ data->backup_ghcb_active = false; ++ ++ panic("Unable to handle #VC exception! GHCB and Backup GHCB are already in use"); ++ } + + /* Mark backup_ghcb active before writing to it */ + data->backup_ghcb_active = true; +@@ -1262,7 +1272,6 @@ static __always_inline bool on_vc_fallba + */ + DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication) + { +- struct sev_es_runtime_data *data = this_cpu_read(runtime_data); + irqentry_state_t irq_state; + struct ghcb_state state; + struct es_em_ctxt ctxt; +@@ -1288,16 +1297,6 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_co + */ + + ghcb = sev_es_get_ghcb(&state); +- if (!ghcb) { +- /* +- * Mark GHCBs inactive so that panic() is able to print the +- * message. +- */ +- data->ghcb_active = false; +- data->backup_ghcb_active = false; +- +- panic("Unable to handle #VC exception! GHCB and Backup GHCB are already in use"); +- } + + vc_ghcb_invalidate(ghcb); + result = vc_init_em_ctxt(&ctxt, regs, error_code); diff --git a/queue-5.10/x86-sev-es-forward-page-faults-which-happen-during-emulation.patch b/queue-5.10/x86-sev-es-forward-page-faults-which-happen-during-emulation.patch new file mode 100644 index 00000000000..13d02f3b7c6 --- /dev/null +++ b/queue-5.10/x86-sev-es-forward-page-faults-which-happen-during-emulation.patch @@ -0,0 +1,37 @@ +From c25bbdb564060adaad5c3a8a10765c13487ba6a3 Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Wed, 19 May 2021 15:52:45 +0200 +Subject: x86/sev-es: Forward page-faults which happen during emulation + +From: Joerg Roedel + +commit c25bbdb564060adaad5c3a8a10765c13487ba6a3 upstream. + +When emulating guest instructions for MMIO or IOIO accesses, the #VC +handler might get a page-fault and will not be able to complete. Forward +the page-fault in this case to the correct handler instead of killing +the machine. + +Fixes: 0786138c78e7 ("x86/sev-es: Add a Runtime #VC Exception Handler") +Signed-off-by: Joerg Roedel +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org # v5.10+ +Link: https://lkml.kernel.org/r/20210519135251.30093-3-joro@8bytes.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -1269,6 +1269,10 @@ static __always_inline void vc_forward_e + case X86_TRAP_UD: + exc_invalid_op(ctxt->regs); + break; ++ case X86_TRAP_PF: ++ write_cr2(ctxt->fi.cr2); ++ exc_page_fault(ctxt->regs, error_code); ++ break; + case X86_TRAP_AC: + exc_alignment_check(ctxt->regs, error_code); + break; diff --git a/queue-5.10/x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch b/queue-5.10/x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch new file mode 100644 index 00000000000..2f12e3612d8 --- /dev/null +++ b/queue-5.10/x86-sev-es-invalidate-the-ghcb-after-completing-vmgexit.patch @@ -0,0 +1,52 @@ +From a50c5bebc99c525e7fbc059988c6a5ab8680cb76 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +Date: Mon, 17 May 2021 12:42:33 -0500 +Subject: x86/sev-es: Invalidate the GHCB after completing VMGEXIT + +From: Tom Lendacky + +commit a50c5bebc99c525e7fbc059988c6a5ab8680cb76 upstream. + +Since the VMGEXIT instruction can be issued from userspace, invalidate +the GHCB after performing VMGEXIT processing in the kernel. + +Invalidation is only required after userspace is available, so call +vc_ghcb_invalidate() from sev_es_put_ghcb(). Update vc_ghcb_invalidate() +to additionally clear the GHCB exit code so that it is always presented +as 0 when VMGEXIT has been issued by anything else besides the kernel. + +Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler") +Signed-off-by: Tom Lendacky +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/5a8130462e4f0057ee1184509cd056eedd78742b.1621273353.git.thomas.lendacky@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es-shared.c | 1 + + arch/x86/kernel/sev-es.c | 5 +++++ + 2 files changed, 6 insertions(+) + +--- a/arch/x86/kernel/sev-es-shared.c ++++ b/arch/x86/kernel/sev-es-shared.c +@@ -63,6 +63,7 @@ static bool sev_es_negotiate_protocol(vo + + static __always_inline void vc_ghcb_invalidate(struct ghcb *ghcb) + { ++ ghcb->save.sw_exit_code = 0; + memset(ghcb->save.valid_bitmap, 0, sizeof(ghcb->save.valid_bitmap)); + } + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -430,6 +430,11 @@ static __always_inline void sev_es_put_g + data->backup_ghcb_active = false; + state->ghcb = NULL; + } else { ++ /* ++ * Invalidate the GHCB so a VMGEXIT instruction issued ++ * from userspace won't appear to be valid. ++ */ ++ vc_ghcb_invalidate(ghcb); + data->ghcb_active = false; + } + } diff --git a/queue-5.10/x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch b/queue-5.10/x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch new file mode 100644 index 00000000000..62bc8e2a618 --- /dev/null +++ b/queue-5.10/x86-sev-es-move-sev_es_put_ghcb-in-prep-for-follow-on-patch.patch @@ -0,0 +1,77 @@ +From fea63d54f7a3e74f8ab489a8b82413a29849a594 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +Date: Mon, 17 May 2021 12:42:32 -0500 +Subject: x86/sev-es: Move sev_es_put_ghcb() in prep for follow on patch + +From: Tom Lendacky + +commit fea63d54f7a3e74f8ab489a8b82413a29849a594 upstream. + +Move the location of sev_es_put_ghcb() in preparation for an update to it +in a follow-on patch. This will better highlight the changes being made +to the function. + +No functional change. + +Fixes: 0786138c78e79 ("x86/sev-es: Add a Runtime #VC Exception Handler") +Signed-off-by: Tom Lendacky +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/8c07662ec17d3d82e5c53841a1d9e766d3bdbab6.1621273353.git.thomas.lendacky@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es.c | 36 ++++++++++++++++++------------------ + 1 file changed, 18 insertions(+), 18 deletions(-) + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -209,24 +209,6 @@ static __always_inline struct ghcb *sev_ + return ghcb; + } + +-static __always_inline void sev_es_put_ghcb(struct ghcb_state *state) +-{ +- struct sev_es_runtime_data *data; +- struct ghcb *ghcb; +- +- data = this_cpu_read(runtime_data); +- ghcb = &data->ghcb_page; +- +- if (state->ghcb) { +- /* Restore GHCB from Backup */ +- *ghcb = *state->ghcb; +- data->backup_ghcb_active = false; +- state->ghcb = NULL; +- } else { +- data->ghcb_active = false; +- } +-} +- + /* Needed in vc_early_forward_exception */ + void do_early_exception(struct pt_regs *regs, int trapnr); + +@@ -434,6 +416,24 @@ static enum es_result vc_slow_virt_to_ph + /* Include code shared with pre-decompression boot stage */ + #include "sev-es-shared.c" + ++static __always_inline void sev_es_put_ghcb(struct ghcb_state *state) ++{ ++ struct sev_es_runtime_data *data; ++ struct ghcb *ghcb; ++ ++ data = this_cpu_read(runtime_data); ++ ghcb = &data->ghcb_page; ++ ++ if (state->ghcb) { ++ /* Restore GHCB from Backup */ ++ *ghcb = *state->ghcb; ++ data->backup_ghcb_active = false; ++ state->ghcb = NULL; ++ } else { ++ data->ghcb_active = false; ++ } ++} ++ + void noinstr __sev_es_nmi_complete(void) + { + struct ghcb_state state; diff --git a/queue-5.10/x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch b/queue-5.10/x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch new file mode 100644 index 00000000000..caf75f85fc0 --- /dev/null +++ b/queue-5.10/x86-sev-es-use-__put_user-__get_user-for-data-accesses.patch @@ -0,0 +1,159 @@ +From 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 Mon Sep 17 00:00:00 2001 +From: Joerg Roedel +Date: Wed, 19 May 2021 15:52:46 +0200 +Subject: x86/sev-es: Use __put_user()/__get_user() for data accesses + +From: Joerg Roedel + +commit 4954f5b8ef0baf70fe978d1a99a5f70e4dd5c877 upstream. + +The put_user() and get_user() functions do checks on the address which is +passed to them. They check whether the address is actually a user-space +address and whether its fine to access it. They also call might_fault() +to indicate that they could fault and possibly sleep. + +All of these checks are neither wanted nor needed in the #VC exception +handler, which can be invoked from almost any context and also for MMIO +instructions from kernel space on kernel memory. All the #VC handler +wants to know is whether a fault happened when the access was tried. + +This is provided by __put_user()/__get_user(), which just do the access +no matter what. Also add comments explaining why __get_user() and +__put_user() are the best choice here and why it is safe to use them +in this context. Also explain why copy_to/from_user can't be used. + +In addition, also revert commit + + 7024f60d6552 ("x86/sev-es: Handle string port IO to kernel memory properly") + +because using __get_user()/__put_user() fixes the same problem while +the above commit introduced several problems: + + 1) It uses access_ok() which is only allowed in task context. + + 2) It uses memcpy() which has no fault handling at all and is + thus unsafe to use here. + + [ bp: Fix up commit ID of the reverted commit above. ] + +Fixes: f980f9c31a92 ("x86/sev-es: Compile early handler code into kernel image") +Signed-off-by: Joerg Roedel +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org # v5.10+ +Link: https://lkml.kernel.org/r/20210519135251.30093-4-joro@8bytes.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/sev-es.c | 66 ++++++++++++++++++++++++++++++++--------------- + 1 file changed, 46 insertions(+), 20 deletions(-) + +--- a/arch/x86/kernel/sev-es.c ++++ b/arch/x86/kernel/sev-es.c +@@ -288,31 +288,44 @@ static enum es_result vc_write_mem(struc + u16 d2; + u8 d1; + +- /* If instruction ran in kernel mode and the I/O buffer is in kernel space */ +- if (!user_mode(ctxt->regs) && !access_ok(target, size)) { +- memcpy(dst, buf, size); +- return ES_OK; +- } +- ++ /* ++ * This function uses __put_user() independent of whether kernel or user ++ * memory is accessed. This works fine because __put_user() does no ++ * sanity checks of the pointer being accessed. All that it does is ++ * to report when the access failed. ++ * ++ * Also, this function runs in atomic context, so __put_user() is not ++ * allowed to sleep. The page-fault handler detects that it is running ++ * in atomic context and will not try to take mmap_sem and handle the ++ * fault, so additional pagefault_enable()/disable() calls are not ++ * needed. ++ * ++ * The access can't be done via copy_to_user() here because ++ * vc_write_mem() must not use string instructions to access unsafe ++ * memory. The reason is that MOVS is emulated by the #VC handler by ++ * splitting the move up into a read and a write and taking a nested #VC ++ * exception on whatever of them is the MMIO access. Using string ++ * instructions here would cause infinite nesting. ++ */ + switch (size) { + case 1: + memcpy(&d1, buf, 1); +- if (put_user(d1, target)) ++ if (__put_user(d1, target)) + goto fault; + break; + case 2: + memcpy(&d2, buf, 2); +- if (put_user(d2, target)) ++ if (__put_user(d2, target)) + goto fault; + break; + case 4: + memcpy(&d4, buf, 4); +- if (put_user(d4, target)) ++ if (__put_user(d4, target)) + goto fault; + break; + case 8: + memcpy(&d8, buf, 8); +- if (put_user(d8, target)) ++ if (__put_user(d8, target)) + goto fault; + break; + default: +@@ -343,30 +356,43 @@ static enum es_result vc_read_mem(struct + u16 d2; + u8 d1; + +- /* If instruction ran in kernel mode and the I/O buffer is in kernel space */ +- if (!user_mode(ctxt->regs) && !access_ok(s, size)) { +- memcpy(buf, src, size); +- return ES_OK; +- } +- ++ /* ++ * This function uses __get_user() independent of whether kernel or user ++ * memory is accessed. This works fine because __get_user() does no ++ * sanity checks of the pointer being accessed. All that it does is ++ * to report when the access failed. ++ * ++ * Also, this function runs in atomic context, so __get_user() is not ++ * allowed to sleep. The page-fault handler detects that it is running ++ * in atomic context and will not try to take mmap_sem and handle the ++ * fault, so additional pagefault_enable()/disable() calls are not ++ * needed. ++ * ++ * The access can't be done via copy_from_user() here because ++ * vc_read_mem() must not use string instructions to access unsafe ++ * memory. The reason is that MOVS is emulated by the #VC handler by ++ * splitting the move up into a read and a write and taking a nested #VC ++ * exception on whatever of them is the MMIO access. Using string ++ * instructions here would cause infinite nesting. ++ */ + switch (size) { + case 1: +- if (get_user(d1, s)) ++ if (__get_user(d1, s)) + goto fault; + memcpy(buf, &d1, 1); + break; + case 2: +- if (get_user(d2, s)) ++ if (__get_user(d2, s)) + goto fault; + memcpy(buf, &d2, 2); + break; + case 4: +- if (get_user(d4, s)) ++ if (__get_user(d4, s)) + goto fault; + memcpy(buf, &d4, 4); + break; + case 8: +- if (get_user(d8, s)) ++ if (__get_user(d8, s)) + goto fault; + memcpy(buf, &d8, 8); + break; -- 2.47.3