Applied, thanks!
Luca Dariz, le mer. 12 juin 2024 08:27:54 +0200, a ecrit:
> * ipc/copy_user.c: recent MIG stubs should always fill the size
> correctly in the msg header, but we shouldn't rely on that. Instead,
> we use the size that was correctly copied-in, overwriting the va
* ipc/copy_user.c: recent MIG stubs should always fill the size
correctly in the msg header, but we shouldn't rely on that. Instead,
we use the size that was correctly copied-in, overwriting the value
in the header. This is already done by the 32-bit copyinmsg(), and
was missing in t
Sergey Bugaev, le mer. 27 mars 2024 19:18:33 +0300, a ecrit:
> Since they are implemented in copy_user.c
> ---
> i386/i386/locore.h | 4
> ipc/copy_user.h| 15 +++
> kern/exception.c | 1 +
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/i386/i386/loc
Since they are implemented in copy_user.c
---
i386/i386/locore.h | 4
ipc/copy_user.h| 15 +++
kern/exception.c | 1 +
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/i386/i386/locore.h b/i386/i386/locore.h
index 217e6dec..8ff587ed 100644
--- a/i386/i386/lo
Applied, thanks!
Sergey Bugaev, le sam. 29 avril 2023 16:13:52 +0300, a ecrit:
> The leak can be easily reproduced (and observed) using the portinfo
> tool:
>
> $ portinfo -v $$ | grep task
> 36: send task(1577)(self) (refs: 127)
> $ portinfo -v $$ | grep task
> 36: send task(1577)(self)
The leak can be easily reproduced (and observed) using the portinfo
tool:
$ portinfo -v $$ | grep task
36: send task(1577)(self) (refs: 127)
$ portinfo -v $$ | grep task
36: send task(1577)(self) (refs: 253)
$ portinfo -v $$ | grep task
36: send task(1577)(self) (refs: 379)
$ portinfo
Sergey Bugaev, le mer. 01 mars 2023 12:21:17 +0300, a ecrit:
> * eip < _hurd_intr_rpc_msg_about_to => thread is still to check
> ss->cancel, so just set ss->cancel = 1;
> * _hurd_intr_rpc_msg_about_to <= eip < _hurd_intr_rpc_msg_setup_done
> => thread is still to check eax, so set eax = MACH_SEND_I
On Wed, Mar 1, 2023 at 12:09 AM Samuel Thibault wrote:
>
> Sergey Bugaev, le mar. 28 févr. 2023 18:53:05 +0300, a ecrit:
> > Really, why would it matter whether eip is after
> > _hurd_intr_rpc_msg_about_to or not? What if it's 1 instruction before
> > that? We skip the call, pretending it was inte
Sergey Bugaev, le mar. 28 févr. 2023 18:53:05 +0300, a ecrit:
> Really, why would it matter whether eip is after
> _hurd_intr_rpc_msg_about_to or not? What if it's 1 instruction before
> that? We skip the call, pretending it was interrupted, but does it
> really matter that we do that — can't we ju
So I implemented this, and it seems to work — as in, signals arrive
and handlers run. It's extremely unlikely that I managed to hit the
interesting code path where eip is inside that piece of code, so who
knows whether that works or not — especially given this has been
apparently broken in glibc fo
Sergey Bugaev, le lun. 27 févr. 2023 20:03:07 +0300, a ecrit:
> On Mon, Feb 27, 2023 at 7:39 PM Samuel Thibault
> wrote:
> > > Are there any tests for this at all?
> >
> > It's very difficult to test since it's all about race conditions, with
> > the interruption happening exactly at the wrong mo
On Mon, Feb 27, 2023 at 7:39 PM Samuel Thibault wrote:
> > Are there any tests for this at all?
>
> It's very difficult to test since it's all about race conditions, with
> the interruption happening exactly at the wrong moment.
Right, but can't it be made reliable with some creative use of
ptrac
Hello,
Sergey Bugaev, le lun. 27 févr. 2023 16:39:19 +0300, a ecrit:
> Does my reasoning make sense? Am I missing anything? Was this a simple
> oversight of 1d20f33ff4fb634310f27493b7b87d0b20f4a0b0,
It most probably was, yes.
> Are there any tests for this at all?
It's very difficult to test si
URN = MACH_SEND_INTERRUPTED;
*state_change = 1;
}
Or in other words: this forcefully jumps the thread to right after the
syscall, pretending it has returned MACH_SEND_INTERRUPTED, but also
makes any arch-specific changes to the state (INTR_MSG_BACK_OUT).
Now, I have found commit 1d20f33ff4f
Luca Dariz, le lun. 16 janv. 2023 11:58:52 +0100, a ecrit:
+static inline int copyin_address(const rpc_vm_offset_t *uaddr, vm_offset_t
*kaddr)
+{
+#ifdef __x86_64
+ return copyin_32to64(uaddr, kaddr);
+#else /* __x86_64__ */
+ return copyin(uaddr, kaddr, sizeof(*uaddr));
+#endif /* __x86_64__
Applied except a little thing, thanks!
Luca Dariz, le lun. 16 janv. 2023 11:58:52 +0100, a ecrit:
> +static inline int copyin_address(const rpc_vm_offset_t *uaddr, vm_offset_t
> *kaddr)
> +{
> +#ifdef __x86_64
> + return copyin_32to64(uaddr, kaddr);
> +#else /* __x86_64__ */
> + return copyin(u
edef mach_msg_header_t mach_msg_user_header_t;
> +#endif
> +
> /*
> * There is no fixed upper bound to the size of Mach messages.
> */
> @@ -389,7 +404,7 @@ typedef kern_return_t mach_msg_return_t;
>
> extern mach_msg_return_t
> mach_msg_trap
> - (mach_msg_header_
;
+#else
+typedef mach_msg_header_t mach_msg_user_header_t;
+#endif
+
/*
* There is no fixed upper bound to the size of Mach messages.
*/
@@ -389,7 +404,7 @@ typedef kern_return_t mach_msg_return_t;
extern mach_msg_return_t
mach_msg_trap
- (mach_msg_header_t *msg
* i386/i386/copy_user.h: new file to handle 32/64 bit differences
- add msg_usize() to recontruct the user-space message size
- add copyin/copyout helpers for addresses and ports
* include/mach/message.h: add msg alignment macros
* ipc/ipc_kmsg.c:
- copyin/out ports names instead of using
Luca, le mar. 04 oct. 2022 22:39:03 +0200, a ecrit:
> Il 30/08/22 07:57, Luca ha scritto:
> > Il 28/08/22 15:13, Samuel Thibault ha scritto:
> > > > + size_t n = size / 8;
> > > > + saddr += n*number;
> > > > + usize += n*number;
> > > > +
Il 30/08/22 07:57, Luca ha scritto:
Il 28/08/22 15:13, Samuel Thibault ha scritto:
+ }
+ else
+ {
+ size_t n = size / 8;
+ saddr += n*number;
+ usize += n*number;
+ align_inline(saddr
> Il 30/08/2022 08:17 CEST Samuel Thibault ha scritto:
> Luca, le mar. 30 août 2022 07:57:23 +0200, a ecrit:
> > Il 28/08/22 15:13, Samuel Thibault ha scritto:
> > > This was breaking the 32bit kernel case. I have pushed a fix for that,
> > > that does this move of setting msgh_size to copyinmsg i
Luca Dariz, le mar. 30 août 2022 09:23:50 +0200, a ecrit:
> > Il 30/08/2022 08:17 CEST Samuel Thibault ha
> > scritto:
> > Luca, le mar. 30 août 2022 07:57:23 +0200, a ecrit:
> > > Il 28/08/22 15:13, Samuel Thibault ha scritto:
> > > > This was breaking the 32bit kernel case. I have pushed a fix
Luca, le mar. 30 août 2022 07:57:23 +0200, a ecrit:
> Il 28/08/22 15:13, Samuel Thibault ha scritto:
> > This was breaking the 32bit kernel case. I have pushed a fix for that,
> > that does this move of setting msgh_size to copyinmsg itself.
>
> The 32-bit case was breaking because it needed an up
Il 28/08/22 15:13, Samuel Thibault ha scritto:
That's great work :D
Thanks :)
Luca Dariz, le mar. 28 juin 2022 12:10:49 +0200, a ecrit:
diff --git a/i386/i386/copy_user.h b/i386/i386/copy_user.h
new file mode 100644
index ..ab932401
--- /dev/null
+++ b/i386/i386/copy_user.h
@@ -0,0 +
Hello,
That's great work :D
Luca Dariz, le mar. 28 juin 2022 12:10:49 +0200, a ecrit:
> diff --git a/i386/i386/copy_user.h b/i386/i386/copy_user.h
> new file mode 100644
> index ..ab932401
> --- /dev/null
> +++ b/i386/i386/copy_user.h
> @@ -0,0 +1,22 @@
Please add the copyright header.
Luca Dariz, le mar. 28 juin 2022 12:10:45 +0200, a ecrit:
> * ipc/ipc_kmsg.c: align msg body to 4 bytes as done in mig
>
> Signed-off-by: Luca Dariz
Applied and fixed, thanks!
> ---
> ipc/ipc_kmsg.c | 49 ++---
> 1 file changed, 22
Luca Dariz, le mar. 28 juin 2022 11:49:27 +0200, a ecrit:
> * user.c:
> - adjust comment in generated file
> - set msgh_size with the same value passed to mach_msg()
>
> Signed-off-by: Luca Dariz
Applied, thanks!
> ---
> user.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
bit builds
- 32-bit pointer -> 64 bit pointer when using 32-bit userspace
* x86_64/locore.S: remove copyinmsg() and copyoutmsg()
Note that this depends on this change in mig for the correct size in msgh:
* fill msg size in the header for user stubs
---
i386/i386/copy_user.h | 22
includ
* ipc/ipc_kmsg.c: align msg body to 4 bytes as done in mig
Signed-off-by: Luca Dariz
---
ipc/ipc_kmsg.c | 49 ++---
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/ipc/ipc_kmsg.c b/ipc/ipc_kmsg.c
index b9d29853..09801924 100644
--- a
* user.c:
- adjust comment in generated file
- set msgh_size with the same value passed to mach_msg()
Signed-off-by: Luca Dariz
---
user.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/user.c b/user.c
index 9a84fe4..886198b 100644
--- a/user.c
+++ b/user.c
@@ -159,
---
ipc/mach_msg.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/ipc/mach_msg.c b/ipc/mach_msg.c
index aecfcd4..07e59e2 100644
--- a/ipc/mach_msg.c
+++ b/ipc/mach_msg.c
@@ -1673,9 +1673,7 @@ mach_msg_trap(
* (syscall entry and thread_syscall_return ex
Order from Canada and save money.
***We are running hot specials***
Meds starts at only 99
- Meridia, Xanax and so much more
- Meds are 80% less than regular price
- No doctor visits or hassles
- Quick delivery to your front door
Click here.
__
Order from Canada and save money.
We are running hot specials***
Meds starts at only 99
- Meridia, Xanax and so much more
- Meds are 80% less than regular price
- No doctor visits or hassles
- Quick delivery to your front door
Click here.
_
Hi,
Sometime last term I got sick of using -I msg.lists, so I made a simple
change so that rpctrace would read the msgids from a standard place.
Two problems came up with this:
Where should these msgids files be install? I think /share/hurd would
be the best place for them.
How do get
Hi Rashim,
I am vishwas. Even I am very new to GNU-HURD. I was
able to install HURD on my Pentium Pro 400 using
Debian image downloaded from ftp://ftp.gnu.org/iso/.
You can find more info about installing HURD at
http://www.gnu.org/software/hurd/install.html
As per the documentation cross-compi
On Thu, Jul 12, 2001 at 08:01:13PM -0400, Roland McGrath wrote:
> proc_setexecdata never deallocates the old port rights.
Isn't the following code doing the job?
if (std_port_array)
{
for (i = 0; i < n_std_ports; i++)
mach_port_deallocate (mach_task_self (), std_port_array[i]
Roland McGrath <[EMAIL PROTECTED]> writes:
> proc_getexecdata and proc_setexecdata both seem to be totally broken.
> It seems like they have never actually been called.
Surely true.
> I think the only correct thing for proc_getexecdata to do is add a user ref
> to each port and then set *portsp
proc_getexecdata and proc_setexecdata both seem to be totally broken.
It seems like they have never actually been called.
proc_setexecdata never deallocates the old port rights.
proc_getexecdata never sets its *portspoly out parameter, so garbage goes
into the reply message.
I think the only co
Hi,
this is not so easy to see, esp with all the libports mayhem.
proc_getexecdata just memcpy()s the port array, and then returns. Will this
do the right thing? proc is essentially single threaded, by taking a lock
in message_demuxer. But as it seems to me, the message has not yet actually
b
40 matches
Mail list logo
