Le 28/01/2014 19:44, Mindaugas Rasiukevicius a écrit :
[...]
- Last but not least, it does not have awkward API naming, such as
prop_data_create_data_nocopy() or prop_number_unsigned_integer_value().
I particularly agree on this one, hehe
Le 01/02/2014 10:51, Martin Husemann a écrit :
On Sat, Feb 01, 2014 at 08:41:15AM +, Emmanuel Dreyfus wrote:
Hi
Here is my latest attempt at netbsd32 swapctl. I had to make uvm_swap_stats()
available to emul code, but that seems to be what it was intented for,
according to comments in
Hi all,
I think there's an inconsistency with COMPAT_10 in the open() syscall:
- kern/vfs_syscalls.c - l.1631 --
#ifdef COMPAT_10/* XXX: and perhaps later */
if (path == NULL) {
pb = pathbuf_create(.);
if (pb ==
Hi,
Here is a patch to sync netbsd32 with the native getfh() syscall. In addition
to making it consistent, it also:
a) fixes the return value:
} else if (error == E2BIG) {
error = copyout(sz, SCARG_P32(uap, fh_size),
sizeof(size_t));
}
Le 25/06/2014 17:28, Christos Zoulas a écrit :
In article 53aa91a3.1070...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Hi,
Here is a patch to sync netbsd32 with the native getfh() syscall. In addition
to making it consistent, it also:
a) fixes the return value:
} else
Le 26/06/2014 04:04, Christos Zoulas a écrit :
On Jun 26, 11:30am, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: Fix netbsd32's getfh()
|
| Christos Zoulas writes:
| Well, let's not propagate the evil design! I is is one thing having:
|
|void *p = malloc(n);
|
Le 26/06/2014 20:46, Christos Zoulas a écrit :
On Jun 26, 4:30pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: Fix netbsd32's getfh()
| I guess it's ok now?
Yes, that looks fine. But why:
if (error != 0)
instead of:
if (error)
I think that most code
Hi,
I would like to improve the priorities of the binary loader. When the kernel
loads a binary, it basically loops and calls different loaders (for aout, ELF,
...). There are several ELF loaders, for native and emulated binaries. This
loop has a particular order: the 32bit compat loaders are
Le 03/07/2014 21:40, David Holland a écrit :
On Thu, Jul 03, 2014 at 03:26:09PM +0200, Maxime Villard wrote:
Being able to automatically invoke a suitable emulator for user
binaries of the wrong OS and/or architecture would be very helpful for
crossbuilding difficult packages
Le 05/07/2014 16:58, Maxime Villard a écrit :
[...]
My approach was wrong. #if(ARCH_ELFSIZE != 64) doesn't remove the exec_elf32
module, since it is still listed in distrib/sets/lists/modules/md.amd64. It
just removes exec_elf32_modcmd() from the module.
If the module is built in (GENERIC
Le 12/07/2014 00:42, Paul Goyette a écrit :
I run without _any_ EXEC_* or COMPAT_* module compiled into my kernel. ALL of
my EXEC_* and COMPAT_* modules are auto-loaded as needed from the file system.
Please don't break this! :)
Well, netbsd32 already breaks the module loader, because of a
Hi,
some days ago when reading msdosfs_vfsops.c I saw this:
if ((error = bread(devvp, 0, secsize, NOCRED, 0, bp)) != 0)
goto error_exit;
bsp = (union bootsector *)bp-b_data;
b33 = (struct byte_bpb33 *)bsp-bs33.bsBPB;
b50 = (struct byte_bpb50
Le 15/07/2014 17:57, Martin Husemann a écrit :
On Tue, Jul 15, 2014 at 03:27:08PM +0200, Maxime Villard wrote:
'secsize' is retrieved through getdisksize(), via an ioctl on the device.
force it to be 512 bytes minimum?
Martin
I thought about that. I haven't found a clear spec
I've put 512. It's the least magic limit.
-
Module Name:src
Committed By: maxv
Date: Wed Jul 16 20:09:00 UTC 2014
Modified Files:
src/sys/fs/msdosfs: msdosfs_vfsops.c
Log Message:
Limit the
Hi,
I intend to enable KMEM_REDZONE on DIAGNOSTIC. It adds a 2-byte-sized pattern at
the end of each allocated buffer when allocating, and checks this pattern when
freeing to ensure the caller hasn't written outside the requested area. It can
catch off-by-one's, and has almost no performance
Le 25/07/2014 16:51, Christos Zoulas a écrit :
In article 53d22353.9090...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Le 23/07/2014 21:51, Greg Troxel a écrit :
I realized that two things can be separated. One is whether DIAGNOSTIC
turns on features that increase the size
Le 18/04/2014 10:30, Maxime Villard a écrit :
Hi all,
I think there's an inconsistency with COMPAT_10 in the open() syscall:
- kern/vfs_syscalls.c - l.1631 --
#ifdef COMPAT_10 /* XXX: and perhaps later */
if (path == NULL) {
pb
Hi,
I've improved my code scanner, and it has found 26 potential bugs under sys/.
Instead of flooding tech-kern@/tech-net@/etc with questions and fixes, I put
here a comprehensive list:
http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Report-2
Some of them will probably need to
Le 05/08/2014 18:18, Rich Neswold a écrit :
On Mon, Jul 28, 2014 at 2:44 PM, Maxime Villard m...@m00nbsd.net
mailto:m...@m00nbsd.net wrote:
I've improved my code scanner, and it has found 26 potential bugs under
sys/.
Instead of flooding tech-kern@/tech-net@/etc with questions
Hi,
four bytes may overflow in ptyfs_vfsops.c::ptyfs_mount().
mount(XX, XX, XX, data, data_len)
The kernel will copyin data_len bytes of data into a kernel-allocated buffer.
This kernel buffer and data_len will be given to the appropriate xx_mount()
function, where xx is a fs.
Hi,
my code scanner reports in several places lines like these:
return ERROR_CODE/func(XXX);
return VALUE;
Of course the latter is never reached; is there a special syntax meaning behind
this? It's ok if I fix them all? I put here [1] those which seem obvious and
harmless.
Also,
Hi,
here is another set of 33 potential bugs found by my code scanner.
http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Report-3
Not all bugs are listed here; I've put only those which looked like proper
bugs. I guess they will all need to be fixed in NetBSD-7.
Maxime
Hi,
there seems to be a vnode issue in compat/linux/common/linux_uselib.c:
115 if (LINUX_N_MACHTYPE(hdr) != LINUX_MID_MACHINE)
116 return ENOEXEC;
Here 'vp' is not released. Patch:
Index: linux_uselib.c
===
RCS
Probably with the conviction I would find some bugs I opened ffs/ffs_vfsops.c
and something immediately stroke me:
918 error = bread(devvp, sblock_try[i] / DEV_BSIZE, SBLOCKSIZE,
cred,
919 0, bp);
SBLOCKSIZE (=8192) bytes are read on the disk and put into
Le 20/10/2014 18:23, David Holland a écrit :
On Mon, Oct 20, 2014 at 03:38:11PM +0200, Maxime Villard wrote:
I think the sanity check should be:
Index: ffs_vfsops.c
===
RCS file: /cvsroot/src/sys/ufs/ffs
Le 20/10/2014 18:48, Maxime Villard a écrit :
Le 20/10/2014 18:23, David Holland a écrit :
On Mon, Oct 20, 2014 at 03:38:11PM +0200, Maxime Villard wrote:
I think the sanity check should be:
Index: ffs_vfsops.c
I'll commit this, unless anyone disagrees.
Index: ffs_vfsops.c
===
RCS file: /cvsroot/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.299
diff -u -r1.299 ffs_vfsops.c
--- ffs_vfsops.c24 May 2014 16:34:04 - 1.299
Hi,
I think there's a rwlock issue in secmodel/secmodel.c:
174 if (sm == NULL) {
175 error = EFAULT;
176 goto out;
177 }
178
179 /* Check if the secmodel is already present. */
180 rw_enter(secmodels_lock, RW_WRITER);
...
out:
194 /* Unlock the
There is a kmem inconsistency in ffs_reload().
676 newfs = kmem_alloc(fs-fs_sbsize, KM_SLEEP);
677 memcpy(newfs, bp-b_data, fs-fs_sbsize);
and later:
705 memcpy(fs, newfs, (u_int)fs-fs_sbsize);
706 brelse(bp, 0);
707 kmem_free(newfs, fs-fs_sbsize);
The memcpy here
Le 27/10/2014 20:10, Christos Zoulas a écrit :
In article 544e69a5.6040...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Can someone explain me what this means?
sys/compat/netbsd32/netbsd32_compat_50.c:
256 (void) copyout(atv,
257 SCARG_P32(uap
Le 27/10/2014 21:21, Lars Heidieker a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 27 Oct 2014 16:42:15 +0100
Maxime Villard m...@m00nbsd.net wrote:
Hi,
I think there's a rwlock issue in secmodel/secmodel.c:
174 if (sm == NULL) {
175 error = EFAULT;
176
Hi,
there's something terribly sad with the kmem API: kmem_free takes
a size argument. It has I think two major drawbacks:
- the fact that the caller needs to know the allocated size often
leads to strange hacks in structures, where fields are added
just to hold allocated sizes.
Le 08/11/2014 18:06, Jean-Yves Migeon a écrit :
Le 08/11/2014 07:28, Maxime Villard a écrit :
[snip]
That's mostly what kern_malloc() does, but it is consistent and
sometimes consumes less memory - kern_malloc may allocate one more
page (PAGE_SIZE).
As some of you may have noticed, some
Le 08/11/2014 19:08, Michael van Elst a écrit :
m...@m00nbsd.net (Maxime Villard) writes:
We currently have malloc()/free(), which at a first glance would
be the solution when too many hacks take place.
kmem_alloc()/kmem_free() was invented to replace malloc/free
because the size to remember
Le 08/11/2014 23:28, Jean-Yves Migeon a écrit :
Le 08/11/2014 19:43, Maxime Villard a écrit :
Le 08/11/2014 18:06, Jean-Yves Migeon a écrit :
I agree that the size not being tracked by the allocator (well, it is,
but the API is ill-designed in this regard) leads to great bugs.
Two things come
Ok, I'm fine with this; what you say partly convinces me:
Le 09/11/2014 12:43, Robert Elz a écrit :
Date:Sun, 09 Nov 2014 09:06:40 +0100
From:Maxime Villard m...@m00nbsd.net
Message-ID: 545f2090.4000...@m00nbsd.net
| My point is:
| - KMEM_SIZE is only
Le 09/11/2014 09:43, Michael van Elst a écrit :
On Sat, Nov 08, 2014 at 07:46:08PM +0100, Maxime Villard wrote:
Le 08/11/2014 19:08, Michael van Elst a écrit :
As a side effect, it removed the debugging features of malloc/free.
As well as it allowed many bugs.
I doubt that it allowed many
Hi,
here is another list of bugs, smaller this time:
http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Report-4
Found by my code scanner.
Hi,
a bug I spotted some weeks ago:
-- libexec/httpd/auth-bozo.c l.139 --
base64_decode(const unsigned char *in, size_t ilen, unsigned char *out,
size_t olen)
{
unsigned char *cp;
size_t i;
cp = out;
for (i = 0; i
Hi,
most of the FSs under sys/fs have their headers in /usr/include/fs/FS-NAME/.
Some are just in /usr/include/FS-NAME/: msdosfs - adosfs - filecorefs - ntfs.
Is it intentional? It's ok if I move them in fs/?
Le 07/02/2015 12:51, Manuel Bouyer a écrit :
On Sat, Feb 07, 2015 at 12:19:36PM +0100, Maxime Villard wrote:
Hi,
I intend to remove the compat-FreeBSD support from the system.
please don't, I'm using it.
It has a limited interest since no major proprietary software is developed
Le 09/02/2015 10:12, Marc Balmer a écrit :
I intend to remove the compat-FreeBSD support from the system.
[...]
This is what motivates my proposal.
Ok?
Generally it would be a good idea, but there are obviously some tw_cli
users. So they need a working alternative first, imo. Maybe
Le 14/02/2015 08:40, David Holland a écrit :
On Fri, Feb 13, 2015 at 07:05:00PM +0100, Maxime Villard wrote:
Our norms for significant changes are more or less about consensus or
preponderance of opinion. So far you've said that you want to
remove/disable this, and a number of people
Le 31/12/2014 09:00, Maxime Villard a écrit :
Hi,
there seems to be a node leak in NTFS in two places: ntfs_ntget(ip) is
called, but the two functions return without calling ntfs_ntput(ip).
I would like some okayz before committing; I can't test it.
Regards,
Maxime
Finally, did
Le 13/02/2015 13:33, Marc Balmer a écrit :
Am 13.02.15 um 12:34 schrieb Maxime Villard:
Le 09/02/2015 10:12, Marc Balmer a écrit :
I intend to remove the compat-FreeBSD support from the system.
[...]
This is what motivates my proposal.
Ok?
Generally it would be a good idea
Apparently, compat-FreeBSD is needed by tw_cli users.
Therefore I think I will just disable it by default in the GENERIC kernels,
unless anyone disagrees.
Le 07/02/2015 12:19, Maxime Villard a écrit :
Hi,
I intend to remove the compat-FreeBSD support from the system.
It has a limited
Le 13/02/2015 22:03, J. Hannken-Illjes a écrit :
On 13 Feb 2015, at 19:18, Maxime Villard m...@m00nbsd.net wrote:
Hi,
this may be a stupid question; in ufs/ffs/ffs_vfsops.c, l.1153:
if (fs-fs_sbsize SBLOCKSIZE)
brelse(bp, BC_INVAL);
else
brelse(bp, 0
Hi,
I've found a bug in the way the kernel handles the PaX flags when
loading an ELF binary.
-- kern/exec_elf.c --
#if defined(PAX_MPROTECT) || defined(PAX_SEGVGUARD) || defined(PAX_ASLR)
l-l_proc-p_pax = epp-ep_pax_flags;
#endif /*
Le 25/02/2015 15:48, Christos Zoulas a écrit :
In article 54edb259.7020...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Attached is a patch. However I have a doubt: if the kernel loads a
binary, and then its interpreter, the p_pax flag is not used when load-
ing this interpreter
Le 25/02/2015 18:16, Christos Zoulas a écrit :
On Feb 25, 4:50pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: PaX: Heritage bug
| Attached is a patch. However I have a doubt: if the kernel loads a
| binary, and then its interpreter, the p_pax flag is not used when load
Hi,
there's still one bug that hasn't been fixed in this report:
http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Report-4
0x05 NO ERROR SET: sys/arch/arm/xscale/ixp425_if_npe.c [+] rev1.27
No error set at l.610.
I would suggest this [1], but I can't test it. Can someone
Hi,
here is a new list of 6 potential bugs:
http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Report-6
Please carefully test/investigate these bugs before fixing them. Also,
please include the keyword Brainy in your commit messages so that I
can easily keep track of what is/isn't
Le 04/04/2015 16:07, Maxime Villard a écrit :
Le 04/04/2015 15:42, Taylor R Campbell a écrit :
Date: Sat, 04 Apr 2015 15:25:23 +0200
From: Maxime Villard m...@m00nbsd.net
here is a patch to put the AppleUFS detection code inside a function.
This changes the behavior a bit
Hi,
here is a new list of 11 potential bugs:
http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Report-5
Please carefully test/investigate these bugs before fixing them. Also,
please include the keyword Brainy in your commit messages so that I
can easily keep track of what is/isn't
Le 04/04/2015 14:57, D'Arcy J.M. Cain a écrit :
On Sat, 04 Apr 2015 11:12:58 +0200
Maxime Villard m...@m00nbsd.net wrote:
here is a new list of 11 potential bugs:
Is it considered a bug that the list appears to be numbered in hex but
jumps from 0x09 to 0x10? :-)
Well, actually my first
Le 04/04/2015 15:42, Taylor R Campbell a écrit :
Date: Sat, 04 Apr 2015 15:25:23 +0200
From: Maxime Villard m...@m00nbsd.net
here is a patch to put the AppleUFS detection code inside a function.
This changes the behavior a bit: if the kernel cannot determine whether
Le 21/06/2015 11:47, Martin Husemann a écrit :
Should we make the native code use swapsys_lock()/swapsys_unlock() as
well, for consistency?
In fact, many comments around there refer to 'swap_syscall_lock',
and I didn't want to pollute the patch and update them all.
Martin
Hi,
I've been developing a new analysis engine for Brainy for some weeks
now, and I've just updated the UAF catcher to use this new engine.
Even though it still needs some work, it has just found two use-
after-free:
1. double free in sys/dev/pci/if_et.c
2. beautiful UAF in
Hi,
the 32bit version of swapctl() calls uvm_swap_stats() without locking
'swap_syscall_lock'. Which means that if you perform a swapctl() call
and at the same time update/add/delete a swap device, you may end up
with a memory corruption.
Here is a patch. Tested on amd64 (with a 32bit binary).
Le 08/06/2015 10:17, Brian Buhrow a écrit :
hello. There is a proposal around to drop support for old NetBSD
binaries in current ersions of NetBSD. For example, nuking COMPAT_NOMID,
COMPAT_10, COMPAT_12, COMPAT_13 COMPAT_14, etc. from the the -current
source tree. I'll let the
Hi,
not a kernel issue, but
--- libexec/httpd/lua-bozo.c ---
321 asprintf(file, /%s, uri);
}
if (file == NULL) {
free(prefix);
return 0;
}
if (request-hr_query
Hi,
-- sys/arch/arm/arm/cpufunc.c --
2309
} else if ((fault_instruction 0x0e00) == 0x0c00) {
[...]
} else if ((fault_instruction 0x0e00) == 0x0c00)
return ABORT_FIXUP_FAILED;
Le 29/07/2015 17:22, Taylor R Campbell a écrit :
Date: Wed, 29 Jul 2015 07:59:46 +0200
From: Maxime Villard m...@m00nbsd.net
What happens if the kernel calls splx(s) twice? And what happens if it
forgets to call splx(s)? Like:
s = splnet
Thanks for your answers.
I guess I'll add the per-CPU queue idea to my TODO list.
[I sent this mail some days ago, but it didn't reach tech-kern@.]
http://marc.info/?l=netbsd-tech-kernm=142486844004373w=2
Here is a new patch. Now, the PaX flag is converted and registered
into the exec package by the loaders (only one loader does that, the
native ELF). And right before
What happens if the kernel calls splx(s) twice? And what happens if it
forgets to call splx(s)? Like:
s = splnet();
[...] NOT RELATED TO S
return; NO SPLX(S)
I guess it creates some inconsistency, right?
Do we have a magic function that can perform two atomic_swap_ptr()
atomically?
In kern/subr_kmem.c::kmem_guard_free(), the code used to be
rotor = atomic_inc_uint_nv(kg-kg_rotor) % kg-kg_depth;
va = (vaddr_t)atomic_swap_ptr(kg-kg_fifo[rotor], (void *)va);
if (va != 0) {
/08/2015 10:53, Maxime Villard a écrit :
[I sent this mail some days ago, but it didn't reach tech-kern@.]
http://marc.info/?l=netbsd-tech-kernm=142486844004373w=2
Here is a new patch. Now, the PaX flag is converted and registered
into the exec package by the loaders (only one loader
Hi,
there is a memory leak here:
--- sys/net/if_ieee1394subr.c --
MGETHDR(m, M_DONTWAIT, MT_HEADER);
if (m == NULL)
goto bad;
m-m_flags |= m0-m_flags (M_BCAST|M_MCAST); /* copy bcast
Hi,
here is a patch I must have written after fixing the bugs in mount one or
two years ago. It changes do_sys_mount() so that it only takes as argument
the type of the drive instead of its associated vfsops.
It does change the behavior for the compat layers: now that the associated
vfsops is
Index: xbd_xenbus.c
===
RCS file: /cvsroot/src/sys/arch/xen/xen/xbd_xenbus.c,v
retrieving revision 1.74
diff -u -r1.74 xbd_xenbus.c
--- xbd_xenbus.c28 Aug 2015 17:41:49 - 1.74
+++ xbd_xenbus.c24 Oct 2015
sys/netnatm/natm.c
struct natmpcb *npcb;
struct sockaddr_natm *snatm = (struct sockaddr_natm *)nam;
struct atm_pseudoioctl api;
struct atm_pseudohdr *aph;
struct ifnet *ifp;
int proto =
Hi,
a bug I must have spotted some weeks ago: the kernel decrements the
number of offline cpus even when trying to shutting down one fails.
How to reproduce:
# schedctl -p SOME_RANDOM_PROC_PID -A 0
# sysctl hw.ncpuonline
# cpuctl offline 0 (it fails)
# sysctl
Hi,
I've added some bugs here:
http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Unsorted-4
I don't have time to investigate, review and fix them. They don't seem all
easy to fix, so please make sure you can test/carefully review your changes,
as usual. Below is a summary, in case
Le 30/08/2015 06:43, David Holland a écrit :
> On Fri, Aug 28, 2015 at 11:17:24AM +0200, Maxime Villard wrote:
> > _11/ UNINITIALIZED VAR: sys/dev/ic/sgec.c
> > _12/ USE-AFTER-FREE: sys/arch/mips/alchemy/dev/aupcmcia.c
> > _13/ MEMORY LEAK: sys/dev/ic/smc91cxx.c
> >
... if someone is interested:
http://m00nbsd.net/ae123a9bae03f7dde5c6d654412daf5a.html#Unsorted-4
Summary:
_22/ MEMORY LEAK: sys/dev/ic/seeq8005.c [+] rev1.53
_23/ MEMORY LEAK: sys/dev/pci/if_jme.c [+] rev1.27
_24/ MEMORY LEAK: sys/dev/qbus/if_il.c [+] rev1.27
_25/ USE-AFTER-FREE:
Le 03/10/2015 16:29, Jean-Yves Migeon a écrit :
Le 03/10/2015 15:45, Joerg Sonnenberger a écrit :
On Sat, Oct 03, 2015 at 02:46:26PM +0200, Maxime Villard wrote:
You can see that the pointer given to kmem_free() is not the one kmem_alloc
returned. Actually, I don't understand at all what
I've committed it.
Le 06/08/2015 17:26, Maxime Villard a écrit :
> Updated diff
>
>
> Index: kern/exec_elf.c
> ===
> RCS file: /cvsroot/src/sys/kern/exec_elf.c,v
> retrieving revision 1.75
> diff -u -r1.
Le 12/09/2015 09:33, David Holland a écrit :
> On Fri, Sep 11, 2015 at 09:11:02PM +0200, Maxime Villard wrote:
> > _26/ INCONSISTENCY: sys/fs/udf/udf_strat_rmw.c [+] rev1.24
>
> : _26/ INCONSISTENCY: sys/fs/udf/udf_strat_rmw.c [+] rev1.24
> : Inconsistency at l.622 a
Hi,
in sys/dev/iscsi/iscsi_ioctl.c:
1542free(sess, M_DEVBUF);
1543
1544DEB(1, ("Cleanup: session ended %d\n", sess->id));
I guess inverting the two instructions fixes the bug.
Found by Brainy.
Maxime
This actually requires more investigation. I'll see later; perhaps I'll
just protect DATA.
Le 28/11/2015 19:54, Maxime Villard a écrit :
Hi,
here is a (draft) patch to map the kernel DATA and BSS segments with
the NX/XD bit in the PTEs on i386+amd64.
A nice PoC: patch your (amd64) kernel
Hi,
here is a (draft) patch to map the kernel DATA and BSS segments with
the NX/XD bit in the PTEs on i386+amd64.
A nice PoC: patch your (amd64) kernel with the shellcode below, and
launch this:
#include
#include
#include
int main() {
Le 08/06/2016 à 08:57, Martin Husemann a écrit :
On Wed, Jun 08, 2016 at 05:57:47AM +0800, Paul Goyette wrote:
All of this sounds like a good idea. however, there are at least one or
two PRs out there related to limits on the amount of address space that
modules can occupy, on i386.
Where?
Le 07/06/2016 à 18:04, Christos Zoulas a écrit :
On Jun 7, 3:20pm, dholland-t...@netbsd.org (David Holland) wrote:
-- Subject: Re: gets in the kernel
| On Tue, Jun 07, 2016 at 12:36:54PM +0200, Maxime Villard wrote:
| > >I noticed that gets_s (a bounded version of gets) was
Le 05/06/2016 à 20:53, Christos Zoulas a écrit :
Hi,
I noticed that gets_s (a bounded version of gets) was added in the kernel.
While this iis nice, it conflicts with the c-11 "Annex K" which has a
different prototype (takes rsize_t instead of size_t). Perhaps we should
rename this to kgets()
The bootloader has a preload feature that allows a kernel module to be allocated
by the bootloader in low memory before the kernel is started. A pointer to the
module is given to the kernel via a bootinfo, and the kernel parses it and uses
it as-is in low memory. There is no granularity provided
Le 14/05/2016 à 04:14, Kamil Rytarowski a écrit :
On 13.05.2016 12:53, Maxime Villard wrote:
I've committed several improvements in amd64 these last days.
Thank you for working on it!
One question, have you got plans for W^X stacks? I'm asking because I
still find trampolines/nested
The location where proc0's stack is put on amd64 is highly bizarre: it is placed
between two page levels. Which implies that a stack overflow can overwrite a
page level. This patch moves the stack out of the BOOTSTRAP TABLES chunk, puts
it before L4, and maps it independently.
We can then easily
Now i386 benefits from the same improvements as amd64. There are two
differences though:
- on non-PAE i386, NOX does not exist. Therefore the mappings all have an
additional X permission. To benefit from X-less mappings, your CPU must
support PAE, and your kernel must be GENERIC_PAE.
-
Le 15/05/2016 15:42, Joerg Sonnenberger a écrit :
On Fri, May 13, 2016 at 05:42:55PM +0200, Maxime Villard wrote:
Le 13/05/2016 16:48, Martin Husemann a écrit :
On Fri, May 13, 2016 at 12:53:54PM +0200, Maxime Villard wrote:
- I took rodata out of the text+rodata chunk, and put
I've committed several improvements in amd64 these last days.
In chronological order, for the record:
- I cleaned up the asm code and fixed several comments, which makes the
boot process much easier to understand.
- I fixed the alignment for the text segment, so that it can be covered by
Le 13/05/2016 16:48, Martin Husemann a écrit :
On Fri, May 13, 2016 at 12:53:54PM +0200, Maxime Villard wrote:
- I took rodata out of the text+rodata chunk, and put it in the data+bss+
PRELOADED_MODULES+BOOTSTRAP_TABLES chunk [3].
Why?
You are probably assuming something obvious to you
Le 13/05/2016 23:09, Martin Husemann a écrit :
On Fri, May 13, 2016 at 05:42:55PM +0200, Maxime Villard wrote:
Initially, two chunks were mapped contiguously in both amd64 and i386:
- text+rodata with RX permissions
Thanks for the detailed explanation.
What I still don't get is why you
Le 24/07/2016 à 22:57, Joerg Sonnenberger a écrit :
On Sun, Jul 24, 2016 at 01:09:46PM +0200, Maxime Villard wrote:
The goal of sysrestrict (and pledge, and whatever else) is not to provide the
perfect feature that will control absolutely everything. The goal is just to
provide an additionnal
Le 26/07/2016 à 11:56, Joerg Sonnenberger a écrit :
It's just obvious: we don't want ftpd to call modctl, or execve (even if it
currently does), or mount, or reboot, or swapctl, etc. And it gets solved
by restricting those syscalls.
You haven't answered my question. "I don't want to allow
Currently, there is no real way to make sure a userland process won't be
able to allocate the NULL page. There is this attempt [1], but it has two
major issues.
First, it is easy to bypass ([2]). The combination of parameters in the
code makes sure this branch [3] is not taken, then [4] is
Le 23/07/2016 à 21:36, Matt Thomas a écrit :
On Jul 23, 2016, at 1:36 AM, Maxime Villard <m...@m00nbsd.net> wrote:
Eight months ago, I shared with a few developers the code for a kernel
interface [1] that can disable syscalls in user processes.
The idea is the following: a syscall
Le 23/07/2016 à 23:50, Paul Goyette a écrit :
I would assume that the checking of syscall restrictions would be done
within the kauth(9) framework?
As I wrote it, it is not. It wouldn't be hard to switch to kauth, but I fear
the performance cost would be higher.
Le 24/07/2016 à 00:52, Alistair Crooks a écrit :
ISTM that your sysretsrict suffers from one of the same drawbacks as
pledge/tame/name-du-jour - the restrictions are being burned into the
binary at compile/link time.
No. As I said, the userland tool could add or modify the bitmap in the ELF
Le 28/07/2016 à 19:45, Eduardo Horvath a écrit :
On Thu, 28 Jul 2016, Maxime Villard wrote:
Currently, there is no real way to make sure a userland process won't be
able to allocate the NULL page. There is this attempt [1], but it has two
major issues.
I don't think this is a good idea. You
1 - 100 of 392 matches
Mail list logo
