Re: arm64 BTI support for mpg123
Mark Kettenis wrote: > I'm not sure to what extent this makes IBT less effective. Can the > retpolines be used as gadgets to bypass IBT? Should we stop enabling > retpolines by default? > > What *is* obvious is that retpolines are incompatible wuth shadow > stacks. Is there an alternative that doesn't replace the indirect > branch with a return instruction? It is clear however that both AMD and Intel have seperate (yet compatible) strategies to encourage you to buy newer chips.
Re: Make USB WiFi drivers more robust
Martin Pieuchot wrote: > > 1. The driver's ioctl function. > > > > 2. The driver's USB transfer completion callbacks. > > Those are called by usb_transfer_complete(). This correspond to > xhci_xfer_done() and xhci_event_port_change(). Does those functions > need to be called during suspend? xhci_xfer_done() is called among other places when hardware completes a transfer, which could happen during suspend unless endpoints were stopped/transfers were aborted before suspend is allowed to proceed. The USB stack (I guess xhci.c) would have to delay suspend until active transfers complete or are aborted while failing new transfers. I don't know if that's desirable. A variant could be for suspend to cancel any active transfers, e.g. using xhci_abort_xfer(). I see that xhci.c doesn't handle DVACT_SUSPEND like other ?hci.c. It only handles DVACT_POWERDOWN. Could this be the underlying reason? xhci_event_port_change() might be called /because of/ suspend, if devices are shut down and the HC can report port change events while the kernel is suspending, which xHCI spec says does not happen if the HC is halted, which seems like a good idea while suspending - but again I don't see xhci.c halting the HC nor doing anything else for suspend. @kettenis Since ehci_activate() handles DVACT_SUSPEND is it possible to use only the EHCI driver on your machine for comparison? //Peter
OpenBSD Errata: July 25, 2023 (hv amd cpu)
Errata patches for guests running on hypervisors on AMD cpus have been released for OpenBSD 7.2 and 7.3. Binary updates for the amd64 and i386 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata72.html https://www.openbsd.org/errata73.html
Re: arm64 BTI support for mpg123
> From: "Theo de Raadt"
> Date: Tue, 25 Jul 2023 08:23:14 -0600
>
> Christian Weisgerber wrote:
>
> > Mark Kettenis:
> >
> > > This port has some infrastructure to use an optimized function that
> > > uses a function pointer. Not sure why for arm64 it actually uses that
> > > infrastructure, since the only alternative is the generic C
> > > implementation. But adding a BTI instruction is the easiest fix.
> >
> > ok naddy@
> >
> > The question is whether there are any others hiding in there. How
> > did you find this in the first place? It broke on the M2?
Yes, it broke on the M2. Very few people are actually running
packages on M2, so there may be more packages that are broken.
> > Because amd64 should suffer from the same problem:
> >
> > fr->cpu_opts.the_dct36 = dct36_avx;
> > ...
> > fr->cpu_opts.the_dct36 = dct36_x86_64;
> >
> > dct36_avx and dct36_x86_64 are assembly routines that lack the
> > endbr64 landing pad. And yet, on my IBT-enabled amd64 laptop,
> > mpg123 plays just fine with both the avx and x86_64 decoders.
>
> Maybe it requires specific files to go via those code paths?
>
> Ayways, how will we know all the locations? I think we will eventually
> know based upon user reports.
>
> It feels like there is a compilers or linker option missing to proactively
> identify these problems. Please don't bring up LTO.
Well, this is probably the wrong place to bring this up, but...
...the most likely reason why this doesn't break is because we enable
repolines by default. If you look at the retpoline implementation:
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html
you'll see that it replaces an indirect branch ("jmp *%rax") with a
sequence that effectively pushes the address to the stack and returns
to that address.
I'm not sure to what extent this makes IBT less effective. Can the
retpolines be used as gadgets to bypass IBT? Should we stop enabling
retpolines by default?
What *is* obvious is that retpolines are incompatible wuth shadow
stacks. Is there an alternative that doesn't replace the indirect
branch with a return instruction?
I mentioned the retpolines at some point before but I don't think the
right people saw that, so adding tech@ and guenther@.
Re: [patch] [arm64] cpu.c patch based on amd64 idea, provides more debug for multicore kernel
Hi, pinging and refreshing this patch
What it does:
allow arm64 cpus to break from the loop of waiting to start core and
drop to DDB or OS.
Patch based on same concept in amd64 cpu.c
Any suggestions? Good to go?
ср, 19 апр. 2023 г. в 02:32, S V :
>
> Hello, tech!
>
> I'm attaching simple patch that adds two "features" to mp kernel for arm64
> arch:
> 1. It allows to enable debug flag to drop to DDB to debug mp init problems
> 2. It allows some buggy arm64 processors to break from loop and dirty
> (or not so dirty) boot to multicore instead of eternal hang in while.
>
> This based on same idea as amd64 cpu.c function - instead of waiting for
> while()
> to boot secondary core either continue to try boot next one or drop to DDB.
>
>
>
> --
> Nerfur Dragon
> -==(UDIC)==-
Index: sys/arch/arm64/arm64/cpu.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/cpu.c,v
retrieving revision 1.97
diff -u -p -r1.97 cpu.c
--- sys/arch/arm64/arm64/cpu.c 16 Jul 2023 16:13:46 - 1.97
+++ sys/arch/arm64/arm64/cpu.c 25 Jul 2023 10:24:17 -
@@ -1087,6 +1087,8 @@ cpu_start_secondary(struct cpu_info *ci,
void
cpu_boot_secondary(struct cpu_info *ci)
{
+ int i;
+
atomic_setbits_int(>ci_flags, CPUF_GO);
__asm volatile("dsb sy; sev" ::: "memory");
@@ -1096,8 +1098,17 @@ cpu_boot_secondary(struct cpu_info *ci)
*/
arm_send_ipi(ci, ARM_IPI_NOP);
- while ((ci->ci_flags & CPUF_RUNNING) == 0)
+ for (i = 1000; (!(ci->ci_flags & CPUF_RUNNING)) && i>0;i--) {
__asm volatile("wfe");
+ }
+ if (! (ci->ci_flags & CPUF_RUNNING)) {
+ printf("cpu %d failed to start\n", ci->ci_cpuid);
+#if defined(MPDEBUG) && defined(DDB)
+ printf("dropping into debugger; continue from here to resume boot\n");
+ db_enter();
+#endif
+ }
+
}
void
Add CXXOPTS in bsd.README
Hi, I have added a description of CXXOPTS in bsd.README. comments, ok? -- ASOU Masato === RCS file: /cvs/src/share/mk/bsd.README,v retrieving revision 1.85 diff -u -p -r1.85 bsd.README --- share/mk/bsd.README 22 Sep 2020 10:31:46 - 1.85 +++ share/mk/bsd.README 25 Jul 2023 06:11:18 - @@ -302,6 +302,8 @@ CLEANFILES Additional files to remove fo COPTS Additional flags to the compiler when creating C objects. +CXXOPTSAdditional flags to the compiler when creating C++ objects. + LDADD Additional linker objects. Usually used for libraries. For example, to link with the crypto and utility libraries, use:
Re: Zenbleed
I hit the same trap as Lucas with my HV (netcup.de).
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5900 (10 entries)
bios0: vendor netcup version "RS 1000 G9 Plus" date 12/17/2020
bios0: netcup KVM Server
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC 7702P 64-Core Processor, 1996.52 MHz, 17-31-00
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
cpu0: 512KB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
https://ibb.co/gZPtLZb
https://ibb.co/sgnTsPb
Based on your diff below the following diff applies on -stable and works
for me.
Index: cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.165
diff -u -p -r1.165 cpu.c
--- cpu.c 9 Mar 2023 13:17:28 - 1.165
+++ cpu.c 25 Jul 2023 06:17:59 -
@@ -1181,7 +1181,8 @@ cpu_fix_msrs(struct cpu_info *ci)
* This MSR is available on all AMD families >= 10h, except 11h
* where LFENCE is always serializing.
*/
- if (family >= 0x10 && family != 0x11) {
+ if (family >= 0x10 && family != 0x11 &&
+ (cpu_ecxfeature & CPUIDECX_HV) == 0) {
msr = rdmsr(MSR_DE_CFG);
if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) {
msr |= DE_CFG_SERIALIZE_LFENCE;
On Mon Jul 24, 2023 at 10:25:29PM -0600, Theo de Raadt wrote:
> Would like to know if this patch helps anyone with this type of
> problem.
>
> Index: sys/arch/amd64/amd64/cpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
> retrieving revision 1.172
> diff -u -p -u -r1.172 cpu.c
> --- sys/arch/amd64/amd64/cpu.c24 Jul 2023 14:53:58 - 1.172
> +++ sys/arch/amd64/amd64/cpu.c25 Jul 2023 03:28:35 -
> @@ -1216,7 +1216,8 @@ cpu_fix_msrs(struct cpu_info *ci)
> if (msr != nmsr)
> wrmsr(MSR_DE_CFG, nmsr);
> }
> - if (family == 0x17 && ci->ci_model >= 0x31) {
> + if (family == 0x17 && ci->ci_model >= 0x31 &&
> + (cpu_ecxfeature & CPUIDECX_HV) == 0) {
> nmsr = msr = rdmsr(MSR_DE_CFG);
> nmsr |= DE_CFG_SERIALIZE_9;
> if (msr != nmsr)
> Index: sys/arch/i386/i386/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.664
> diff -u -p -u -r1.664 machdep.c
> --- sys/arch/i386/i386/machdep.c 24 Jul 2023 14:54:00 - 1.664
> +++ sys/arch/i386/i386/machdep.c 25 Jul 2023 03:28:29 -
> @@ -1993,7 +1993,8 @@ identifycpu(struct cpu_info *ci)
> if (msr != nmsr)
> wrmsr(MSR_DE_CFG, nmsr);
> }
> - if (family == 0x17 && ci->ci_model >= 0x31) {
> + if (family == 0x17 && ci->ci_model >= 0x31 &&
> + (cpu_ecxfeature & CPUIDECX_HV) == 0) {
> nmsr = msr = rdmsr(MSR_DE_CFG);
> nmsr |= DE_CFG_SERIALIZE_9;
> if (msr != nmsr)
>
