Hello,
I have attached a patch which adds the Kernel Code Coverage(KCov)
to the NetBSD kernel.
This is one of the foundational steps to get Syzkaller (Kernel Fuzzer)
fully functional on NetBSD.
The option can be enabled by uncommenting the following lines in amd64/GENERIC
makeoptions KCOV=1
opt
Le 12/12/2018 à 11:01, Siddharth Muralee a écrit :
Hello,
I have attached a patch which adds the Kernel Code Coverage(KCov)
to the NetBSD kernel.
This is one of the foundational steps to get Syzkaller (Kernel Fuzzer)
fully functional on NetBSD.
The option can be enabled by uncommenting the f
On 12.12.2018 12:50, Maxime Villard wrote:
> Le 12/12/2018 à 11:01, Siddharth Muralee a écrit :
>> Hello,
>> I have attached a patch which adds the Kernel Code Coverage(KCov)
>> to the NetBSD kernel.
>> This is one of the foundational steps to get Syzkaller (Kernel Fuzzer)
>> fully functional o
On Wed, Dec 12, 2018 at 01:19:40PM +0100, Kamil Rytarowski wrote:
> Upstream (dvyukov) suggested to evaluate whether to use pointers always
> in 64bit types (uint64_t), as this way programs will be easier to reuse
> in 32bit mode on 64-bit kernel mode.
I fail to parse that - can you give an exampl
On 12.12.2018 13:23, Martin Husemann wrote:
> On Wed, Dec 12, 2018 at 01:19:40PM +0100, Kamil Rytarowski wrote:
>> Upstream (dvyukov) suggested to evaluate whether to use pointers always
>> in 64bit types (uint64_t), as this way programs will be easier to reuse
>> in 32bit mode on 64-bit kernel mod
Le 12/12/2018 à 12:50, Maxime Villard a écrit :
Le 12/12/2018 à 11:01, Siddharth Muralee a écrit :
Hello,
I have attached a patch which adds the Kernel Code Coverage(KCov)
to the NetBSD kernel.
This is one of the foundational steps to get Syzkaller (Kernel Fuzzer)
fully functional on NetBSD.
> kcov returns kernel pointers, 32-bit program executed by 64-bit
> kernel cannot store them in 32-bit integers.
Why would you store pointers in integers at all? Surely the right
thing to do is store them as void * (for data pointers) or void (*)()
(for function pointers)...?
/~\ The ASCII
On 12.12.2018 16:02, Mouse wrote:
>> kcov returns kernel pointers, 32-bit program executed by 64-bit
>> kernel cannot store them in 32-bit integers.
>
> Why would you store pointers in integers at all? Surely the right
> thing to do is store them as void * (for data pointers) or void (*)()
> (for
Hi,
As you may know I'm working on implementing WireGuard
in the kernel. The implementation works and buildable.
Some code cleanups are still needed but I'll propose it on
the list in the near future.
Before that, I want to ask about how to import cryptography
libraries needed tor the implementa
I don't expect there to be any problems with the ISC license. It's the
preferred license for OpenBSD and we use a lot of their code (it's
everywhere in sys/dev/)
external, as I understand it, means "please upstream your changes, and
avoid unnecessary local changes".
>> Why would you store pointers in integers at all? Surely the right
>> thing to do is store them as void * (for data pointers) or
>> void (*)() (for function pointers)...?
> kcov utilizes compiler instrumentation that uses low-lever, below the
> C and C++ language (or runtime), thus here it doesn
m...@netbsd.org writes:
> I don't expect there to be any problems with the ISC license. It's the
> preferred license for OpenBSD and we use a lot of their code (it's
> everywhere in sys/dev/)
Agreed that the license is ok.
> external, as I understand it, means "please upstream your changes, and
On Thu, Dec 13, 2018 at 2:12 AM Greg Troxel wrote:
>
> m...@netbsd.org writes:
>
> > I don't expect there to be any problems with the ISC license. It's the
> > preferred license for OpenBSD and we use a lot of their code (it's
> > everywhere in sys/dev/)
>
> Agreed that the license is ok.
>
> > ex
Hi,
While researching libc++ test failures, I've discovered that NetBSD
suffers from the same issue as FreeBSD -- that is, both the userspace
tooling and the kernel have problems with (time_t)-1 timestamp,
i.e. one second before the epoch.
For example:
$ TZ=UTC touch -t 196912312359.59 test
touc
On 12.12.2018 18:04, Mouse wrote:
>>> Why would you store pointers in integers at all? Surely the right
>>> thing to do is store them as void * (for data pointers) or
>>> void (*)() (for function pointers)...?
>> kcov utilizes compiler instrumentation that uses low-lever, below the
>> C and C++ la
> On Dec 12, 2018, at 11:46 AM, Michał Górny wrote:
>
> c. Add an extra flag to va_vaflags that explicitly indicates timestamps
> are supposed to be changed; always ignore tv_sec when it's unset,
> otherwise respect tv_sec independently of value.
This is part of a bigger problem with how the V
On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote:
> Before that, I want to ask about how to import cryptography
> libraries needed tor the implementation. The libraries are
> libb2[1] and libsodium[2]: the former is for blake2s and
> the latter is for curve25519 and [x]chacha20-poly1305
On Wed, Dec 12, 2018 at 08:46:33PM +0100, Michał Górny wrote:
> While researching libc++ test failures, I've discovered that NetBSD
> suffers from the same issue as FreeBSD -- that is, both the userspace
> tooling and the kernel have problems with (time_t)-1 timestamp,
> i.e. one second before the
On 12.12.2018 22:27, Joerg Sonnenberger wrote:
> On Wed, Dec 12, 2018 at 08:46:33PM +0100, Michał Górny wrote:
>> While researching libc++ test failures, I've discovered that NetBSD
>> suffers from the same issue as FreeBSD -- that is, both the userspace
>> tooling and the kernel have problems with
> In real life it's often needed to store time_t pointing before the
> UNIX epoch.
I am inclined to doubt it - "real life" needs to store such times,
certainly, but I have yet to see a case where it imposes any particular
representation for that storage. (Without enlarging time_t, you can't
go be
On 13.12.2018 03:22, Mouse wrote:
>> In real life it's often needed to store time_t pointing before the
>> UNIX epoch.
>
> I am inclined to doubt it - "real life" needs to store such times,
> certainly, but I have yet to see a case where it imposes any particular
> representation for that storage.
On Wed, Dec 12, 2018 at 08:46:33PM +0100, Micha? G?rny wrote:
> Sadly, this does not solve the problem entirely since kernel also
> special-cases the value of '-1'. FWICS, the vattr structure used to
> update filesystem information uses the value of VNOVAL or -1 to indicate
> that the particul
On Wed, Dec 12, 2018 at 10:27:04PM +0100, Joerg Sonnenberger wrote:
> On Wed, Dec 12, 2018 at 08:46:33PM +0100, Micha? G?rny wrote:
> > While researching libc++ test failures, I've discovered that NetBSD
> > suffers from the same issue as FreeBSD -- that is, both the userspace
> > tooling and t
Date:Thu, 13 Dec 2018 03:55:12 +0100
From:Kamil Rytarowski
Message-ID: <70762ce1-90e5-eb8e-acc0-6f4d9a581...@gmx.com>
| Storing negative times is a generic open topic so I defer myself from
| discussing it.
It is, and I agree, it is pointless.
| It's the curre
n...@gmx.com (Kamil Rytarowski) writes:
>I disagree, this used to be a flaw in C/POSIX interface to keep one
>specific point of time invalid. It should be fixed similarly to other OSe=
>s.
negative time_t values don't specify a point in time. The talk about
"one specific point of time invalid" is
On Wed, Dec 12, 2018 at 2:34 PM Joerg Sonnenberger wrote:
> On Wed, Dec 12, 2018 at 08:46:33PM +0100, Michał Górny wrote:
> > While researching libc++ test failures, I've discovered that NetBSD
> > suffers from the same issue as FreeBSD -- that is, both the userspace
> > tooling and the kernel ha
26 matches
Mail list logo
