I was reading some openssl source code, in particular the x86 assembly
language files (which accelerate some crypto operations), and I find
many cases where data tables are intentionally inserted into text (code)
segments, and those tables include the byte value 0xC3.
By intentional, I mean
The APM_IOC_NEXTEVENT ioctl was ripped out from i386 in 2001 in
favor of a kqueue interface, but apm.4 on various arches still claim
it's supported or may be in the future which is unlikely.
https://github.com/openbsd/src/commit/1e8a3e096b6ef01dcdf4f881eac1b86b1bafe06d
Index:
Replace selwakeup() with KNOTE() in tun(4) and tap(4).
This patch makes the tun(4) and tap(4) event filters MP-safe.
This is similar to the change that just got committed to pppac(4)
and pppx(4). However, tun(4) and tap(4) can be destroyed abruptly,
so klist_invalidate() has to be kept in
Marc Espie wrote:
> Actual patches to pkg_add (if need be) welcome
>
> The switch to not using full term length was actually done at Theo's
> request.
>
> I don't remember the details, but Theo's rationale was quite
> reasonable and made lots of sense.
>
> (specifically, using the full line
"Theo de Raadt" writes:
... removed the comprehensive summary of the effort.
> The major application problems have been reasonably isolated, and after
> 3 weeks they are mostly handled, or we know where the remaining problems
> lie:
>
> - libcrypto assembly functions with incorrect data
Actual patches to pkg_add (if need be) welcome
The switch to not using full term length was actually done at Theo's
request.
I don't remember the details, but Theo's rationale was quite
reasonable and made lots of sense.
(specifically, using the full line length would be cool, but there
were
Hi,
I've been using this patch for the past 6 months and haven't noticed any
regressions. However, during this timespan I became aware of additional
POSIX compatibility issues in OpenBSD ed: `3 2p` as well as
addresses with interleaved `,` and `;` separators (e.g. `1,;`) are also
evaluated
One thing that's going to be very useful IMO
is newer function bindings.
Us perlers don't really care, matching $@
after the sub is cool.
But having off-the-mill function "declarations"
that look a lot like function declarations in
other more common languages
(e.g.
sub f($a, $b)
)
might help
The two main test programs being used for xonly assessment, as
attachments. They will eventually head towards src/regress but for
now, people can play with them.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char
We've made good progress in the xonly effort so here's a small summary.
architectures crossed over completely
arm64 - X bit without implied R in mmu
riscv64 - X bit without implied R in mmu
amd64 - using hardware 'PKU' feature
powerpc64 - using feature similar to
Unfortunately we cannot use strtonum(3) here since there may be
non-digit characters following the number. So, strtoll(3)
it is then.
- todd
Index: lib/libc/time/strptime.c
===
RCS file: /cvs/src/lib/libc/time/strptime.c,v
ASDOT started out as sort of a joke, but unfortunately gained some
popularity in the 2010s with the rise of 4-byte ASNs and some people
thinking "cute, I can write my longish number in a shorter exotic
notation".
Then, many operators came to realize that using a '.' (dot) in places
which used to
Hi,
While switchind pppx(4) and pppac(4) from selwakeup() to KNOTE(9), I
found npppd(8) doesn't create pppx interface with "pipex no" in
npppd.conf, but successfully connects the client. So packets don't flow.
However, the pppac(4) has no this problem, because corresponding pppac
interface always
13 matches
Mail list logo
