On Sat, Jan 25, 2025 at 10:07 AM Borislav Petkov wrote:
>
>
> On Thu, Jan 23, 2025 at 02:07:36PM -0500, Brian Gerst wrote:
> > Instead of having a private area for the stack canary, use
> > fixed_percpu_data for GSBASE like the native kernel.
> >
> > Signed-off
On Fri, Oct 4, 2024 at 9:15 AM Ard Biesheuvel wrote:
>
> On Sat, 28 Sept 2024 at 15:41, Brian Gerst wrote:
> >
> > On Wed, Sep 25, 2024 at 2:33 PM Uros Bizjak wrote:
> > >
> > > On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel
> > >
m/
>
> Uros.
I plan on resubmitting that series sometime after the 6.12 merge
window closes. As I recall from the last version, it was decided to
wait until after the next LTS release to raise the minimum GCC version
to 8.1 and avoid the need to be compatible with the old stack
protector layout.
Brian Gerst
On Thu, Apr 11, 2024 at 11:26 AM Jason Andryuk wrote:
>
> On 2024-04-10 17:00, Brian Gerst wrote:
> > On Wed, Apr 10, 2024 at 3:50 PM Jason Andryuk wrote:
>
> >> /* 64-bit entry point. */
> >> .code64
> >> 1:
> >> + U
lea rva(pvh_bootparams)(%ebp), %rsi
> + lea rva(startup_64)(%ebp), %rax
RIP-relative here too.
> ANNOTATE_RETPOLINE_SAFE
> jmp *%rax
>
> @@ -143,7 +167,7 @@ SYM_CODE_END(pvh_start_xen)
> .balign 8
> SYM_DATA_START_LOCAL(gdt)
> .word gdt_end - gdt_start
> - .long _pa(gdt_start)
> + .long _pa(gdt_start) /* x86-64 will overwrite if relocated. */
> .word 0
> SYM_DATA_END(gdt)
> SYM_DATA_START_LOCAL(gdt_start)
> --
> 2.44.0
>
>
Brian Gerst
orld?
>
> First, I agree with you because it makes things simple and neat.
>
> However, the latest SDM and FRED spec 5.0 both doesn't disallow it, so it
> becomes an OS implementation choice.
>
> >
> > Is there anything (other than perhaps the selftests) which would even
> > notice?
>
> I'm just conservative :)
>
> If a user app can do it with IDT, we should still allow it when FRED is
> enabled. But if all key stakeholders don't care whatever gets broken
> due to the change and agree to change it.
One case to consider is Windows software running under Wine.
Anti-tampering code has been known to do some non-standard things,
like using ICEBP or using SYSCALL directly instead of through system
DLLs. Keeping the status quo should be preferred, especially if
Microsoft does the same.
Brian Gerst
x, PER_CPU_VAR(0(%esi))
> - movl%ecx, PER_CPU_VAR(4(%esi))
> + movl%ebx, %fs:(%esi)
> + movl%ecx, %fs:4(%esi)
>
> orl $X86_EFLAGS_ZF, (%esp)
>
> @@ -72,8 +84,8 @@ SYM_FUNC_START(this_cpu_cmpxchg8b_emu)
> RET
>
> .Lnot_same2:
> - movlPER_CPU_VAR(0(%esi)), %eax
> - movlPER_CPU_VAR(4(%esi)), %edx
> + movl%fs:(%esi), %eax
> + movl%fs:4(%esi), %edx
>
> andl$(~X86_EFLAGS_ZF), (%esp)
>
> --
> 2.41.0
>
This will break on !SMP builds, where per-cpu variables are just
regular data and not accessed with a segment prefix.
Brian Gerst
initial_gs in common_cpu_up() ]
> [ Oleksandr Natalenko: reported suspend/resume issue fixed in
> x86_acpi_suspend_lowlevel ]
>
> Co-developed-by: Thomas Gleixner
> Signed-off-by: Thomas Gleixner
> Co-developed-by: Brian Gerst
> Signed-off-by: Brian Gerst
> Signed-off-by
+721,10 @@ static void impress_friends(void)
> * Allow the user to impress friends.
> */
> pr_debug("Before bogomips\n");
> - for_each_possible_cpu(cpu)
> - if (cpumask_test_cpu(cpu, cpu_callout_mask))
> + for_each_possible_cpu(cpu) {
> + if (cpumask_test_cpu(cpu, cpu_online_mask))
> bogosum += cpu_data(cpu).loops_per_jiffy;
This should be the same as for_each_online_cpu().
--
Brian Gerst
On Xen PV, the GDT must be read-only because the hypervisor
> * requires it.
> */
> - pgprot_t gdt_prot = boot_cpu_has(X86_FEATURE_XENPV) ?
> + pgprot_t gdt_prot = cpu_feature_enabled(X86_FEATURE_XENPV) ?
> PAGE_KERNEL_RO : PAGE_KERNEL;
> pgprot_t tss_prot = PAGE_KERNEL;
> #endif
This is another case that can be removed because it's for 32-bit.
--
Brian Gerst
One thing that you missed is removing VDSO_NOTE_NONEGSEG_BIT from
vdso32/note.S. With that removed there is no difference from the
64-bit version.
Otherwise this series looks good to me.
--
Brian Gerst
ther HVM or PVH, or they can use a 64 bit kernel.
>
> Remove the 32-bit Xen PV support from the kernel.
If you send a v3, it would be better to split the move of the 64-bit
code into xen-asm.S into a separate patch.
--
Brian Gerst
ER_LABEL(entry_SYSENTER_compat_after_hwframe, SYM_L_GLOBAL)
This skips over the section that truncates the syscall number to
32-bits. The comments present some doubt that it is actually
necessary, but the Xen path shouldn't differ from native. That code
should be moved after this new label.
--
Brian Gerst
he kernel was loaded between 2G and 4G. Looking closer at the code,
we just left 32-bit mode, so we must have been loaded below 4G,
therefore EDX must be zero.
--
Brian Gerst
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
+ /* Set base address in stack canary descriptor. */
> + mov $MSR_GS_BASE,%ecx
> + mov $canary, %rax
> + cdq
> + wrmsr
CDQ only sign-extends EAX to RAX. What you really want is to move the
high 32-bits to EDX (or zero EDX if we can guarantee it is loaded
belo
15 matches
Mail list logo
