On 2025-02-11 14:37, Yuqian Yang wrote:
This patch still uses a PATH_MAX stuck on Hurd. But it at least
can unblock your other works.
PATH_MAX stub.
Thanks.
--
Yuqian Yang
Hello,
On 2025-02-08 09:05, Sam Hartman wrote:
* I work with the porter and review the patches.
Thanks.
I have put 2 patches in attachment. `hurd-fix.patch` is the
real patch for fixing problems on Hurd. You have to put this
to `debian/patches` manually and change the `series`.
`hurd
Samuel Thibault, le lun. 10 févr. 2025 13:57:46 +0100, a ecrit:
> Flavio Cruz, le dim. 09 févr. 2025 22:36:30 -0500, a ecrit:
> > * pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
> > extern since they are used in another module (icmp.c) and shouldn't be
> > removed.
>
> >
Flavio Cruz, le dim. 09 févr. 2025 22:36:30 -0500, a ecrit:
> * pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
> extern since they are used in another module (icmp.c) and shouldn't be
> removed.
> diff --git a/pfinet/linux-src/net/ipv4/tcp_ipv4.c
> b/pfinet/linux-src/net
Hello,
I did not see this mail. And I don't know why. It is not easy to
communicate when emails are lost. Same problems with other emails too.
And btw: The OS is not HURD or hurd, it's either GNU/Hurd or just Hurd.
Best regards,
Svante Signell
To: svante.sign...@gmail.com,
* libshouldbeinlibc/lcm.c: make gcd static since it's not exposed as a
symbol.
* pfinet/linux-src/net/ipv4/{tcp,udp}_ipv4.c: mark lookup functions as
extern since they are used in another module (icmp.c) and shouldn't be
removed.
* term/munge.c: make poutput static since it's not exposed as a
On 2025-02-07 23:51, Samuel Thibault wrote:
Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit:
I know this is due to the way of our kernel to handle file and memory.
Do we have a good way to fix this,
Not a trivial way. It'd need adding names to the kernel map entries,
and
setting t
On Fri, Feb 7, 2025 at 6:51 PM Samuel Thibault wrote:
> Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit:
> > I know this is due to the way of our kernel to handle file and memory.
> > Do we have a good way to fix this,
>
> Not a trivial way. It'd need adding names to the kernel map entr
Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit:
> I know this is due to the way of our kernel to handle file and memory.
> Do we have a good way to fix this,
Not a trivial way. It'd need adding names to the kernel map entries, and
setting them from mmap() and such functions that map fi
When I fixed abseil[1] for Hurd, I disabled its debugging feature
of finding the symbol of current functions or any other symbols.[2]
It does not work on Hurd and its unit tests failed. It can be safely
disabled and does not affect other functions of lib just like
platforms that do not support it
idem, and Win32s system being
> used (Windows 3.1)
> haikuHaiku version of Vim.
> hangul_input Compiled with Hangul input support. |hangul|
> hpux HP-UX version of Vim.
> +hurd Hurd version of Vim
> iconv
support. |hangul|
hpux HP-UX version of Vim.
+hurd Hurd version of Vim
iconv Can use iconv() for conversion.
insert_expand Compiled with support for CTRL-X expansion commands in
Insert mode. (always true)
diff
On Mon, Feb 03, 2025 at 04:41:13PM +0800, Zhaoming Luo wrote:
>
> Zhaoming Luo (1):
> Exclude GNU/Hurd from has('bsd') feature
>
> src/evalfunc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
As it seems not to be the correct way of submitting pa
GNU/Hurd, like Mac OS X, is a BSD-based system. It should exclude
has('bsd') feature just like what Mac OS X does. The __GNU__ pre-defined
macro indicates it's compiling for GNU/Hurd.
Signed-off-by: Zhaoming Luo
---
src/evalfunc.c | 2 +-
1 file changed, 1 insertion(+), 1 de
Hi,
I'm not sure if I should add a feature (like has('hurd')) for GNU/Hurd,
and if it should be in this patch or in a seperate patch.
Zhaoming Luo (1):
Exclude GNU/Hurd from has('bsd') feature
src/evalfunc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.47.2
This port extends the existing i686 port to support x86_64 by reusing
existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs.
The signal code is very similar to i686, except the
Applied, thanks!
Yuqian Yang, le mer. 29 janv. 2025 23:14:31 +0800, a ecrit:
> Many people are familiar with VirtualBox, or using OS other than
> GNU/Linux. VirtualBox gives them more opportunity to play with Hurd.
> ---
> hurd/running/virtualbox.mdwn | 19 +--
&
Many people are familiar with VirtualBox, or using OS other than
GNU/Linux. VirtualBox gives them more opportunity to play with Hurd.
---
hurd/running/virtualbox.mdwn | 19 +--
index.mdwn | 2 ++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a
Applied, thanks!
dnie...@gmail.com, le lun. 27 janv. 2025 01:17:33 +, a ecrit:
> From: Diego Nieto Cid
>
> Hello,
>
> On Sun, Jan 26, 2025 at 10:18:03PM +0100, Samuel Thibault wrote:
> >
> > dnie...@gmail.com, le ven. 10 janv. 2025 23:52:28 +, a ecrit:
> > > --- a/procfs/rootdir.c
> > >
From: Diego Nieto Cid
Hello,
On Sun, Jan 26, 2025 at 10:18:03PM +0100, Samuel Thibault wrote:
>
> dnie...@gmail.com, le ven. 10 janv. 2025 23:52:28 +, a ecrit:
> > --- a/procfs/rootdir.c
> > +
> > + m = open_memstream(contents, (size_t *) contents_len);
>
> Please mind the GNU coding style
Sergey Bugaev, le lun. 27 janv. 2025 00:25:15 +0300, a ecrit:
> > > +out:
> > > + flcose(m);
> >
> > You didn't try to compile it ;)
>
> I suppose that's not easy for Diego to do, given the state of aarch64-gnu :)
Sure, but he can comment the very few really-arm64-specific lines and
try to build
On Mon, Jan 27, 2025 at 12:18 AM Samuel Thibault
wrote:
> > + err = aarch64_get_hwcaps(mach_host_self(), &caps, &mdir, &revdir);
> > + if (err)
> > +goto out;
> > +
> > + implementer = (mdir & 0xff00) >> 24;
> > + variant = (mdir & 0x00f0) >> 20;
> > + architecture = (mdir &
Hello,
Thanks for working on it :)
Sorry for the delay,
dnie...@gmail.com, le ven. 10 janv. 2025 23:52:28 +, a ecrit:
> --- a/procfs/rootdir.c
> +++ b/procfs/rootdir.c
> @@ -38,6 +38,12 @@
> #include "procfs_dir.h"
> #include "main.h"
> #include
> +#if defined (__x86_64__) || defined (_
Hi Paolo,
The hardware that's supported by GNU/Hurd is described in the following
link:
https://darnassus.sceen.net/~hurd-web/faq/drivers/
Please feel free to ask questions.
Best wishes,
Zhaoming
Hi,
I would like to try to add a wiki page introducing how to set up a more
friendly development environment in hurd vm. That wiki page will
introduce some plugins that would be useful while reading source code,
like `any-jump.vim`, and Emacs' `dumb-jump` suggested by gnucode (thanks
gn
+140,7 @@ mkdev() {
# link for compatibility with Linux.
cmd ln -f -s random $I;;
null)
- st $I root 666 c /hurd/null;;
+ st $I root 666 c /hurd/null --rdev=1,3;;
full)
st $I root 666 c /hurd/null --full;;
zero)
diff --git a/trans/null.c b/trans
Hi,
For quite a while I've been using Hurd from 2022 [1] for testing
various GNU packages, and it's been quite stable.
This week, Samuel invited me to try newer Hurd versions [2].
So, I tried
- Hurd/i386 from June 2023 [3]
- Hurd/x86_64 from November 2024 [4].
In all cases, I do th
On Sun, Jan 12, 2025 at 10:48 PM Samuel Thibault
wrote:
> Does the posted patch look fine to you?
It does, so:
Acked-by: Sergey Bugaev
I'll test it some time later when I get around to doing more
aarch64-gnu hacking :|
Sergey
exim4 also needs to be upgraded to the rebuilt version 4.98-3+hurd.1
Samuel Thibault, le lun. 13 janv. 2025 03:00:50 +0100, a ecrit:
> Hello,
>
> The CMSG_DATA() fix requires bumping the ABI. Since it's still really
> at early stage, I don't plan to make a compatibility lay
3, the
old openssh will break. I have put a Breaks so people don't accidentally
end up there. But installing the rebuilt openssh will not currently
upgrade libc0.3, so be sure to upgrade both packages on your hurd-amd64
system.
So basically, after next "unreleased" mirror pulse (~7:30 U
Sergey Bugaev, le jeu. 09 janv. 2025 18:36:57 +0300, a ecrit:
> On Thu, Jan 9, 2025 at 6:18 PM Jessica Clarke wrote:
> > On 9 Jan 2025, at 15:12, Diego Nieto Cid wrote:
> > > Looking at the types.h header, I see there are HWCAP2_* definitions for
> > > bits above 32. Since hwcaps_t is an uint32_t
Zhaoming Luo, le dim. 12 janv. 2025 20:17:31 +0800, a ecrit:
> > > -libstore.so-LDLIBS += $(PARTED_LIBS) -ldl
> > > +ifeq ($(EXCLUDE_PARTED), 1)
> > > + libstore-noparted.so-LDLIBS += -ldl
> > > +else
> > > + libstore.so-LDLIBS += $(PARTED_LIBS) -ldl
> >
> > Better use
> >
> > $(libname).so-LD
On Sat, Jan 11, 2025 at 11:39:46AM +0100, Samuel Thibault wrote:
> Hello,
Thanks for the review.
>
> Zhaoming Luo, le sam. 11 janv. 2025 12:56:33 +0800, a ecrit:
> > diff --git a/libstore/Makefile b/libstore/Makefile
> > index c7af958b..d0f06450 100644
> > --- a/libstore/Makefile
> > +++ b/libst
Applied, thanks!
Damien Zammit via Bug reports for the GNU Hurd, le sam. 11 janv. 2025 08:21:50
+, a ecrit:
> The usb stack also uses SCSI emulation for usb mass storage.
>
> ---
> rumpdisk/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --gi
Hello,
Zhaoming Luo, le sam. 11 janv. 2025 12:56:33 +0800, a ecrit:
> diff --git a/libstore/Makefile b/libstore/Makefile
> index c7af958b..d0f06450 100644
> --- a/libstore/Makefile
> +++ b/libstore/Makefile
> @@ -20,10 +20,17 @@
> # along with this program; if not, write to the Free Software
>
The usb stack also uses SCSI emulation for usb mass storage.
---
rumpdisk/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rumpdisk/Makefile b/rumpdisk/Makefile
index e7f53511..cbe93845 100644
--- a/rumpdisk/Makefile
+++ b/rumpdisk/Makefile
@@ -17,7 +17,7 @@
RUMPLIB
\
libbpf \
libmachdev \
libirqhelp \
+ libstore-noparted \
# Hurd programs
prog-subdirs = auth proc exec term \
diff --git a/libstore-noparted/Makefile b/libstore-noparted/Makefile
new file mode 100644
index ..b04b3350
--- /dev/null
+++ b/libstore
.f8e38b71 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -33,6 +33,7 @@ lib-subdirs = libshouldbeinlibc libihash libiohelp libports
> \
> libbpf \
> libmachdev \
> libirqhelp \
> + libstore-noparted \
>
> # Hurd programs
>
libmachdev \
libirqhelp \
+ libstore-noparted \
# Hurd programs
prog-subdirs = auth proc exec term \
diff --git a/libstore-noparted/Makefile b/libstore-noparted/Makefile
new file mode 100644
index ..694218c1
--- /dev/null
+++ b/libstore-noparted/Makefile
@@ -0,0 +1,9 @@
+# U
Zhaoming Luo, le sam. 11 janv. 2025 09:47:35 +0800, a ecrit:
> On Thu, Jan 09, 2025 at 02:09:01PM +0100, Samuel Thibault wrote:
> > Hello,
> >
> > Zhaoming Luo, le jeu. 09 janv. 2025 20:58:22 +0800, a ecrit:
> > > The library can be compiled using the following command in the build/
> > > director
> > 2 files changed, 98 insertions(+)
> > create mode 100644 libstore-noparted/Makefile
> >
> > diff --git a/Makefile b/Makefile
> > index 9d9e33c3..f8e38b71 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -33,6 +33,7 @@ lib-subdirs
From: Diego Nieto Cid
Hello,
Sorry for the duplicate, I found a missing semicolon in the
unsupported architecture case. Now fixed.
Thanks,
Diego
-- >8 -- >8 -- >8 --
* procfs/rootdir.c: (rootdir_gc_cpuinfo) new function
(rootdir_entries) add entry for cpuinfo file
(cpuinfo_x86, cpu
From: Diego Nieto Cid
Hello,
This is a new version of the cpuinfo patch. I added some #ifdef to
include the cpuinfo.h or the march_aarch64 header accordingly.
I also attempted to implement a version of the content generation
function for aarch64 with the information in the link Sergey provided.
p libports \
libbpf \
libmachdev \
libirqhelp \
+ libstore-noparted \
# Hurd programs
prog-subdirs = auth proc exec term \
diff --git a/libstore-noparted/Makefile b/libstore-noparted/Makefile
new file mode 100644
index ..e803bdfb
--- /dev/
/Makefile b/Makefile
> > index 9d9e33c3..f8e38b71 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -33,6 +33,7 @@ lib-subdirs = libshouldbeinlibc libihash libiohelp
> > libports \
> > libbpf \
> > libmachdev \
> > libirqhelp \
On Thu, Jan 9, 2025 at 6:18 PM Jessica Clarke wrote:
> On 9 Jan 2025, at 15:12, Diego Nieto Cid wrote:
> > Looking at the types.h header, I see there are HWCAP2_* definitions for
> > bits above 32. Since hwcaps_t is an uint32_t and the defs file claims to
> > return two values (I assume the first
On 9 Jan 2025, at 15:12, Diego Nieto Cid wrote:
>
> Hi,
>
> On Thu, Jan 09, 2025 at 11:51:27AM +0300, Sergey Bugaev wrote:
>>
>> "Implementer", "architecture", "variant", "part", "revision" come from
>> midr/revidr [0], and "features" are hwcap names. These are privileged
>> registers that only
Hi,
On Thu, Jan 09, 2025 at 11:51:27AM +0300, Sergey Bugaev wrote:
>
> "Implementer", "architecture", "variant", "part", "revision" come from
> midr/revidr [0], and "features" are hwcap names. These are privileged
> registers that only EL1 can read, but on AArch64 gnumach, their values
> are obta
Sergey Bugaev, le jeu. 09 janv. 2025 16:36:03 +0300, a ecrit:
> On Thu, Jan 9, 2025 at 4:09 PM Samuel Thibault
> wrote:
> > > make libstore-noparted
> > > ```
> > >
> > > This file is the same as libstore/Makefile except a few modifications so
> > > it can use the source files from libstore/ and
On Thu, Jan 9, 2025 at 4:09 PM Samuel Thibault wrote:
> > make libstore-noparted
> > ```
> >
> > This file is the same as libstore/Makefile except a few modifications so
> > it can use the source files from libstore/ and build a libstore with
> > libparted module.
>
> Thanks for working on it. AIU
t;
> diff --git a/Makefile b/Makefile
> index 9d9e33c3..f8e38b71 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -33,6 +33,7 @@ lib-subdirs = libshouldbeinlibc libihash libiohelp libports
> \
> libbpf \
> libmachdev \
> libirqhelp \
> +
= libshouldbeinlibc libihash libiohelp libports \
libbpf \
libmachdev \
libirqhelp \
+ libstore-noparted \
# Hurd programs
prog-subdirs = auth proc exec term \
diff --git a/libstore-noparted/Makefile b/libstore-noparted/Makefile
new file mode
Hi,
On Thu, Jan 9, 2025 at 1:42 AM Luca wrote:
> >> maybe this can be already made arch-specific.
> >>
> >
> > Hmm, maybe. As is it only makes sense for x86 based architectures.
>
> There was some work from Sergey towards porting to aarch64, I guess
> curre
roc/cpuinfo didn't tell me what bit to look for in each
case.
From a quick check it seems the names on the publicly available Intel
manuals are the same as Linux procinfo, (just uppercase), it might be
worth to check what other OSs use, like some BSDs, if they have such file.
About licensin
quot;fma", "cx16", "xtpr", "pdcm",
> > +NULL, "pcid", "dca", "sse4_1", "sse4_2", "x2apic", "movbe", "popcnt",
> > + "tsc_deadline", "aes_ni", "xsave&qu
.
There remains a lot of fields that I haven't covered yet and
SMP is not supported (in alignment with the output of /proc/stat).
But it seems to help in the porting of libgtop to GNU/Hurd, which I
started from a copy of Linux implementation.
Beside that, I probably need to cache the CPUID pro
d yet and
SMP is not supported (in alignment with the output of /proc/stat).
But it seems to help in the porting of libgtop to GNU/Hurd, which I
started from a copy of Linux implementation.
Beside that, I probably need to cache the CPUID provided information
as I don't think it would change
Thanks for reviewing.
On 1/3/25 6:52 PM, Sergey Bugaev wrote:
On Fri, Jan 3, 2025 at 1:42 PM Zhaoming Luo wrote:
hurd: Add CLOCK_MONOTONIC case in clock_gettime()
Nitpick: the prefix should be "mach:" instead of "hurd:".
In theory, there could be other targets that a
On Fri, Jan 3, 2025 at 1:42 PM Zhaoming Luo wrote:
> hurd: Add CLOCK_MONOTONIC case in clock_gettime()
Nitpick: the prefix should be "mach:" instead of "hurd:".
In theory, there could be other targets that also run on Mach, and
sysdeps/mach/clock_gettime.c is only
Compared with v1: follow the following emails suggestions:
https://mail.gnu.org/archive/html/bug-hurd/2025-01/msg00011.html
https://mail.gnu.org/archive/html/bug-hurd/2025-01/msg2.html
https://mail.gnu.org/archive/html/bug-hurd/2025-01/msg00019.html
Is there anything I need to add before
hurd: Add CLOCK_MONOTONIC case in clock_gettime()
The Mach RPC host_get_uptime64() is implemented. It returns the elapsed time
value since bootup. See
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=fc494bfe3fb6363e1077dc035eb119970d84a9d1
In this patch, the RPC is used to
On Fri, Jan 3, 2025 at 5:32 AM Zhaoming Luo wrote:
> > in the latter case, you should get MIG_BAD_ID from the kernel, so you
> > can detect that.
> What's the best way to handle the MIG_BAD_ID case. I tried perror(NULL)
> but it gave my output '(ipc/mig) bad request message ID'. To be honest I
> d
On Wed, Jan 01, 2025 at 10:11:24PM +0100, Samuel Thibault wrote:
> Diego Nieto Cid, le mer. 01 janv. 2025 20:07:04 +, a ecrit:
> > On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > > > /* Structure used for storage of ancillary data object information.
> > > > */
> > >
On 1/1/25 5:50 PM, Sergey Bugaev wrote:
Happy New Year!
Happy New Year
On Wed, Jan 1, 2025 at 12:25 PM Zhaoming Luo wrote:
---
sysdeps/mach/clock_gettime.c | 12
1 file changed, 12 insertions(+)
diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_gettime.c
index
;
> > Suggested-by: Diego Nieto Cid
> > ---
> > bits/socket.h | 12
> > sysdeps/mach/hurd/bits/socket.h | 12
> > 2 files changed, 8 insertions(+), 16 deletions(-)
> >
> > diff --git a/bits/socket.h b/bits/socke
Hello,
Sergey Bugaev, le mer. 01 janv. 2025 12:50:48 +0300, a ecrit:
> On Wed, Jan 1, 2025 at 12:25 PM Zhaoming Luo wrote:
> >
> > ---
> > sysdeps/mach/clock_gettime.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_g
ONIC.
Mmm, that website comment actually looks bogus: one can't assume that
CLOCK_MONOTONIC provides something that can be used to display actuall
wallclock time, which is subject to jumps.
I have dropped it.
> Does that refer to this one[1]?
>
> [0]: https://darnassus.sceen.net/~hu
Diego Nieto Cid, le mer. 01 janv. 2025 21:03:23 +, a ecrit:
> On Wed, Jan 01, 2025 at 08:07:04PM +, Diego Nieto Cid wrote:
> > On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > > >
> > > > /* Structure used for storage of ancillary data object information.
> > > >
Diego Nieto Cid, le mer. 01 janv. 2025 20:07:04 +, a ecrit:
> On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > > /* Structure used for storage of ancillary data object information.
> > > */
> > > struct cmsghdr
> > > {
> > > socklen_t cmsg_len;
On Wed, Jan 01, 2025 at 08:07:04PM +, Diego Nieto Cid wrote:
> On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> > >
> > > /* Structure used for storage of ancillary data object information.
> > > */
> > > struct cmsghdr
> > > {
> > > socklen_t cmsg_len
On Wed, Jan 01, 2025 at 06:51:47PM +0100, Samuel Thibault wrote:
> >
> > /* Structure used for storage of ancillary data object information. */
> > struct cmsghdr
> > {
> > socklen_t cmsg_len; /* Length of data in cmsg_data plus
> > length
> >
Diego Nieto Cid, le mar. 31 déc. 2024 20:48:08 +, a ecrit:
> On Tue, Dec 31, 2024 at 08:32:47PM +, Diego Nieto Cid wrote:
> >
> > Adding the following line to the program:
> >
> > printf("cmsghdr: %lu\n", sizeof (struct cmsghdr));
> >
&g
On 1/1/25 5:51 PM, Zhaoming Luo wrote:
---
sysdeps/mach/clock_gettime.c | 12
1 file changed, 12 insertions(+)
The website[0] mentions making `gettimeofday()` use the CLOCK_MONOTONIC.
Does that refer to this one[1]?
[0]: https://darnassus.sceen.net/~hurd-web/open_issues
Happy New Year!
On Wed, Jan 1, 2025 at 12:25 PM Zhaoming Luo wrote:
>
> ---
> sysdeps/mach/clock_gettime.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_gettime.c
> index 6fffad39f5..22faf85730 100644
> --- a/sysdeps/mach
---
sysdeps/mach/clock_gettime.c | 12
1 file changed, 12 insertions(+)
diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_gettime.c
index 6fffad39f5..22faf85730 100644
--- a/sysdeps/mach/clock_gettime.c
+++ b/sysdeps/mach/clock_gettime.c
@@ -31,6 +31,18 @@ __clock_gettim
On Tue, Dec 31, 2024 at 08:32:47PM +, Diego Nieto Cid wrote:
>
> Adding the following line to the program:
>
> printf("cmsghdr: %lu\n", sizeof (struct cmsghdr));
>
> shows 12 on Hurd and 16 on Linux. I think I'm closer :)
The only difference in the str
> output (or at least different from Linux).
>
> The attached program prints:
>
> cmsg: 0x101040a90; data: 0x101040a9c; hurd=0x101040a9c, linux=0x101040aa0
>
> data seems to be off by 4 bytes compared to linux output.
Adding the following line to the program:
printf(&
x101040a90; data: 0x101040a9c; hurd=0x101040a9c, linux=0x101040aa0
data seems to be off by 4 bytes compared to linux output.
#include
#include
int main(int argc, char **argv)
{
size_t ucred = 12;
printf("ucred: %lu\n", ucred);
printf("CMS_LEN(ucred): %lu\n", CMSG_LEN(ucred)
Hi,
On Tue, Dec 31, 2024 at 02:52:53PM +0100, Samuel Thibault wrote:
>
> You should probably check precisely the difference between Linux and
> Hurd on these alignment questions at the various stages.
>
I placed a `g_message` call in `g_unix_credentials_message_deserialize` and
age->control_messages[i]));
>
This is OK, according to `man cmsg`
> Adding CMSG_ALIGN to the glib size check seems odd to be because in the
> linux case G_CREDENTIALS_NATIVE_SIZE is sizeof (struct ucred), which is
> 12bytes, so not 8byte-round and rounding would break the check on
of (struct ucred), which is
12bytes, so not 8byte-round and rounding would break the check on Linux.
You should probably check precisely the difference between Linux and
Hurd on these alignment questions at the various stages.
Samuel
Diego Nieto Cid, le mar. 31 déc. 2024 02:47:35 +, a ecrit:
> On Tue, Dec 31, 2024 at 02:02:53AM +, Diego Nieto Cid wrote:
> >
> > Here are the results for `hurd-amd64`:
> >
> > $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
> &
On Tue, Dec 31, 2024 at 02:02:53AM +, Diego Nieto Cid wrote:
>
> Here are the results for `hurd-amd64`:
>
> $ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
> -pthread cred_size.c -lgio-2.0 -lgobject-2.0 -lglib-2.0 \
>
ket.h
>
I wrote a little test-case (attached) that compares several sizes of the objects
involved in the GBus authentication.
Here are the results for `hurd-amd64`:
$ cc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-gnu/glib-2.0/include \
-pthread cred_size.c -lgio-2.0 -lgobjec
t; description [0] back in Feb 2023, and still got no response. So: ping?
>
> [0]: https://mail.gnu.org/archive/html/bug-hurd/2023-02/msg00054.html
>
> I have also written a PoC exploit for this, which authenticates itself
> to the D-Bus daemon as UID 0, even though it's not.
ind everyone that the SCM_CREDS
implementation, which is shipped as a Debian downstream patch, doesn't
actually verify the credentials. I have posted a more detailed
description [0] back in Feb 2023, and still got no response. So: ping?
[0]: https://mail.gnu.org/archive/html/bug-hurd/2023-02/msg00054.html
I have also written a PoC exploit for this, which authenticates itself
to the D-Bus daemon as UID 0, even though it's not.
Sergey
least the sender and the receiver don't seem to agree
> on the shape of struct cmsgcred.
I'll try to investigate. It's indeed weird that the sizes don't match as
both sender (test?) and receiver (ibus-daemon?) run on the same machine
and are compiled with the same headers :/
Possibly it's the position of cmcred_groups that gets aligned, but I
don't see why. At least the sender and the receiver don't seem to agree
on the shape of struct cmsgcred.
> Two patches to the test runner needs to be applied for hurd-amd64[2]:
>
> * add t64 suffix to libgt
ction g_unix_credentials_message_deserialize (which
can be seen here[1]).
It seems to be some structure size issue on amd64 (i386 tests don't fail)
regarding
SCM_CREDS implementation. But I couldn't debug the test because they are run
from
complicated shell scripts :(
Two patches to the test runner needs to be a
Applied, thanks!
Damien Zammit via Bug reports for the GNU Hurd, le sam. 28 déc. 2024 07:35:52
+, a ecrit:
> Proxied memory was not rounded up to page size, causing
> error with vm_map'ing the underlying memory.
>
> WARNING: Assumes pci memory resources are at least page
On 12/29/24 8:56 AM, Samuel Thibault wrote:
> Damien Zammit via Bug reports for the GNU Hurd, le sam. 28 déc. 2024 06:39:04
> +, a ecrit:
>> + setenv ("RUMP_MEMLIMIT", "16m", 1);
> Did you test this a lot?
>
> We'd probably want to disable rump-
Hello,
Damien Zammit via Bug reports for the GNU Hurd, le sam. 28 déc. 2024 06:39:04
+, a ecrit:
> + setenv ("RUMP_MEMLIMIT", "16m", 1);
Did you test this a lot?
We'd probably want to disable rump-side caching rather than putting
pressure on it.
Samuel
Applied, thanks!
Damien Zammit via Bug reports for the GNU Hurd, le sam. 28 déc. 2024 06:38:41
+, a ecrit:
> ---
> rumpdisk/block-rump.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c
> index cd7af494..8a3a4
Applied, thanks!
Damien Zammit via Bug reports for the GNU Hurd, le sam. 28 déc. 2024 07:35:32
+, a ecrit:
> Return positive error code when return value indicates error.
>
> ---
> acpi/acpi-ops.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --gi
Proxied memory was not rounded up to page size, causing
error with vm_map'ing the underlying memory.
WARNING: Assumes pci memory resources are at least page aligned.
If not, this will expose part of next resource to userspace.
---
pci-arbiter/netfs_impl.c | 8 +++-
1 file changed, 7 inserti
Return positive error code when return value indicates error.
---
acpi/acpi-ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/acpi/acpi-ops.c b/acpi/acpi-ops.c
index 47f7e3d2..16d96e71 100644
--- a/acpi/acpi-ops.c
+++ b/acpi/acpi-ops.c
@@ -84,7 +84,7 @@ S_acpi_get_pci_irq
On Sat, Dec 28, 2024 at 9:38 AM Damien Zammit via Bug reports for the
GNU Hurd wrote:
>
> Proxied memory was not rounded up to page size, causing
> error with vm_map'ing the underlying memory.
>
> WARNING: Could be security risk if assumption is incorrect:
> Assumes
---
rumpdisk/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/rumpdisk/main.c b/rumpdisk/main.c
index ca166274..ca9deea1 100644
--- a/rumpdisk/main.c
+++ b/rumpdisk/main.c
@@ -123,6 +123,8 @@ main (int argc, char **argv)
setenv ("RUMP_NCPU", "1", 1);
setenv ("RUMP_VERBOSE", "1"
---
rumpdisk/block-rump.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c
index cd7af494..8a3a404a 100644
--- a/rumpdisk/block-rump.c
+++ b/rumpdisk/block-rump.c
@@ -373,6 +373,7 @@ rumpdisk_device_write (void *d, mach_port_t reply_port,
Proxied memory was not rounded up to page size, causing
error with vm_map'ing the underlying memory.
WARNING: Could be security risk if assumption is incorrect:
Assumes start of all pci memory resources are at least page aligned.
---
pci-arbiter/netfs_impl.c | 11 ++-
1 file changed, 10
1 - 100 of 1734 matches
Mail list logo
