Re: syscall call-from verification
On Fri, Nov 29, 2019 at 10:12:10AM +0100, Thomas de Grivel wrote: > Maybe Go is not the only problem, I see SBCL compiling syscalls too. > > Truth is libc is for C and not all programs are written in C nowadays. Where are you seeing SBCL compiling direct syscalls? In my testing, SBCL self-hosts just fine under a kernel modified to disallow syscalls from the text segment, whereas go is killed under such a kernel. Are you sure you're not seeing SBCL compile calls to the libc syscall wrappers?
Fix libcompiler_rt __clear_cache() on armv7
I came across some code which uses __clear_cache() from
libgcc/libcompiler_rt on 32-bit arm. Currently that just falls through
to abort(), but enabling the existing sysarch() code works for me.
diff --git a/lib/libcompiler_rt/clear_cache.c b/lib/libcompiler_rt/clear_cache.c
index 451f1c0b124..4902d761b81 100644
--- a/lib/libcompiler_rt/clear_cache.c
+++ b/lib/libcompiler_rt/clear_cache.c
@@ -33,7 +33,7 @@ uintptr_t GetCurrentProcess(void);
#include
#endif
-#if defined(__OpenBSD__) && defined(__mips__)
+#if defined(__OpenBSD__) && (defined(__mips__) || defined(__arm__))
#include
#include
#endif
@@ -102,7 +102,7 @@ void __clear_cache(void *start, void *end) {
* so there is nothing to do
*/
#elif defined(__arm__) && !defined(__APPLE__)
-#if defined(__FreeBSD__) || defined(__NetBSD__)
+#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
struct arm_sync_icache_args arg;
arg.addr = (uintptr_t)start;
Re: stack pointer checking
It unmaps for each thread when it is destroyed, but never for the
initial thread.
On Sat, Jan 13, 2018 at 03:45:52PM -0700, Theo de Raadt wrote:
> Does it not free it somewhere eventually? How is that handled.
>
>
> > lang/sbcl will need a small patch:
> >
> > $OpenBSD$
> >
> > Index: src/runtime/thread.c
> > --- src/runtime/thread.c.orig
> > +++ src/runtime/thread.c
> > @@ -636,9 +636,16 @@ create_thread_struct(lispobj initial_function) {
> > * on the alignment passed from os_validate, since that might
> > * assume the current (e.g. 4k) pagesize, while we calculate with
> > * the biggest (e.g. 64k) pagesize allowed by the ABI. */
> > +#ifdef MAP_STACK
> > +spaces = mmap(0, THREAD_STRUCT_SIZE, OS_VM_PROT_ALL,
> > + MAP_PRIVATE | MAP_ANON | MAP_STACK, -1, 0);
> > +if(spaces == MAP_FAILED)
> > +return NULL;
> > +#else
> > spaces=os_validate(0, THREAD_STRUCT_SIZE);
> > if(!spaces)
> > return NULL;
> > +#endif
> > /* Aligning up is safe as THREAD_STRUCT_SIZE has
> > * THREAD_ALIGNMENT_BYTES padding. */
> > aligned_spaces = (void *)uword_t)(char *)spaces)
> >
Re: stack pointer checking
On Thu, Jan 11, 2018 at 08:39:25PM -0700, Theo de Raadt wrote:
> Stefan (stefan@) and I have been working for a few months on this
> diff, with help from a few others.
>
> At every trap and system call, it checks if the stack-pointer is on a
> page that is marked MAP_STACK. execve() is changed to create such
> mappings for the process stack. Also, libpthread is taught the new
> MAP_STACK flag to use with mmap().
>
> There is no corresponding system call which can set MAP_FLAG on an
> existing page, you can only set the flag by mapping new memory into
> place. That is a piece of the security model.
>
> The purpose of this change is to twart stack pivots, which apparently
> have gained some popularity in JIT ROP attacks. It makes it difficult
> to place the ROP stack in regular data memory, and then perform a
> system call from it. Workarounds are cumbersome, increasing the need
> for far more gadgetry. But also the trap case -- if any memory
> experiences a demand page fault, the same check will occur and
> potentially also kill the process.
>
> We have experimented a little with performing this check during device
> interrupts, but there are some locking concerns and performance may
> then become a concern. It'll be best to gain experience from handle
> of syncronous trap cases first.
>
> chrome and other applications I use run fine!
>
> I'm asking for some feedback to discover what ports this breaks, we'd
> like to know. Those would be ports which try to (unconvenionally)
> create their stacks in malloc()'d memory or inside another
> datastructure. Most of them are probably easily fixed ...
lang/sbcl will need a small patch:
$OpenBSD$
Index: src/runtime/thread.c
--- src/runtime/thread.c.orig
+++ src/runtime/thread.c
@@ -636,9 +636,16 @@ create_thread_struct(lispobj initial_function) {
* on the alignment passed from os_validate, since that might
* assume the current (e.g. 4k) pagesize, while we calculate with
* the biggest (e.g. 64k) pagesize allowed by the ABI. */
+#ifdef MAP_STACK
+spaces = mmap(0, THREAD_STRUCT_SIZE, OS_VM_PROT_ALL,
+ MAP_PRIVATE | MAP_ANON | MAP_STACK, -1, 0);
+if(spaces == MAP_FAILED)
+return NULL;
+#else
spaces=os_validate(0, THREAD_STRUCT_SIZE);
if(!spaces)
return NULL;
+#endif
/* Aligning up is safe as THREAD_STRUCT_SIZE has
* THREAD_ALIGNMENT_BYTES padding. */
aligned_spaces = (void *)uword_t)(char *)spaces)
Re: Allow raw sockets to process icmp echo requests.
On Fri, Jul 15, 2011 at 08:13:59PM -0300, Christiano F. Haesbaert wrote: > Hi, this diff adds a sysctl to disable kernel icmp echo processing and pass it > to userland via raw sockets. I'm terrible with names but I chose userecho, so > net.inet.icmp.userecho. > > I did some basic tests and it seems to work ok. > > I kinda need this to tunnel ip over icmp echo. > Can't you just write a PF rule to pass the incoming ICMP packets to a divert socket for a userland program to handle?
Re: correct mxcsr+mxcsr_mask handling (revised)
On Mon, Dec 27, 2010 at 12:07:55PM -0800, Philip Guenther wrote:
> Okay, check out the revised diff below. I've tested the updated amd64
> part; I would appreciate a confirmation from an i386 w/X11 user for that
> part.
Works for me, X runs and test program no longer drops us into ddb:
OpenBSD 4.8-current (GENERIC) #43: Mon Dec 27 13:08:01 PST 2010
jo...@flint.joshe.fake:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) M processor 1.40GHz ("GenuineIntel" 686-class) 1.40
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF
It couldn't hurt to also test this on a machine where the fxsave
instruction writes an empty mask. This should be any machine with SSE
is in the cpu flags list and without SSE2.
ok joshe@
> Index: amd64/amd64/fpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/fpu.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 fpu.c
> --- amd64/amd64/fpu.c 29 Sep 2010 15:11:31 - 1.21
> +++ amd64/amd64/fpu.c 27 Dec 2010 20:05:56 -
> @@ -95,6 +95,8 @@
> void fpudna(struct cpu_info *);
> static int x86fpflags_to_siginfo(u_int32_t);
>
> +uint32_t fpu_mxcsr_mask;
> +
> /*
> * Init the FPU.
> */
> @@ -103,6 +105,16 @@ fpuinit(struct cpu_info *ci)
> {
> lcr0(rcr0() & ~(CR0_EM|CR0_TS));
> fninit();
> + if (fpu_mxcsr_mask == 0) {
> + struct fxsave64 fx __attribute__((aligned(16)));
> +
> + bzero(&fx, sizeof(fx));
> + fxsave(&fx);
> + if (fx.fx_mxcsr_mask)
> + fpu_mxcsr_mask = fx.fx_mxcsr_mask;
> + else
> + fpu_mxcsr_mask = __INITIAL_MXCSR_MASK__;
> + }
> lcr0(rcr0() | (CR0_TS));
> }
>
> Index: amd64/amd64/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/machdep.c,v
> retrieving revision 1.129
> diff -u -p -r1.129 machdep.c
> --- amd64/amd64/machdep.c 22 Nov 2010 21:07:16 - 1.129
> +++ amd64/amd64/machdep.c 27 Dec 2010 20:05:56 -
> @@ -658,9 +658,11 @@ sys_sigreturn(struct proc *p, void *v, r
> fpusave_proc(p, 0);
>
> if (ksc.sc_fpstate) {
> - if ((error = copyin(ksc.sc_fpstate,
> - &p->p_addr->u_pcb.pcb_savefpu.fp_fxsave, sizeof (struct
> fxsave64
> + struct fxsave64 *fx = &p->p_addr->u_pcb.pcb_savefpu.fp_fxsave;
> +
> + if ((error = copyin(ksc.sc_fpstate, fx, sizeof(*fx
> return (error);
> + fx->fx_mxcsr &= fpu_mxcsr_mask;
> p->p_md.md_flags |= MDP_USEDFPU;
> }
>
> @@ -1506,6 +1508,7 @@ init_x86_64(paddr_t first_avail)
> cpu_init_idt();
>
> intr_default_setup();
> + fpuinit(&cpu_info_primary);
>
> softintr_init();
> splraise(IPL_IPI);
> Index: amd64/amd64/process_machdep.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/process_machdep.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 process_machdep.c
> --- amd64/amd64/process_machdep.c 29 Sep 2010 15:11:31 - 1.9
> +++ amd64/amd64/process_machdep.c 27 Dec 2010 20:05:56 -
> @@ -137,7 +137,7 @@ process_read_fpregs(struct proc *p, stru
> frame->fx_fsw = 0x;
> frame->fx_ftw = 0xff;
> frame->fx_mxcsr = __INITIAL_MXCSR__;
> - frame->fx_mxcsr_mask = __INITIAL_MXCSR_MASK__;
> + frame->fx_mxcsr_mask = fpu_mxcsr_mask;
> p->p_md.md_flags |= MDP_USEDFPU;
> }
>
> @@ -198,6 +198,7 @@ process_write_fpregs(struct proc *p, str
> }
>
> memcpy(frame, ®s->fxstate, sizeof(*regs));
> + frame->fx_mxcsr &= fpu_mxcsr_mask;
> return (0);
> }
>
> Index: amd64/include/fpu.h
> ===
> RCS file: /cvs/src/sys/arch/amd64/include/fpu.h,v
> retrieving revision 1.7
> diff -u -p -r1.7 fpu.h
> --- amd64/include/fpu.h 20 Nov 2010 20:11:17 - 1.7
> +++ amd64/include/fpu.h 27 Dec 2010 20:05:56 -
> @@ -49,6 +49,8 @@ struct savefpu {
> struct trapframe;
> struct cpu_info;
>
> +extern uint32_t fpu_mxcsr_mask;
> +
> void fpuinit(struct cpu_info *);
> void fpudrop(void);
> void fpudiscard(struct proc *);
> Index: i386/i386/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.485
> diff -u -p -r1.485 machdep.c
> --- i386/i386/machdep.c 2 Oct 2010 23:31:34 - 1.485
> +++ i386/i386/machdep.c 27 Dec 2010 20:05:57 -
> @@ -2362,9 +2362,12 @@ sys_sigreturn(struct proc *p, void *v, r
> npxsave_proc(p, 0);
>
> if (context.sc_fpstate) {
> - if ((error = copyin(context.sc_fpstate,
> -
Re: utmpx for OpenBSD
On Tue, Jul 13, 2010 at 10:28:47PM +, Christian Weisgerber wrote: > Theo de Raadt wrote: > > > > - posix_openpt(), grantpt(), unlockpt() and ptsname(), and > > > - utmpx. > > > > > > This causes a real burden on people trying to write network login > > > services, terminal emulators, terminal multiplexers, etc. > > > > You are killing us with hyperbole. > > Well, I have been waiting for some time for porters to run against > a wall because of the lack of posix_openpt() etc, but so far it > hasn't happened yet. > > I certainly don't think it's a burden on third party developers--they'll > just shrug and ignore us. > > (app/luit in xenocara was broken until I fixed it to use openpty(); > the upstream of net/rtorrent essentially told me to shove it if we > didn't support the POSIX interface and ignored my patch, but that > was for a configure test and isn't even really used in the program.) When I initially ported SBCL, it took me all of half an hour to realize the standard POSIX interfaces weren't available, read the docs of the native interfaces, then modify the code to use openpty() on OpenBSD. It's not like any real-world program doesn't already have it's share of the language's equivalent of #ifdefs.
Re: /boot broken on latest snapshot ?
On 2010-07-09 14:01:41, Christopher Zimmermann wrote:
> On 07/09/10 14:19, Christopher Zimmermann wrote:
> > Hi,
> >
> > I just upgraded to the very latest snapshot(9.7. 1:50) on i386. Now my
> > system does not boot anymore. The only thing I get is:
> >
> > Using drive 0, partition 3.
> > Loading...
> > [cursor sits here]
> >
> > As I understand the boot process, the PBR boot loader has found /boot,
> > verified the magic number and handed control over to the code loaded
> > from /boot.
> >
> > I already booted the latest bsd.rd via pxeboot and did the following:
> >
> > # fdisk -u wd0
> > # mount /dev/wd0a /mnt
> > # /mnt/mdec/installboot -v /mnt/boot /usr/mdev/biosboot wd0
> >
> > this did not change anything. Same symptoms as before. Next thing I'll
> > try is to boot normal bsd kernel via pxeboot and do installboot again
> > from there.
>
> ok. Booting via pxeboot still works with
>
> boot hd0a:/bsd
>
> running installboot from there didn't help either.
>
> Next thing I tried was a complete reinstall of the latest snapshot on an
> alternate root via pxeboot.
> Install worked find, booting from harddist still doesn't work. pxeboot
> works fine.
>
> There is something broken in latest snapshots /boot for sure. The system
> is a ThinkPad T43p. I don't have a dmesg to provide at hand, sorry.
>
I see this on my laptop too. Building /boot built from -current
source and source from Jul 1 (before the last change to boot) yields
the same result. Perhaps a gcc4 issue?
OpenBSD 4.7-current (GENERIC) #14: Fri Jul 9 13:08:16 PDT 2010
jo...@flint.joshe.fake:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) M processor 1.40GHz ("GenuineIntel" 686-class) 1.40
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF
real mem = 804540416 (767MB)
avail mem = 781402112 (745MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/29/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS
rev. 2.3 @ 0xf8cb0 (61 entries)
bios0: vendor Dell Computer Corporation version "A17" date 06/29/2005
bios0: Dell Computer Corporation Inspiron 600m
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP
acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S1) USB1(S1) USB2(S1)
USB3(S1) MODM(S3) PCIE(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
\\_SB_.PCI0 post-crs: 0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (PCIE)
acpicpu0 at acpi0acpicpu0: struck PSS entry, core frequency equals last
acpicpu0: struck PSS entry, core frequency equals last
acpicpu0: struck PSS entry, core frequency equals last
acpicpu0: struck PSS entry, core frequency equals last
acpicpu0: struck PSS entry, core frequency equals last
acpicpu0: struck PSS entry, core frequency equals last
acpicpu0: struck PSS entry, core frequency equals last
acpicpu0: struck PSS entry, core frequency equals last
acpicpu0: invalid _PSS length
: C3, C3, C2, C1
acpitz0 at acpi0: critical temperature 102 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "DELL Y13385" serial 4344 type LION oem "Sanyo"
acpibat1 at acpi0: BAT1 not present
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_
acpivout0 at acpivideo0: TV__
acpivout1 at acpivideo0: CRT_
acpivout2 at acpivideo0: CRT2
acpivout3 at acpivideo0: LCD_
acpivout4 at acpivideo0: DVI_
bios0: ROM list: 0xc/0x1
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82855PM Host" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xe000, size 0x800
ppb0 at pci0 dev 1 function 0 "Intel 82855PM AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility M9" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: irq 11
drm0 at radeondrm0
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 11
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 11
ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x01: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x81
pci2 at ppb1 bus 2
bce0 at pci2 dev 0 function 0 "Broadcom BCM4401B1" rev 0x02: irq 11, address
00:14:22:b8:c3:99
bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0
cbb0 at pci2 dev 1 function 0 "O2 Micro OZ711EC1 SmartCardBus" rev 0x20: irq
11, CardBus support disabled
cbb1 at pci2 dev 1 function 1 "O2 Micro OZ711EC1 SmartCardBus" rev 0x20: irq
11, CardBus support disabled
ath0 at pci2 dev 3 function 0 "Atheros AR5212 (IBM MiniPCI)" rev 0x01: irq 11
ath0: AR5213A 5.9 phy 4.3 rf5112a 3.6, WOR01W, address 00:0e:9b:89:d7:ca
cardslot0 at cbb0 slot 0 flags 0
pcmci
