On Mon, Oct 03, 2022 at 06:43:26PM -0600, Theo de Raadt wrote:
> David Gwynne wrote:
>
> > On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
> > > diskless(8) just needs tftpd(8) to deliver files, none of the possibly
> > > untrusted clients are supposed to ever write anything.
> > >
On Sun, Oct 02, 2022 at 09:09:36PM +, Klemens Nanni wrote:
> On Tue, Sep 06, 2022 at 09:06:41PM +, Klemens Nanni wrote:
> > On Sun, Sep 04, 2022 at 07:08:51PM +, Mikolaj Kucharski wrote:
> > > Hi,
> > >
> > > I have strange setup on some of my machines, when I want to encrypt disk
> >
On 2022/10/04 10:36, David Gwynne wrote:
> On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
> > diskless(8) just needs tftpd(8) to deliver files, none of the possibly
> > untrusted clients are supposed to ever write anything.
> >
> > Either way, even when run without -c, a single fil
Hi,
Today I fetched latest /src and fn key mapping in my Macbook stopped
working with
latest changes in hidkbd.c and ukbd.c
Found that the reason is that 'sc_apple_fn' inside 'ukbd_softc' is not
being assigned to
newly created 'sc_fn' inside 'hidkbd'
I attach possible one liner fix. This gets th
On Tue, 04 Oct 2022 09:24:04 -, Klemens Nanni wrote:
> > we were read-only believers a long time ago, and it seems the world has
> > caught up to our way of thinking so yes maybe it is time to make it an
> > option you must specify.
>
> I like the idea, then -c should logically imply -w.
Look
A note on why this chance is coming.
malloc.c (as it is today), does mprotects back and forth between RW and
R, to protect an internal object. This object is in bss, it is not
allocated with mmap. With the upcoming mimmutable change, the bss will
become immutable by default, at program load time
On Tue, Oct 04, 2022 at 09:24:04AM +, Klemens Nanni wrote:
> On Mon, Oct 03, 2022 at 06:43:26PM -0600, Theo de Raadt wrote:
> > David Gwynne wrote:
> >
> > > On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
> > > > diskless(8) just needs tftpd(8) to deliver files, none of the po
On Tue, Sep 27, 2022 at 09:32:15AM -0600, Todd C. Miller wrote:
> On Tue, 27 Sep 2022 11:28:59 -0400, Josiah Frentsos wrote:
>
> > From ksh(1):
> >
> > [[ expression ]]
> > Similar to the test and [ ... ] commands (described later), with
> > the following exceptions:
>
On Tue, Sep 20, 2022 at 11:19:38AM +, Klemens Nanni wrote:
> sh(1) happily accepts newlines inside double quotes just like in the
> script itself:
>
> $ sh -c "echo foo
> > echo bar"
> foo
> bar
>
> So no need to squash things into a single line as is required in make(
> Found that the reason is that 'sc_apple_fn' inside 'ukbd_softc' is not
> being assigned to
> newly created 'sc_fn' inside 'hidkbd'
Argh, sorry about that.
Does the following diff fix the problem on your machine?
Index: ukbd.c
===
On Tue, 04 Oct 2022 18:17:02 -, Klemens Nanni wrote:
> On Tue, Sep 20, 2022 at 11:19:38AM +, Klemens Nanni wrote:
> > sh(1) happily accepts newlines inside double quotes just like in the
> > script itself:
> >
> > $ sh -c "echo foo
> > > echo bar"
> > foo
> > bar
> >
> >
On Tue, 04 Oct 2022 17:58:15 -, Klemens Nanni wrote:
> On Tue, Sep 27, 2022 at 09:32:15AM -0600, Todd C. Miller wrote:
> > On Tue, 27 Sep 2022 11:28:59 -0400, Josiah Frentsos wrote:
> >
> > > From ksh(1):
> > >
> > > [[ expression ]]
> > > Similar to the test and [ ... ] comma
Hi Miod,
Yes, I confirm that your diff fixes the problem.
Thank you!
Leonardo
El mar, 4 oct 2022 a las 13:28, Miod Vallat () escribió:
> > Found that the reason is that 'sc_apple_fn' inside 'ukbd_softc' is not
> > being assigned to
> > newly created 'sc_fn' inside 'hidkbd'
>
> Argh, sorry abou
Hi Mark,
Addendum after 24h of testing. Your patch fixes the frequent touchpad
freezes I see on this model and which I reported back then in
https://marc.info/?l=openbsd-bugs&m=165328803822857&w=2
\o/ and cheers
Matthias
* Matthias Schmidt wrote:
> Hi Mark,
>
> * Mark Kettenis wrote:
> Date: Tue, 4 Oct 2022 07:56:22 +0200
> From: Matthias Schmidt
>
> Hi Mark,
>
> * Mark Kettenis wrote:
> > The diff below adds the hooks to disable and enable GPIO interrupts
> > for amdgpio(4), aplgpio(4), bytgpio(4), chvgpio(4), glkgpio(4) and
> > pchgpio(4). This is similar to what I did fo
This function's style is a bit off: it wraps the body in a subshell to
discard all stdout/err at once, but a still uses return inside it.
1. A command list (using {}) would be enough here as it groups like a
subshell but avoids spawning another shell;
2. discarding stdout/err at the end of an
* Mark Kettenis wrote:
> > Date: Tue, 4 Oct 2022 07:56:22 +0200
> > From: Matthias Schmidt
> >
> > Hi Mark,
> >
> > * Mark Kettenis wrote:
> > > The diff below adds the hooks to disable and enable GPIO interrupts
> > > for amdgpio(4), aplgpio(4), bytgpio(4), chvgpio(4), glkgpio(4) and
> > > pchg
On Wed, Sep 28, 2022 at 10:11:14AM +0200, Claudio Jeker wrote:
> There is an extra space in the output of ext communities of type OVS.
> It seems when fmt_ext_community was introduced the extra space was not
> removed from those special ext-communities.
>
> This was noticed by job@
ok
> --
> :w
kvm_openfiles() happens before unveil. It opens these files (or falls
back to defaults), stores the opened fds (but not their names) in kd,
and the file names are never used later. So these unveils seem
unnecessary.
I don't think the intention was to unveil before kvm_openfiles(), since
then the u
On Tue, Oct 04, 2022 at 09:43:40AM +, Klemens Nanni wrote:
> On Tue, Oct 04, 2022 at 09:24:04AM +, Klemens Nanni wrote:
> > On Mon, Oct 03, 2022 at 06:43:26PM -0600, Theo de Raadt wrote:
> > > David Gwynne wrote:
> > >
> > > > On Sun, Oct 02, 2022 at 06:32:04PM +, Klemens Nanni wrote:
There is no problem to fix, but every boot I read "/clearing /tmp" and
know it is a useless step since my /tmp live on volatile RAM anyway.
Other steps in rc(8) also check and print/log conditionally, so this
can do as well, saving yet another line.
There is also the unconditional
echo 'p
This is only required for the single fchmod(2) ensuring default permissions
which only happens in the -c code path; "fattr" without "cpath" makes no
sense here.
OK?
Index: tftpd.c
===
RCS file: /cvs/src/usr.sbin/tftpd/tftpd.c,v
retr
Daniel Kahn Gillmor suggested this exact change on the openssh-unix-dev
mailing list in 2008, but I couldn't find any reply. [1]
Ignoring the current umask makes it hard to fulfill the Defense
Information Systems Agency's Security Technical Implementation Guide. In
particular, it requires:
"The R
On Sun, Sep 25, 2022 at 12:59:27AM +, Klemens Nanni wrote:
> On a sparc64 T4-2 I boot OpenBSD from hardware RAID 1E using the
> built-in controller:
>
> mpii0 at pci15 dev 0 function 0 "Symbios Logic SAS2008" rev 0x03: msi
> mpii0: Solana On-Board, firmware 9.0.0.0 IR, MPI 2.0
>
If it is empty at the beginning, the operation is free.
Today it is a narrow check for mfs. Tomorrow someone will want to
add tmpfs to this. And next month, some other crazy configuration.
So I do not see the point of this diff, at all.
The find operation is free. The echo doesn't stab you in
Hello,
diff below fixes my a tiny glitch I've introduced with
commit [1] back in May. Fortunately the impact is hardly
noticeable (I think).
The current code reads as follows:
1495 pfr_add_tables(struct pfr_table *tbl, int size, int *nadd, int flags)
1496 {
1507 for (i = 0; i < size;
I think the idea was to do the unveil+pledge before kvm_openfiles, but
I ran into some other difficulty. I wonder if issues remain. It means
someone must play with dead kernels...
Theo Buehler wrote:
> kvm_openfiles() happens before unveil. It opens these files (or falls
> back to defaults), s
Hi,
The current VALUE length limit for the hostctl command for VMware is
fixed 4096 bytes. I want to pass a longer VALUE. I made a patch to
change it to variable length.
commane, ok?
Index: share/man/man4/pvbus.4
===
RCS file: /cv
Looking at these pieces:
+ sc->sc_rpc_buf = malloc(sc->sc_rpc_buflen, M_DEVBUF, M_NOWAIT);
...
+vm_rpc_buf_realloc(struct vmt_softc *sc, size_t len)
+{
+ free(sc->sc_rpc_buf, M_DEVBUF, sc->sc_rpc_buflen);
+
+ sc->sc_rpc_buflen = len / VMT_RPC_BUFLEN * VMT_RPC_BUFLEN;
+ sc->
From: "Theo de Raadt"
Date: Tue, 04 Oct 2022 21:58:13 -0600
> Looking at these pieces:
>
> + sc->sc_rpc_buf = malloc(sc->sc_rpc_buflen, M_DEVBUF, M_NOWAIT);
> ...
> +vm_rpc_buf_realloc(struct vmt_softc *sc, size_t len)
> +{
> + free(sc->sc_rpc_buf, M_DEVBUF, sc->sc_rpc_buflen);
> +
>
Masato Asou wrote:
> As you pointed out, it is not a good idea to allocate large spaces
> in kernel.
>
> Would it be better to keep the current fixed length?
>
> Prepare a variable like kern.maxpvbus and default it to
> 4096. Futhermore, how about free() after copyout() to user space?
Sorry I
31 matches
Mail list logo
