On Fri, May 05, 2017 at 07:04:55PM +, Callum R. Davies wrote:
> Hi tech@, was looking through the tree for the providence of the
> amusing "No really..." message in the installer and saw that the list
> of invalid users needed updating. Names are in the order found in
> passwd, with the except
On 2017-05-05, "Peter J. Philipp" wrote:
> This is my second official contribution to what I call ELFSEC, it places a
> signature in binaries, in the ELF header to be exact.
-snip-
How does this defend against binary code introduced as a shared
library by way of LD_LIBRARY_PATH or LD_PRELOAD?
Just got this panic on armv7; got a very similar panic on hppa
yesterday that I didn't have time to look into any further. This is
completely reproducable.
setting tty flags
pf enabled
kern.allowkmem: 0 -> 1
starting network
panic: pool_do_get: mbufpl free list modified: page 0xc56a4000; item add
Hi tech@, was looking through the tree for the providence of the
amusing "No really..." message in the installer and saw that the list
of invalid users needed updating. Names are in the order found in
passwd, with the exception of ftp.
Index: distrib/miniroot/install.sub
=
Due to a poorly chosen initial state, we might jump immediately
into a CONTROL state bypassing the DROPPING one when the initial
state is DROPPING. The fix is easy: the initial state must be
something neutral, so that we would transition INITIAL->DROPPING
right off the bat in the beggining of the
On Fri, 5 May 2017 17:56:11 +0200
> If CMAC's can be truncated then this entire implementation can be
> rewritten to not truncate for 64 bit machines and truncate for 32 bit
> machines.
There is also POLY1305-AES which is a little stronger. The more you
limit failed MAC requests the more you can
On Thu, May 04, 2017 at 08:57:00PM -0700, Pratik Vyas wrote:
> Hello tech@,
>
> This patch adds functions to read and write state of devices in vmd. The
> atomicio parts are copied from usr.bin/ssh.
>
> Context: This is required for implementing vmctl send and vmctl receive.
> vmctl send / receiv
On Fri, May 05, 2017 at 05:25:57PM +0100, Kevin Chadwick wrote:
> > There was concern about my use of MD5 HMAC's so I
> > took them out. The ELF header of 32 bit systems is too small to fit
> > SHA256 checksums, so I'm leaving it out.
>
> Have you considered CMAC which can be truncated if need b
Hi,
Checking for IPv6 mapped IPv4 addreses is the task of ip6_input().
Doing it again in the protocol input functions gains nothing.
ok to remove the double check?
bluhm
Index: netinet/tcp_input.c
===
RCS file: /data/mirror/openbsd
On Fri, 5 May 2017 14:16:37 +0200
> There was concern about my use of MD5 HMAC's so I
> took them out. The ELF header of 32 bit systems is too small to fit
> SHA256 checksums, so I'm leaving it out.
Have you considered CMAC which can be truncated if need be and also
could take advantage of AES
> Date: Fri, 5 May 2017 16:52:17 +0200
> From: Patrick Wildt
>
> On Fri, May 05, 2017 at 02:26:51PM +0200, Mark Kettenis wrote:
> > I'm working on support for the SDHC controller on the Rockchip RK3399
> > such that I can use the onboard eMMC on the Firefly-RK3399. This
> > controller is based o
On Fri, May 05, 2017 at 02:26:51PM +0200, Mark Kettenis wrote:
> I'm working on support for the SDHC controller on the Rockchip RK3399
> such that I can use the onboard eMMC on the Firefly-RK3399. This
> controller is based on the Arasan eMMC 5.1 "IP", which has a standard
> SDHC 3.0 interface. H
On Fri, May 05, 2017 at 03:19:07PM +0200, Mark Kettenis wrote:
> To support sdhc(4) on the Firefly-RK3399, I actually need a working
> bus_dmamap_sync(9) implementation that does proper cache flushes. So
> far we've gotten away with not having one, because the USB stack tends
> to set the BUS_DMA_
On Fri, May 05, 2017 at 03:19:07PM +0200, Mark Kettenis wrote:
> To support sdhc(4) on the Firefly-RK3399, I actually need a working
> bus_dmamap_sync(9) implementation that does proper cache flushes. So
> far we've gotten away with not having one, because the USB stack tends
> to set the BUS_DMA_
> 5 maj 2017 kl. 15:55 skrev Maxim Bourmistrov :
>
>
>> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma :
>>
>> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
>>>
>>> Hey,
>>> on OpenBSD 6.0-stable I have following configuration for relayd:
>>>
>>> snip———
>>> interval
The 7000 generation of iwm hawrdware requires that the driver sets a
bit in the CSR_GP_CNTRL register before accessing most other registers
or sending commands to the firmware. The device will keep paying attention
while this bit is set. In the driver, the act of setting this bit is
referred to as
> 5 maj 2017 kl. 14:41 skrev Hiltjo Posthuma :
>
> On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
>>
>> Hey,
>> on OpenBSD 6.0-stable I have following configuration for relayd:
>>
>> snip———
>> interval 10
>> timeout 1200
>> prefork 15
>> log all
>> —
This fixes issues with iwm(4) firmware's retry rate table.
For a HT node ni_txrate is always zero and we should be using
ni_txmcs instead. Simplify the if-else logic to make sure of that.
The mimo delimiter in the link quality command was never set.
I don't know how important this is. But Linux s
To support sdhc(4) on the Firefly-RK3399, I actually need a working
bus_dmamap_sync(9) implementation that does proper cache flushes. So
far we've gotten away with not having one, because the USB stack tends
to set the BUS_DMA_COHERENT flag which maps memory into uncached
address space such that t
On Fri, May 05, 2017 at 12:30:56PM +0200, Maxim Bourmistrov wrote:
>
> Hey,
> on OpenBSD 6.0-stable I have following configuration for relayd:
>
> snip———
> interval 10
> timeout 1200
> prefork 15
> log all
> ——
>
> Respective login.conf to spawn more relayd procs:
>
>
I'm working on support for the SDHC controller on the Rockchip RK3399
such that I can use the onboard eMMC on the Firefly-RK3399. This
controller is based on the Arasan eMMC 5.1 "IP", which has a standard
SDHC 3.0 interface. However there are some minor quirks.
Setting the signalling voltage to
This is my second official contribution to what I call ELFSEC, it places a
signature in binaries, in the ELF header to be exact. This set of patches
are against 6.1 sources not -current. While I think it's somewhat premature
to send this in, some people in #openbsd on efnet were very interested
> Date: Fri, 5 May 2017 21:30:13 +1000
> From: Jonathan Matthew
>
> I found one of these on my desk. I tried ports 1 and 4 and then ran out
> of things to plug in, but those two work fine. Are the entries in
> pucdata.c in some kind of order?
Not really.
I don't think you should introduce an
I found one of these on my desk. I tried ports 1 and 4 and then ran out
of things to plug in, but those two work fine. Are the entries in
pucdata.c in some kind of order?
Index: pucdata.c
===
RCS file: /cvs/src/sys/dev/pci/pucdata.
Hey,
on OpenBSD 6.0-stable I have following configuration for relayd:
snip———
interval 10
timeout 1200
prefork 15
log all
——
Respective login.conf to spawn more relayd procs:
relayd:\
:maxproc-max=31:\
:maxproc-cur=15:\
:openfiles=65536:\
Hello tech@,
This is a patch that extends the readregs and writeregs vmm(4) ioctl to
read and write XCR0. This is required to send and receive FPU state
correctly for vmctl send and vmctl receive. vmctl send / receive are two
new options that will support snapshotting VMs and migrating VMs from
26 matches
Mail list logo
