Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5632C05027 for ; Mon, 23 Jan 2023 23:43:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232314AbjAWXnU (ORCPT ); Mon, 23 Jan 2023 18:43:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232021AbjAWXnS (ORCPT ); Mon, 23 Jan 2023 18:43:18 -0500 Received: from gnuweeb.org (gnuweeb.org [51.81.211.47]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79EA630284 for ; Mon, 23 Jan 2023 15:43:10 -0800 (PST) Received: from biznet-home.integral.gnuweeb.org (unknown [182.253.88.152]) by gnuweeb.org (Postfix) with ESMTPSA id 360FF824E0; Mon, 23 Jan 2023 23:43:05 +0000 (UTC) X-GW-Data: lPqxHiMPbJw1wb7CM9QUryAGzr0yq5atzVDdxTR0iA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=default; t=1674517390; bh=9DfZPqZPMZoxg4dALK/KfFdag/hMsQm1yfpdpUWQNlM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VmCh6LwnGcm+A8xipz/T13V/dm/ltum2pcvT0pPb5G5biVrRXsu9RUUZxrpe6Eyti F57r+b8B+8GRqwEhFXR592b3h6LW/fuduCBp1o/EBEhxt53Y87PlbT1TAs3INVNf2e B8d7vsVcNru8bNpckIHtLOji6vmKKe7Uybecm0QAejEAMH+ztrXhajSjdBrZ4sc8Tb AJNW79Ey+lGoGpoFnogajzAHsnNJ5awyrQIqaGvLGqki8+Pu4K0yIRxLw4jnCTW4E0 KEYmq8g79BBY99jdOT4cqBcxH9gz8qRbLYuInWytIoWYrkqeEmqFVnUgogcPgLu430 m2jbYLnxicgkg== Date: Tue, 24 Jan 2023 06:43:02 +0700 From: Ammar Faizi To: "H. Peter Anvin" Cc: Dave Hansen , Dave Hansen , Xin Li , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Peter Zijlstra , x86 Mailing List , Linux Kernel Mailing List Subject: Re: the x86 sysret_rip test fails on the Intel FRED architecture Message-ID: References: <5d4ad3e3-034f-c7da-d141-9c001c2343af@intel.com> <18B5DB6D-AEBD-4A67-A7B3-CE64940819B7@zytor.com> <25b96960-a07e-a952-5c23-786b55054126@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 23, 2023 at 11:43:35AM -0800, H. Peter Anvin wrote: > Good spotting. %rax needs to be marked clobbered, too. Yeah, that 'syscall' variable should be using a "+a" constraint. But anyway, I found something wrong with this. I was playing with your code and I found it failed to assert that %r11 == rflags_sentinel on a non-FRED system. It happens because "popf" doesn't set the %rflags to the expected value. I tried to simplify it like this: pushq $0x200893 popf # This popf sets %rflags to 0x200a93, not to 0x200893. pushf popq %r11 # Now %r11 == 0x200a93, # but the expected value is %r11 == 0x200893. Looking into their bits: (gdb) p/t 0x200893 $1 = 1000000000100010010011 (gdb) p/t 0x200a93 $2 = 1000000000101010010011 Align them to spot differences: 0x200893 = 0b1000000000100010010011 0x200a93 = 0b1000000000101010010011 ^ Or just xor them to find the differences: (gdb) p/x 0x200893 ^ 0x200a93 $3 = 0x200 ** Checks my Intel SDM cheat sheets. ** Then, I was like "Oh, that's (1 << 9) a.k.a. IF. Of course we can't change rflags[IF] from userspace!!!". In short, we can't use 0x200893 as the rflags_sentinel value because it clears the interrupt flag. -- Ammar Faizi