On Sat, Apr 29, 2017 at 05:24:22PM -0700, Pratik Vyas wrote:
> Hello tech@,
>
> This is a patch that extends the readregs and writeregs vmm(4) ioctl to
> read and write MSRs as well.
>
> It also sets the IA32_VMX_IA32E_MODE_GUEST entry control in
> vcpu_reset_regs based on the value of EFER_LMA.
> On Mon, May 01, 2017 at 04:07:27PM -0600, Theo de Raadt wrote:
> >
> > Let me stop here and ask if the pattern is: "always explicit_bzero
> > a password field once it is used"? It might make sense, but some
> > of these are heading straight to exit immediately. Is it too much
> > to do it then
On Mon, May 01, 2017 at 04:07:27PM -0600, Theo de Raadt wrote:
>
> Let me stop here and ask if the pattern is: "always explicit_bzero
> a password field once it is used"? It might make sense, but some
> of these are heading straight to exit immediately. Is it too much
> to do it then, or is the
On Mon, May 01, 2017 at 10:18:58PM +0200, Mark Kettenis wrote:
> > Date: Mon, 1 May 2017 20:58:29 +0100
> > From: Stuart Henderson
> >
> > Userland is non-responsive, machine is pingable, tcp connections open
> > but no banner from ssh. No failed pool requests. This kernel is from
> > today's sna
> Index: sbin/init/init.c
> ===
> RCS file: /cvs/src/sbin/init/init.c,v
> retrieving revision 1.63
> diff -u -p -u -r1.63 init.c
> --- sbin/init/init.c 2 Mar 2017 10:38:09 - 1.63
> +++ sbin/init/init.c 4 Apr 2017 08:50:53 -
So the Linux developers decided to change the bindings for the sunxi
pinctrl devices. You know, it's supposed to a stable ABI...
This diff updates the sxipio(4) driver to support the new binding in
addition to the old binding. There is a subtle change in that it now
leaves the current configurat
Hi tech@,
After we are done with sensitive data (such as passwords) on readpassphrase(3)
we should dispose it with explicit_bzero(3), nevertheless some base
applications still rely either on bzero(3), memset(3), or something else
entirely.
Please find a diff below to change it to explicit_bzero(3
> Date: Mon, 1 May 2017 20:58:29 +0100
> From: Stuart Henderson
>
> Userland is non-responsive, machine is pingable, tcp connections open
> but no banner from ssh. No failed pool requests. This kernel is from
> today's snapshot but I saw the same with one from a couple of days
> ago. Is there an
On Mon, May 01, 2017 at 10:08:28PM +0200, Mark Kettenis wrote:
> > Date: Mon, 1 May 2017 12:35:32 -0700
> > From: Mike Larkin
> >
> > Yes, the list is locked down to those listed in the diff (those are the
> > only
> > ones in the permissions bitmap anyway).
> >
> > I don't think there are any
> Date: Mon, 1 May 2017 12:35:32 -0700
> From: Mike Larkin
>
> Yes, the list is locked down to those listed in the diff (those are the only
> ones in the permissions bitmap anyway).
>
> I don't think there are any bits we should not allow touching via
> this mechanism. The guest can already do
Userland is non-responsive, machine is pingable, tcp connections open
but no banner from ssh. No failed pool requests. This kernel is from
today's snapshot but I saw the same with one from a couple of days
ago. Is there anything else I can get that might be useful?
ddb> ps
On Mon, May 01, 2017 at 08:30:42PM +0200, Mark Kettenis wrote:
> > Date: Mon, 1 May 2017 11:16:07 -0700
> > From: Mike Larkin
> >
> > On Sat, Apr 29, 2017 at 05:24:22PM -0700, Pratik Vyas wrote:
> > > Hello tech@,
> > >
> > > This is a patch that extends the readregs and writeregs vmm(4) ioctl t
> Date: Mon, 1 May 2017 11:16:07 -0700
> From: Mike Larkin
>
> On Sat, Apr 29, 2017 at 05:24:22PM -0700, Pratik Vyas wrote:
> > Hello tech@,
> >
> > This is a patch that extends the readregs and writeregs vmm(4) ioctl to
> > read and write MSRs as well.
> >
> > It also sets the IA32_VMX_IA32E_M
On Sat, Apr 29, 2017 at 05:24:22PM -0700, Pratik Vyas wrote:
> Hello tech@,
>
> This is a patch that extends the readregs and writeregs vmm(4) ioctl to
> read and write MSRs as well.
>
> It also sets the IA32_VMX_IA32E_MODE_GUEST entry control in
> vcpu_reset_regs based on the value of EFER_LMA.
Mark Kettenis wrote:
> The futex(2) syscall needs to be able to atomically copy the futex in
> and out of userland. The current implementation uses copyin(9) and
> copyout(9) for that. The futex is a 32-bit integer, and currently our
> copyin(9) and copyout(9) don't guarantee an atomic 32-bit acc
Hi,
Just to see what would happen, I added a virtual NVMe controller to an
OpenBSD 6.1 VM on VMware ESXi 6.5. It seemed to work OK, but on VM shutdown
a warning appeared. I wasn't able to find out more, so the best I have is a
patch correcting a typo in the warning...
Index: src/sys/dev/ic/nvme.
The futex(2) syscall needs to be able to atomically copy the futex in
and out of userland. The current implementation uses copyin(9) and
copyout(9) for that. The futex is a 32-bit integer, and currently our
copyin(9) and copyout(9) don't guarantee an atomic 32-bit access.
Previously mpi@ and I di
looks good, ok nicm
On Mon, May 01, 2017 at 10:35:59AM +0200, Tobias Stoeckmann wrote:
> Hi,
>
> On Mon, May 01, 2017 at 09:15:45AM +0200, Anton Lindqvist wrote:
> > While freeing tag entries, make sure to free the copied strings.
>
> this patch looks good to me.
>
> Have you reported this to
On Mon, May 1, 2017 at 12:28 PM, Mark Kettenis wrote:
>> From: Dmitry Vyukov
>> Date: Mon, 1 May 2017 10:43:26 +0200
>>
>> On Mon, May 1, 2017 at 8:51 AM, Greg Steuck wrote:
>> > I naively tried to build something with -fsanitize=address using llvm-4.0
>> > port available on OpenBSD 6.1-amd64. I
> From: Dmitry Vyukov
> Date: Mon, 1 May 2017 10:43:26 +0200
>
> On Mon, May 1, 2017 at 8:51 AM, Greg Steuck wrote:
> > I naively tried to build something with -fsanitize=address using llvm-4.0
> > port available on OpenBSD 6.1-amd64. I was immediately greeted with:
> > clang-4.0: error: unsup
On Mon, May 1, 2017 at 8:51 AM, Greg Steuck wrote:
> I naively tried to build something with -fsanitize=address using llvm-4.0
> port available on OpenBSD 6.1-amd64. I was immediately greeted with:
> clang-4.0: error: unsupported option '-fsanitize=address' for target
> 'amd64-unknown-openbsd6
Hi,
On Mon, May 01, 2017 at 10:35:59AM +0200, Tobias Stoeckmann wrote:
> Hi,
>
> On Mon, May 01, 2017 at 09:15:45AM +0200, Anton Lindqvist wrote:
> > While freeing tag entries, make sure to free the copied strings.
>
> this patch looks good to me.
>
> Have you reported this to the upstream less
Hi,
On Mon, May 01, 2017 at 09:15:45AM +0200, Anton Lindqvist wrote:
> While freeing tag entries, make sure to free the copied strings.
this patch looks good to me.
Have you reported this to the upstream less maintainers, as well?
The original less and the forked one from Garrett D'Amore, which
Hi,
While freeing tag entries, make sure to free the copied strings.
Index: tags.c
===
RCS file: /cvs/src/usr.bin/less/tags.c,v
retrieving revision 1.18
diff -u -p -r1.18 tags.c
--- tags.c 17 Sep 2016 15:06:41 - 1.18
+++
24 matches
Mail list logo
