Hello!
On Sat, Oct 16, 2021 at 12:38 PM Joan Lledó wrote:
> The new interface needs to know about proxies, and if one range has been
> mapped using a proxy, it must return the proxy and not the original object,
> which could be used to bypass the proxy protection, that's why I needed a way
> t
On Sat, Oct 16, 2021 at 2:27 PM Sergey Bugaev wrote:
> I don't think it should *ever* return the original object back. I'd
> rather it always made a new proxy that internally references the
> object and caps max_protection to that of the region.
I also think there's a phi
On Sat, Oct 16, 2021 at 6:54 PM Samuel Thibault wrote:
> Indeed, since it's the region that remembers which protection was
> allowed, we need a proxy there to enforce them.
Right, that's also a good point. max_proection can be less than 7 even
if there never was a proxy. That is, one can do
vm_m
On Sun, Oct 17, 2021 at 6:41 PM Joan Lledó wrote:
> Why the "size" parameter? I'd rather see a new wrapper for
> memory_object_create_proxy() which receives the same params but with the
> address instead of the original pager, which internally gets the pager
> from the address and calls memory_obj
On Tue, Oct 19, 2021 at 1:42 PM Andrea Monaco
wrote:
> common boot scripts call reboot with -f or --force to force a reboot. I
> think our reboot can safely recognize and ignore it, to avoid breaking
> those scripts and make interchange of scripts easier.
Wouldn't it be better to implement --forc
On Tue, Oct 19, 2021 at 2:27 PM Samuel Thibault wrote:
> Reboot-hurd is already that actually. What -f ignores on Linux is the
> daemon shut down, which reboot-hurd ignores as well. People still expect
> Linux to properly flush page cache and buffers, i.e. safely shut down
> translators, which reb
On Tue, Oct 19, 2021 at 3:18 PM Samuel Thibault wrote:
> IIRC the kernel does unmount filesystems and flushes caches before
> actually rebooting.
These two comments provide some more details:
"reboot doesn't sync: do that yourself before calling this." [0]
"The kernel will automatically flush AT
On Sun, Oct 24, 2021 at 4:47 PM Ludovic Courtès wrote:
> $ addr2line -e
> /gnu/store/acl9ffg0pjcj1hvzf8f5pz98xm0cqpps-gnumach-1.8-1.097f9cf/boot/gnumach
> 0xc10b1f5d 0xc105c6da 0xc1046209 0xc1040d25 0xc104a7a5 0xc1022252 0xc1052ef9
> 0xc10071f8
> /tmp/guix-build-gnumach-1.8-1.097f9cf.drv-0/sour
On Sun, Oct 24, 2021 at 7:28 PM Joan Lledó wrote:
> +routine memory_object_get_proxy(
> + task: task_t;
Naming: perhaps memory_object_create_vm_proxy ()? or even
memory_object_create_task_vm_proxy ()?
I would expect the request port argument to be a vm_task_t (i.e. a
vm
On Sat, Oct 30, 2021 at 9:38 AM Joan Lledó wrote:
> El 24/10/21 a les 19:50, Sergey Bugaev ha escrit:
> > I would expect the request port argument to be a vm_task_t (i.e. a
> > vm_map), not a full task. But I see that you need to pass
> > task->itk_space to memory_obj
On Sat, Oct 30, 2021 at 3:06 PM Sergey Bugaev wrote:
> But
> memory_object_create_proxy () does add a reference to the memory
> object by doing ipc_port_copy_send (object[0]). It would seem that it
> should not do that; but then I'm not sure why this doesn't cause a
>
On Mon, Nov 1, 2021 at 12:33 PM Joan Lledó wrote:
> Thanks for your explanations, it makes sense but there's still one thing I
> don't understand: if memory_object_create_proxy() is the owner of the pager
> it receives as parameter, and the caller doesn't care about releasing it,
> then where i
On Mon, Nov 1, 2021 at 12:32 PM Joan Lledó wrote:
> +kern_return_t
> +memory_object_get_proxy (task_t task, const vm_offset_t address,
> +vm_prot_t max_protection, vm_offset_t len,
> +ipc_port_t *port)
> +{
> + kern_return_t err;
Super minor nitpic
On Sun, Oct 31, 2021 at 8:44 PM Svante Signell wrote:
> One alternative to the path_max.diff patch is to simply do:
> #ifndef PATH_MAX
> #define PATH_MAX 4096
> #endif
> in xf86drm.c. This is a patch that upstream would accept more easily than the
> proposed one, but is not very Hurdish.
>
> WDYT?
So I've applied the patch and have tried to actually exercise the new
functionality.
And unfortunately, I'm reminded (by a kernel panic and a corrupted
filesystem) of the two important cases that we have forgot:
* Submaps
* "Anonymous" mappings (created with a null memory object)
Submaps could b
On Mon, Nov 1, 2021 at 6:44 PM Joan Lledó wrote:
> > * "Anonymous" mappings (created with a null memory object)
>
> If they provide no object when calling vm_map, then the kernel uses the
> default pager, isn't it?
Conceptually, yes. But the way it's implemented, the object->pager
port stays null
On Mon, Nov 1, 2021 at 7:13 PM Sergey Bugaev wrote:
> But again, let's try to get the simple version working first. As I've
> said, with vm_object_pager_create () it kind of works, except it
> doesn't give me the actual data for whatever reason.
Phew, I figured out wh
On Mon, Nov 1, 2021 at 10:36 PM Samuel Thibault wrote:
> offset is inside the original object, and start is in the proxy object.
> Think for instance of /dev/mem, within which you could want to map some
> VGA-compatible range at 0xA (that's the start), but the mapping
> range is a subpart of t
Short description
=
When trying to exec a setuid executable, there's a window of time when the
process already has the new privileges, but still refers to the old task and is
accessible through the old process port. This can be exploited to get full root
access to the system.
Bac
Short description
=
A single pager port is shared between anyone who mmaps a file, allowing anyone
to modify any files they can read. This can be trivially exploited to get full
root access to the system.
Background: Mach memory objects
===
Mach has t
Short description
=
The use of authentication protocol in the proc server is vulnerable to
man-in-the-middle attacks, which can be exploited for local privilege escalation
to get full root access to the system.
Background: authentication
==
Here, the word
Short description
=
libports accepts fake notification messages from any client on any port, which
can lead to port use-after-free, which can be exploited for local privilege
escalation to get full root access to the system.
Background: Mach notifications
Hello!
As promised [0], here are the details of the Hurd vulnerabilities I have found
earlier this year [1] [2].
[0]: https://lists.gnu.org/archive/html/bug-hurd/2021-10/msg6.html
[1]: https://lists.gnu.org/archive/html/bug-hurd/2021-05/msg00079.html
[2]: https://lists.gnu.org/archive/html/bu
On Sat, Oct 30, 2021 at 9:38 AM Joan Lledó wrote:
> El 24/10/21 a les 19:50, Sergey Bugaev ha escrit:
> > Naming: perhaps memory_object_create_vm_proxy ()? or even
> > memory_object_create_task_vm_proxy ()?
>
> I don't care about the name, you guys de
On Fri, Nov 5, 2021 at 1:41 PM Samuel Thibault wrote:
>
> William ML Leslie, le ven. 05 nov. 2021 21:18:50 +1100, a ecrit:
> > > which makes the root filesystem reauthenticate all of the
> > > processes file descriptors.
> >
> > It seems to eliminate a rather convenient method of delegation; a
> >
ing is.
On Fri, Nov 5, 2021 at 3:52 PM William ML Leslie
wrote:
>
> On Fri, 5 Nov 2021 at 22:17, Sergey Bugaev wrote:
>> The Hurd is a capability system, but not a *pure* capability system:
>> it implements Unix semantics on top of Mach/capabilities. File
>> descripto
Hello,
I investigated briefly and found this piece of code to be the likely
culprit [0]. I also see that the previous investigation also arrived
at the same conclusion [1].
[0]:
https://gitlab.gnome.org/GNOME/vte/-/blob/db3c6253d7fa1645996a2abd9fd55df414ca4c2d/src/missing.cc#L218
[1]: https://li
On Sat, Nov 6, 2021 at 3:16 PM Samuel Thibault wrote:
> To exercise it you can probably move
> sysdeps/unix/sysv/linux/tst-close_range.c to misc/,
> and add it to tests in sysdeps/mach/hurd/Makefile too.
That doesn't seem to work: it uses support_descriptors_* () which
walks over /proc/self/fd/ w
kernel, a fallback implementation is never necessary.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/Makefile | 1 +
sysdeps/mach/hurd/Versions | 3 ++
sysdeps/mach/hurd/bits/unistd_ext.h | 34 +++
sysdeps/mach/hurd/close_range.c | 67
On Sun, Nov 7, 2021 at 6:00 PM Samuel Thibault wrote:
> > That doesn't seem to work: it uses support_descriptors_* () which
> > walks over /proc/self/fd/ which procfs doesn't implement — though I
> > guess it could, via msg_get_dtable () & msg_get_fd () and even
> > FS_RETRY_MAGICAL.
>
> It'd prob
On Sun, Nov 7, 2021 at 6:27 PM Samuel Thibault wrote:
> libnetfs does not this way, see libnetfs/dir-lookup.c, it'll first look
> for self/, then for the rest, directory by directory.
I know — that's one of my major gripes with libnetfs. Resolving paths
component-by-component is _really not_ what
On Sun, Nov 14, 2021 at 2:17 PM Joan Lledó wrote:
>
> Hi,
>
> I'm trying to implement a correct release of resources in libpciaccess
> x86 module. I have this text from Sergey as reference
Hello! You're lucky to have caught me on my very last day :)
> Please take a look at map_dev_mem() implemen
> +mem_size = (mem_size + vm_page_size - 1) % vm_page_size;
Or rather: roundup (mem_size, vm_page_size)
On Tue, Nov 29, 2022 at 7:34 AM Guy-Fleury Iteriteka
wrote:
> There is a thread from bugaev that explain the issue and a partial fix :
>
> https://floss.social/@bugaevc/109422269238549581
Well, I guess that's my cue to wave hi to this list :)
Hello everyone!
I am indeed out of the army, alive a
On Tue, Nov 29, 2022 at 11:47 AM Samuel Thibault
wrote:
> Sergey Bugaev, le mar. 29 nov. 2022 09:22:20 +0300, a ecrit:
> > Hello everyone!
> >
> > I am indeed out of the army, alive and in one piece.
>
> !! \o/ !!
>
> I have to say I was very worried, I'm
On Tue, Nov 29, 2022 at 4:24 PM Sergey Bugaev wrote:
> Well, here's a preliminary patch. Please don't expect it to be any
> good, I must have forgotten all the subtleties of glibc development —
> those that I managed to learn in the first place — over the year. That
> be
/urandom: /hurd/symlink random
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/getrandom.c | 101 --
1 file changed, 85 insertions(+), 16 deletions(-)
diff --git a/sysdeps/mach/hurd/getrandom.c b/sysdeps/mach/hurd/getrandom.c
index ad2d3ba3..70a0e582 100644
--- a/sys
On Fri, Dec 2, 2022 at 12:17 PM Samuel Thibault wrote:
>
> Hello,
>
> Sergey Bugaev, le ven. 02 déc. 2022 12:13:51 +0300, a ecrit:
> > Caveat: this new implementation does not respect the GRND_RANDOM flag
> > and always uses /dev/urandom to read random data.
>
>
, whereas previously it took about 50 seconds. This
program was also used to test that getrandom () doesn't explode if the
random server dies, but instead reopens the /dev/urandom anew. I have
also verified that with this patch, OpenSSH can once again accept
connections properly.
Si
On Fri, Dec 2, 2022 at 4:56 PM Sergey Bugaev wrote:
> + switch (flags)
> +{
> +case 0:
> + cached_server = &urandom_server;
> + break;
> +case GRND_RANDOM:
> + cached_server = &random_server;
> + break;
> +case GR
ilemonitor.c
@@ -0,0 +1,269 @@
+/* GIO - GLib Input, Output and Streaming Library
+ *
+ * Copyright (C) 2022 Sergey Bugaev
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Softwar
the ::changed
signal does get emitted indeed.
Feedback is very welcome!
Sergey
Sergey Bugaev (1):
Very WIP: Add GHurdFileMonitor
gio/giomodule.c | 4 +
gio/hurd/fs_notify.defs | 9 ++
gio/hurd/fs_notify.h| 10 ++
gio/hurd/ghurdfilemonitor.c | 269
r = linkat(fd, "", AT_FDCWD, "/tmp/hello.txt", AT_EMPTY_PATH);
if (r < 0)
error(1, errno, "linkat");
}
After running the latter, /tmp/hello.txt should appear, owned by $(id -u):24,
(where 24 is the group 'cdrom' on my system, chosen arbi
This adds a special SHM_ANON value that can be passed into shm_open ()
in place of a name. When called in this way, shm_open () will create a
new anonymous shared memory file. The file will be created in the same
way that other shared memory files are created (i.e., under /dev/shm/),
except that it
Instead of __file_name_lookup_at delegating to __file_name_lookup
in simple cases, make __file_name_lookup_at deal with both cases, and
have __file_name_lookup simply wrap __file_name_lookup_at.
---
hurd/hurdlookup.c | 10 ++
hurd/lookup-at.c | 51 -
This is a flag that causes open () to create a new, unnamed file in the
same filesystem as the given directory. The file descriptor can be
simply used in the creating process as a temporary file, or shared with
children processes via fork (), or sent over a Unix socket. The file can
be left anonymo
On Mon, Dec 19, 2022, 03:48 Flavio Cruz wrote:
> a full system boostrap like how it is done in
> https://github.com/flavioc/cross-hurd.
Thank you for that repo! It has been very helpful for me when I tried
to build my own cross-toolchain.
Sergey
On Tue, Jan 24, 2023 at 8:23 PM Ryan Raymond wrote:
>
> Hello,
> I was reading the install instructions and I saw that they were incomplete.
> The system can't build right now I guess, but I wanted to fix that. I was
> wondering if the last person who built could point me in the general
> direc
On Wed, Jan 25, 2023 at 4:10 AM Samuel Thibault wrote:
> Hello,
Hi!
> It'd be useful that all these small cross-compilation howtos here and
> there be merged into the corresponding wiki page where it belongs,
>
> ./toolchain/cross-gnu.mdwn
>
> https://darnassus.sceen.net/~hurd-web/toolchain/cros
> On Tue, Jan 24, 2023 at 7:59 PM Ryan Raymond wrote:
> Does anyone know what this is? The file "interrupt_S.h" doesn't exist, but
> many files refer to it. I checked the git log but there wasn't a record of
> the file ever existing.
This header in not checked into the Git repo, it is, as Flávi
On Wed, Jan 25, 2023 at 1:57 PM Sergey Bugaev wrote:
> [0]: Chained Rules (GNU make)
Arghhh, Edge is at it again! I meant:
[0]: https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html
A humble meta-suggestion, if I might:
it would be nicer if you explicitly specified what source tree this
patch is for, for instance: [PATCH glibc] or [PATCH gnumach] instead
of just [PATCH]. (There is the --subject-prefix option in git
format-patch for this.)
This is typically easy to infer by l
On Mon, Jan 30, 2023 at 2:25 AM Samuel Thibault wrote:
>
> Hello,
>
> Sergey Bugaev, le lun. 12 déc. 2022 14:46:35 +0300, a ecrit:
> > diff --git a/sysdeps/mach/hurd/bits/fcntl.h b/sysdeps/mach/hurd/bits/fcntl.h
> > index 17dcb384..b898a0c5 100644
> > --- a/
Changes since v1:
- Add forgotten Signed-off-by
- Fix a typo (thanks Amos!)
- Drop the separate __O_TMPFILE definition
Re-tested on i686-gnu, still works.
Sergey Bugaev (3):
hurd: Consolidate file_name_lookup implementation
hurd: Implement O_TMPFILE
hurd: Implement SHM_ANON
hurd
Instead of __file_name_lookup_at delegating to __file_name_lookup
in simple cases, make __file_name_lookup_at deal with both cases, and
have __file_name_lookup simply wrap __file_name_lookup_at.
Signed-off-by: Sergey Bugaev
---
hurd/hurdlookup.c | 10 ++
hurd/lookup-at.c | 51
API.
O_TMPFILE was initially introduced by Linux. This implementation is
intended to be compatible with the Linux implementation, except that the
O_EXCL flag is not given the special meaning when used together with
O_TMPFILE, unlike on Linux.
Signed-off-by: Sergey Bugaev
---
hurd/
it is not given a name and therefore cannot be reached from
the file system, nor by other calls to shm_open (). This is accomplished
by utilizing O_TMPFILE.
This is intended to be compatible with FreeBSD's API of the same name.
Signed-off-by: Sergey Bugaev
---
posix/shm-direct
On Tue, Jan 31, 2023 at 9:08 AM Flavio Cruz wrote:
>
> When generating stubs, Mig will will take the vm_size_array_t and define the
> input request struct using rpc_vm_size_t since the size is variable. This
> will turn cause a mismatch
> between types (vm_size_t* vs rpc_vm_size_t*). We could als
Replying to myself after looking at the definition:
On Tue, Jan 31, 2023 at 12:06 PM Sergey Bugaev wrote:
>
> I understand they are related to the x64 bringup, and possibly to
> running 32-bit userland on a 64-bit kernel (or to support for 32-bit
> tasks communicating with 64-bit ta
On Tue, Jan 31, 2023 at 10:54 PM Luca wrote:
> I think it would be possible to handle both a 32-bit and a
> 64-bit userspace at the same time, as in XNU, but we'd need also
> user-space support if we want to integrate 32-bit and 64-bit tasks, and
> this seems a bit more complicated to me (although
Hello!
I came across this glibc patch [0] from Svante Signell that is
apparently not upstream, but shipped in Debian. I have also seen this
wiki page [1]. So here is a braindump of how that patch is broken and
why we cannot easily fix it.
[0]:
https://salsa.debian.org/glibc-team/glibc/-/blob/sid
On Wed, Feb 8, 2023 at 2:45 PM Samuel Thibault wrote:
> Actually, no: the rustc compiler itself cross-builds fine, it's libstd
> that needs porting, and the gcc front-end uses the rustc libstd too.
Is planning to use the upstream libstd, rather. Currently GCC Rust
cannot even build libcore yet.
Forgot to mention another interesting possibility:
clearly, the auth_{user,server}_authenticate () API has been designed
with io_reauth in mind. The newport being passed from the server to
the client fits the io_reauth model very well, the newport being a
newly authenticated port to the same perop
Hello!
Seeing that the patches to make binutils and GCC support --target=x86_64-gnu
have recently landed, I thought it would be interesting to try to configure
glibc with --host=x86_64-gnu and see what breaks.
To make things work at least somewhat, I've tried to put some basic directory
& Implies
..so that it can match the alignment of pthread_mutex_t on x86_64-gnu.
This likely breaks many other arches (if not all of them), though.
Signed-off-by: Sergey Bugaev
---
sysdeps/pthread/threads.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sysdeps/pthread/threads.h b
inter.
But if you start with an integer (such as mach_port_t), then cast it to
a longer pointer (void *), and then back to a shorter integer, you are
fine. To keep GCC happy, cast through an intermediary uintptr_t, which
is always the same size as a pointer.
Signed-off-by: Sergey Bugaev
---
htl/cth
tls.h in particular is very unfinished.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/x86_64/static-start.S | 27 +++
sysdeps/mach/hurd/x86_64/tls.h | 182
sysdeps/mach/hurd/x86_64/tlsdesc.sym| 22 +++
sysdeps/x86_64/htl/bits/pthreadtypes
Since GNU Mach commit d30481122a5d24ad6b921062f93b9172ef922fc3,
i386/machine_types.defs defines types based on defined(__x86_64__).
Supressing the built-in macro definitions will now result in the wrong
type being silently selected.
-undef was initially introduced in commit
78b6a7665db7b2eae367e17
'sem' is the opaque 'sem_t', 'isem' is the actual 'struct new_sem'.
Signed-off-by: Sergey Bugaev
---
sysdeps/htl/sem-timedwait.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sysdeps/htl/sem-timedwait.c b/sysdeps/htl/
Make the code flow more linear using early returns where possible. This
makes it so much easier to reason about what runs on error / successful
code paths.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/readlinkat.c | 55 --
1 file changed, 32 insertions
Signed-off-by: Sergey Bugaev
---
mach/Makefile | 3 ++-
sysdeps/mach/configure| 6 +++---
sysdeps/mach/configure.ac | 6 +++---
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/mach/Makefile b/mach/Makefile
index 39358fdb..f2fdd7da 100644
--- a/mach/Makefile
+++ b
...not sizeof(int). This appears to be required on x86_64.
PLEASE NOTE: There is now a patch from Flavio Cruz ("Make MIG work for
pure 64 bit kernel and userland") that appears to tackle this same issue
(and more). Most likely this simplistic patch should be dropped in favor
of the one from Flavio
This does not seem like it is supposed to return negative error codes.
Signed-off-by: Sergey Bugaev
---
hurd/xattr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hurd/xattr.c b/hurd/xattr.c
index 48914bcf..5a0fc263 100644
--- a/hurd/xattr.c
+++ b/hurd/xattr.c
@@ -68,7
And move pt-setup.c to the generic x86 tree.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/Implies | 1 +
sysdeps/mach/hurd/{i386 => x86}/htl/pt-setup.c | 4 ++--
sysdeps/mach/hurd/x86_64/Implies | 2 ++
sysdeps/mach/hurd/x86_64/htl/Implies
It has been decided that on x86_64, mach_msg_type_number_t stays 32-bit.
Therefore, it's not possible to use mach_msg_type_number_t
interchangeably with size_t, in particular this breaks when a pointer to
a variable is passed to a MIG routine.
Signed-off-by: Sergey Bugaev
---
hurd/hurdio
---
hurd/tioctl.defs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hurd/tioctl.defs b/hurd/tioctl.defs
index 905a4a38..a04f5ae4 100644
--- a/hurd/tioctl.defs
+++ b/hurd/tioctl.defs
@@ -34,9 +34,9 @@ import ; /* XXX */
/* These are the pieces of a struct termios as spec
On Sun, Feb 12, 2023 at 6:00 PM Samuel Thibault wrote:
> We don't need these to be 64bits, 32bit will be completely large enough.
>
> Which issue did you actually encounter?
Well, these MIG definitions need to match the ones in C/glibc. In
hurd/ioctl_types.h (in the Hurd tree) there is
typedef t
> > # Translate GNU names for CPUs into the names used in Mach header files.
> > -mach-machine = $(patsubst powerpc,ppc,$(base-machine))
> > +mach-machine := $(patsubst powerpc,ppc,$(base-machine))
> > +mach-machine := $(patsubst x86_64,i386,$(mach-machine))
>
> Mmm, no, it's not actually a transl
On Sun, Feb 12, 2023 at 6:18 PM Samuel Thibault wrote:
> I'd say rather make pthread_mutex_t aligned on long int, so we can
> possibly in the future put some pointers in it without breaking the ABI.
I honestly have 0 idea how it is not 8-aligned right now (nor how its
size is 32 and not like 56),
On Sun, Feb 12, 2023 at 6:46 PM Samuel Thibault wrote:
>
> Sergey Bugaev, le dim. 12 févr. 2023 18:38:03 +0300, a ecrit:
> > Since mach/machine/syscall_sw.h is the i386 version on x86_64 (or --
> > is it not supposed to be?)
>
> Nobody yet decided that the system call int
On Sun, Feb 12, 2023 at 7:01 PM Luca wrote:
> It seems XNU's mig [0] always sets the alignment to natural_t (=4) with
> a #pragma... I still have to understand how they handle these issues.
Please note that XNU uses "untyped messaging", and Apple's version of
MIG is "untyped MIG". They don't have
ort has its own bits/termios.h, is it fine to
just modify the generic one inline, rather than creating a
Hurd-specific version? The patch for that follows.
Sergey
-- >8 --
>From 625b774141823a8f504cce8a92b9f45f5e6f050f Mon Sep 17 00:00:00 2001
From: Sergey Bugaev
Date: Sun, 12 Feb 2023 19:08:5
On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault wrote:
>
> Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ecrit:
> > We should not need a getter routine, because one can simply inspect the
> > target
> > thread's state (unless, again, I misunderstand things h
On Sun, Feb 12, 2023 at 7:36 PM Samuel Thibault wrote:
>
> Sergey Bugaev, le dim. 12 févr. 2023 19:25:11 +0300, a ecrit:
> > On Sun, Feb 12, 2023 at 7:11 PM Samuel Thibault
> > wrote:
> > > Sergey Bugaev, le dim. 12 févr. 2023 14:10:42 +0300, a ecrit:
> > > &
On Sun, Feb 12, 2023 at 8:02 PM Samuel Thibault wrote:
> I'd rather make it a separate state content, like we have a separate
> i386_DEBUG_STATE content.
>
> (And thus no need for a new RPC).
Makes sense to me! 👍
Sergey
On Sun, Feb 12, 2023 at 9:26 PM Flavio Cruz wrote:
>
> This is required to implement ptrace.
> ---
> i386/i386/pcb.c| 42 +-
> i386/include/mach/i386/thread_status.h | 28 +
> 2 files changed, 69 insertions(+), 1 deletion(-)
>
> diff
This line in configure logs has always bugged me; of course GNU MIG
supports "retcode" (as in, does not report an error upon seeing it).
Today I happened to have journalctl -f opened at the time I ran
../configure, and accidentally found out why this happens:
kernel: traps: x86_64-gnu-migc[177175]
This macro from Mach headers conflicts with how
sysdeps/x86_64/multiarch/strcmp-sse2.S expects it to be defined.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/sysdep.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/sysdeps/mach/sysdep.h b/sysdeps/mach/sysdep.h
index fe26bcb3..1c869f5c
* instead?
Sergey Bugaev (3):
hurd: i386 TLS tweaks
mach: undef ENTRY2
htl: Make pthread_mutex_t pointer-aligned
.../htl/bits/types/struct___pthread_mutex.h | 13 +++--
sysdeps/mach/hurd/i386/tls.h | 48 ++-
sysdeps/mach/sysdep.h
This is for future-proofing. On i386, it is 4-byte aligned anyway, but
on x86_64, we want it 8-byte aligned, not 4-byte aligned.
Signed-off-by: Sergey Bugaev
---
.../hurd/htl/bits/types/struct___pthread_mutex.h| 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a
fsets that are a part of ABI are what
we expect them to be.
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/i386/tls.h | 48 ++--
1 file changed, 35 insertions(+), 13 deletions(-)
diff --git a/sysdeps/mach/hurd/i386/tls.h b/sysdeps/mach/hurd/i386/tls.h
On Tue, Feb 14, 2023 at 10:20 PM Samuel Thibault
wrote:
> > > +#if defined(__x86_64__) && !defined(USER32)
> > > + uint64_tefl;
> >
> > Should this not be 'rfl' (for 'rflags')?
>
> In both cases, that would make the gnumach code have to distinguish the
> two names, in the debugger an
On Wed, Feb 15, 2023 at 9:17 AM Flavio Cruz wrote:
>
> Moved thread_state.h to x86 directory since we only need to customize
> those 3 definitions.
No, that won't be enough. We also need to customize those
MACHINE_THREAD_STATE_FLAVOR definitions to include the potential new
i386_FSGS_BASE_STATE t
On Wed, Feb 15, 2023 at 8:51 AM Flávio Cruz wrote:
>> This would be trivial to fix by flipping the line order in aclocal.m4
>> (in each repo that vendors it...), but maybe MIG should actually
>> support this? What does it need the subsystem for anyway, when parsing
>> type defs? Apple's MIG suppor
On Thu, Feb 16, 2023 at 10:27 AM Flávio Cruz wrote:
>> On that note: right now, MIG-generated stubs are broken on x86_64. MIG
>> built from master complains about time_value_t (which GCC says is 16
>> bytes-, but MIG expects to be 12 bytes- sized). If I set
>> desired_max_alignof to 8 (which it mu
> With this layout alignment issues seem much simpler to solve, basically
> we can leave the compiler find the best combination for the second part
> of the message, and if the user/kernel archs are the same, the struct
> will have the same layout in the sending and receiving mig stubs.
To be clea
On Fri, Feb 17, 2023 at 9:02 AM Flávio Cruz wrote:
> Thanks for the instructions. I discovered that mach_msg_type_long_t does not
> align to 8 bytes so it also needs a bit of padding just like mach_msg_type_t.
> See my last patch. I was able to compile most of the glibc and all the stubs
> afte
Hello,
here's some more work on the x86_64-gnu glibc port. Large parts of glibc
(almost all of it?) builds, in particular mach/subdir_lib builds cleanly.
Patch 6 is really unrelated to the rest of the changes, it's just a small thing
that I've noticed while single-stepping through glibc startup,
And make it a bit more 64-bit ready. This is in preparation to moving this
file into x86/
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/i386/init-first.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/sysdeps/mach/hurd/i386/init-first.c
b
Signed-off-by: Sergey Bugaev
---
sysdeps/mach/hurd/{i386 => x86}/init-first.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
rename sysdeps/mach/hurd/{i386 => x86}/init-first.c (96%)
diff --git a/sysdeps/mach/hurd/i386/init-first.c
b/sysdeps/mach/hurd/x8
101 - 200 of 850 matches
Mail list logo
