On March 6, 2024 10:28:25 AM PST, Xin Li wrote:
>On 3/4/2024 12:33 AM, Xin Li (Intel) wrote:
>> As TOP_OF_KERNEL_STACK_PADDING is defined as 0 on x86_64, no one noticed
>> it's missing in the calculation of the .sp field in INIT_THREAD until it
>> is defined to 16 with CONFIG_X86_FRED=y.
>>
>>
So we have recently discovered an overlooked interaction with VT-x.
Immediately before VMENTER and after VMEXIT, CR2 is live with the
*guest* CR2. Regardless of if the guest uses FRED or not, this is guest
state and SHOULD NOT be corrupted. Furthermore, host state MUST NOT leak
into the guest.
On December 6, 2023 11:19:26 AM PST, "Li, Xin3" wrote:
>> >>> +case X86_TRAP_OF:
>> >>> +exc_overflow(regs);
>> >>> +return;
>> >>> +
>> >>> +/* INT3 */
>> >>> +case X86_TRAP_BP:
>> >>> +exc_int3(regs);
>> >>> +
On November 28, 2023 10:39:01 AM PST, "Li, Xin3" wrote:
>> > FRED and IDT can share most of the definitions and declarations so
>> > that in the majority of cases the actual handler implementation is the
>> > same.
>> >
>> > The differences are the exceptions where FRED stores exception related
gt;
>> Specially introduce a new structure fred_ss to denote the FRED flags
>> above SS selector, which avoids FRED_SSX_ macros and makes the code
>> simpler and easier to read.
>>
>> Signed-off-by: H. Peter Anvin (Intel)
>
>You and hpa need to go throug
On November 13, 2023 1:29:47 PM EST, Borislav Petkov wrote:
>On Mon, Nov 13, 2023 at 12:36:04PM -0500, H. Peter Anvin wrote:
>> A resource cannot be consumed after the value has been written; this
>> is the only necessary level of serialization, equivalent to, say, RAX.
&g
On November 13, 2023 4:37:42 AM EST, Borislav Petkov wrote:
>On Mon, Oct 02, 2023 at 11:24:40PM -0700, Xin Li wrote:
>> From: "H. Peter Anvin (Intel)"
>>
>> MSR_IA32_FRED_RSP0 is used during ring 3 event delivery, and needs to
>> be updated to point to t
On 10/12/23 14:17, Uros Bizjak wrote:
Are you PIC-adjusting the percpu variables as well?
After this patch (and after fixing percpu_stable_op to use "a" operand
modifier on GCC), the only *one* remaining absolute reference to
percpu variable remain in xen-head.S, where:
movq
On 10/12/23 13:59, Uros Bizjak wrote:
On Thu, Oct 12, 2023 at 10:53 PM Dave Hansen wrote:
On 10/12/23 13:12, Uros Bizjak wrote:
The last patch introduces (%rip) suffix and uses it for x86_64 target,
resulting in a small code size decrease: text data bss dec hex filename
25510677 4386685
On 10/12/23 14:02, H. Peter Anvin wrote:>
%fs??
>
Nevermind, I forgot that we changed from %gs to %fs on i386 at some
point in the now-distant past.
-hpa
gister, so
>use explicit segment registers to access percpu variable instead.
>
>Also add a missing function comment to this_cpu_cmpxchg8b_emu.
>
>No functional changes intended.
>
>Cc: Thomas Gleixner
>Cc: Ingo Molnar
>Cc: Borislav Petkov
>Cc: Dave Hansen
>Cc: &q
cept, and should be defined in a common x86
>> header.
>>
>> Add event type macros to , and use it in .
>>
>> Suggested-by: H. Peter Anvin (Intel)
>> Tested-by: Shan Kang
>> Signed-off-by: Xin Li
>> ---
>>
>> Changes since v10:
>
On September 25, 2023 10:56:44 AM PDT, "Li, Xin3" wrote:
>> >diff --git a/arch/x86/kernel/cpu/common.c
>> >b/arch/x86/kernel/cpu/common.c index 20bbedbf6dcb..2ee4e7b597a3 100644
>> >--- a/arch/x86/kernel/cpu/common.c
>> >+++ b/arch/x86/kernel/cpu/common.c
>> >@@ -2071,10 +2071,8 @@ static void
On September 23, 2023 2:42:10 AM PDT, Xin Li wrote:
>Because FRED uses the ring 3 FRED entrypoint for SYSCALL and SYSENTER and
>ERETU is the only legit instruction to return to ring 3, there is NO need
>to setup SYSCALL and SYSENTER MSRs for FRED, except the IA32_STAR MSR.
>
>Split IDT syscall
On September 20, 2023 1:18:14 AM PDT, Thomas Gleixner
wrote:
>On Wed, Sep 20 2023 at 04:33, Li, Xin3 wrote:
>>> > +static inline void fred_syscall_init(void) {
>>> > + /*
>>> > + * Per FRED spec 5.0, FRED uses the ring 3 FRED entrypoint for SYSCALL
>>> > + * and SYSENTER, and ERETU is the only
On 9/14/23 18:46, andrew.coop...@citrix.com wrote:
On 15/09/2023 1:38 am, H. Peter Anvin wrote:
On 9/14/23 17:33, andrew.coop...@citrix.com wrote:
It's an assumption about what "definitely won't" be paravirt in the
future.
XenPV stack handling is almost-FRED-like and has been for
15/09/2023 1:07
am, H. Peter Anvin wrote:
>> Is *that* your concern?! Just put a NOP before WRMSR – you need
padding NOP bytes anyway – and the extable entry is no longer at the
same address. Problem solved.
>>
>> Either that, or use a direct call, which can't #GP in th
On 9/14/23 17:33, andrew.coop...@citrix.com wrote:
It's an assumption about what "definitely won't" be paravirt in the future.
XenPV stack handling is almost-FRED-like and has been for the better
part of two decades.
You frequently complain that there's too much black magic holding XenPV
On September 14, 2023 4:00:39 PM PDT, Thomas Gleixner
wrote:
>Andrew!
>
>On Thu, Sep 14 2023 at 15:05, andrew wrote:
>> On 14/09/2023 5:47 am, Xin Li wrote:
>>> +static __always_inline void wrmsrns(u32 msr, u64 val)
>>> +{
>>> + __wrmsrns(msr, val, val >> 32);
>>> +}
>>
>> This API works in
On 7/30/23 23:41, Xin Li wrote:
+static DEFINE_FRED_HANDLER(fred_other_default)
+{
+ regs->vector = X86_TRAP_UD;
+ fred_emulate_fault(regs);
+}
+
+static DEFINE_FRED_HANDLER(fred_syscall)
+{
+ regs->orig_ax = regs->ax;
+ regs->ax = -ENOSYS;
+ do_syscall_64(regs,
On 7/30/23 23:41, Xin Li wrote:
+
+static DEFINE_FRED_HANDLER(fred_sw_interrupt_user)
+{
+ /*
+* In compat mode INT $0x80 (32bit system call) is
+* performance-critical. Handle it first.
+*/
+ if (IS_ENABLED(CONFIG_IA32_EMULATION) &&
+
On January 18, 2023 1:45:44 AM PST, Peter Zijlstra wrote:
>On Mon, Jan 16, 2023 at 03:25:34PM +0100, Peter Zijlstra wrote:
>> The boot trampolines from trampoline_64.S have code flow like:
>>
>> 16bit BIOS SEV-ES 64bit EFI
>>
>> trampoline_start()
On October 3, 2022 2:28:40 PM PDT, Nadav Amit wrote:
>On Oct 3, 2022, at 2:06 PM, H. Peter Anvin wrote:
>
>> ⚠ External Email
>>
>> On October 3, 2022 10:34:15 AM PDT, Nadav Amit wrote:
>>> On Oct 3, 2022, at 8:03 AM, Vitaly Kuznetsov wrote:
>>>
&g
On October 3, 2022 10:34:15 AM PDT, Nadav Amit wrote:
>On Oct 3, 2022, at 8:03 AM, Vitaly Kuznetsov wrote:
>
>> Not my but rather PCI maintainer's call but IMHO dropping 'const' is
>> better, introducing a new global var is our 'last resort' and should be
>> avoided whenever possible.
On October 3, 2022 8:03:41 AM PDT, Vitaly Kuznetsov wrote:
>Ajay Kaher writes:
>
>>> On 13/09/22, 7:05 PM, "Vitaly Kuznetsov" wrote:
Thanks Vitaly for your response.
1. we have multiple objects of struct pci_raw_ops, 2. adding 'priority'
field to struct pci_raw_ops
On April 14, 2022 12:19:29 PM PDT, Oleksandr Tyshchenko
wrote:
>From: Juergen Gross
>
>In order to support virtio in Xen guests add a config option enabling
>the user to specify whether in all Xen guests virtio should be able to
>access memory via Xen grant mappings only on the host side.
>
On November 2, 2021 10:49:44 AM GMT+01:00, Borislav Petkov
wrote:
>On Tue, Nov 02, 2021 at 05:19:46PM +0800, Lai Jiangshan wrote:
>> It will add a 5-byte NOP at the beginning of the native
>> swapgs_restore_regs_and_return_to_usermode.
>
>So?
>
It would be interesting to have an "override
nded regardless of the
> setup_header limitations. Additionally, the patch series introduces some
> convenience features like the setup_indirect struct and the
> kernel_info.setup_type_max field.
>
> Daniel
>
Looks great! Ship it!
Reviewed-by: H. P
5 without SETUP_INDIRECT
support, should patch 3/3 end up getting reverted.
(It is possible to detect, of course, but I feel pretty sure in saying
that bootloaders won't get it right.)
Other than that:
Reviewed-by: H. Peter Anvin (Intel)
-hpa
__
ioremap.c | 11 ++
>> 13 files changed, 292 insertions(+), 16 deletions(-)
>>
>> Daniel Kiper (3):
>> x86/boot: Introduce the kernel_info
>> x86/boot: Introduce the kernel_info.setup_type_max
>> x86/boot: Introduce the setup_indi
On 11/10/18 1:03 AM, Juergen Gross wrote:
>
> How would that help? The garabge data written could have the correct
> terminal sentinel value by chance.
>
> That's why I re-used an existing field in setup_header (the version) to
> let grub tell the kernel which part of setup_header was written by
On 11/9/18 11:02 PM, Juergen Gross wrote:
>>
>> Yes. We know that and it is resolved by:
>>
>> a) the length field in setup_header;
>> b) the "sentinel" field which catches legacy non-compliant bootloaders.
>
> Doesn't help for boot loaders reading struct setup_header from the
> kernel image and
>
> Unfortunately there are many major distros shipping boot loaders which
> write crap data past the end of setup_header.
>
Yes. We know that and it is resolved by:
a) the length field in setup_header;
b) the "sentinel" field which catches legacy non-compliant bootloaders.
>>
>> This field
One more aspect on this patchset: when CONFIG_ACPI_TABLE_UPGRADE was
inroduced, it was seen as a security problem and disabled by default
(unlike for device tree, where feeding entries from the boot loader is
standard operating procedure.)
Thus functionally makes that possible to bypass that
I just noticed this patch -- I missed it because the cover message
seemed far more harmless so I didn't notice this change.
THIS PATCH IS FATALLY WRONG AND NEEDS TO BE IMMEDIATELY REVERTED BEFORE
ANYONE STARTS RELYING ON IT; IT HAS THE POTENTIAL OF BREAKING THE
BOOTLOADER PROTOCOL FOR ALL FUTURE.
35 matches
Mail list logo
