On Tue, Aug 10, 2021 at 5:04 AM Samuel Thibault wrote:
> In the past months, Sergey Bugaev has been working on fixing some
> Hurd security vulnerabilities.
Well I certainly wasn't doing it alone :)
Samuel and me have been working together over the past few months to
design and impl
Hello!
(Please keep in mind I'm *not* subscribed to debian-hurd@, so I don't
see mail here unless you send it to me explicitly.)
> start ext2fs: Hurd server bootstrap: ext2fs[device:hd2s2] exec
> startupext2fs: Executing '/hurd/startup': (os/kern) protection failure
>
> Could you help me?
This s
On Fri, Aug 13, 2021, 01:25 Samuel Thibault wrote:
> So as usual, along the Debian release, we will have a Debian Hurd
> release. I have drafted the following list of news since the 2019
> release: <...>
> Is there some other big line that I am forgetting?
>
Perhaps "multiple security improvemen
On Fri, Aug 13, 2021, 10:05 Sergey Bugaev wrote:
> Perhaps "multiple security improvements" deserve a mention?
>
Oh, or is it not going to make it into the release because of the
unfinished copyright assignment? :(
Sergey
>
Hello.
Lately I've been having ever-increasing troubles trying to update my Debian
GNU/Hurd installation. I'm not entirely sure if it's my system that's
broken, or something's wrong with upstream Debian repositories (the latter
appears to be more likely, though). Either way, the issues seem to be
On Fri, Oct 8, 2021 at 12:33 AM Samuel Thibault wrote:
>
> Hello,
>
> Answering separately since they are completely separate issues.
Thanks a lot for taking a look!
> That's odd indeed. Which gnumach kernel were you using? I noticed an FPU
> context switch bug in gnumach, possibly that was affe
On Fri, Oct 8, 2021 at 12:42 AM Samuel Thibault wrote:
> > I've verified that I see the same behavior on darnassus,
>
> I don't see it happen on darnassus.
Interesting: I've just checked and I no longer see it on darnassus
either! But I'm 100% positive I saw it there. Could it be that
darnassus h
On Fri, Oct 8, 2021 at 12:38 AM Samuel Thibault wrote:
> Please always check the latest version of the wiki pages on darnassus,
> there it was fixed:
>
> debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg
> --extra-suites=unreleased sid chroot http://deb.debian.org/debian-
On Fri, Oct 8, 2021 at 12:56 PM Sergey Bugaev wrote:
>
> On Fri, Oct 8, 2021 at 12:33 AM Samuel Thibault wrote:
> >
> > Hello,
> >
> > Answering separately since they are completely separate issues.
>
> Thanks a lot for taking a look!
>
> > That'
On Fri, Oct 8, 2021 at 2:20 PM Samuel Thibault wrote:
> That's because vim is currently failing to build, and thus we get
> trapped again by the version difference between vim and vim-common.
>
> "Unstable" has its name for a reason :)
Even ignoring vim for a second (I could/should attempt to exc
Ignoring both syslog and vim did the trick! The final command was:
# debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg
--extra-suites=unreleased --exclude vim,vim-tiny,rsyslog sid
/tmp/subhurd/ http://deb.debian.org/debian-ports/
Now, I ran into another issue, which is th
On Fri, Oct 8, 2021 at 8:49 PM Samuel Thibault wrote:
> That's the "Extend `device_read`/`device_write` into supporting > 2TiB
> disk sizes." item in the "small hack entries" list. There's indeed the
> device_get_status() call that needs fixing, but device_read/write as
> well, they need to be ext
On Fri, Oct 8, 2021 at 9:03 PM Samuel Thibault wrote:
> Sergey Bugaev, le ven. 08 oct. 2021 21:01:09 +0300, a ecrit:
> > I wonder if it'd be possible to change device_{read,write} to use a
> > 64-bit integer without introducing separate new RPCs,
>
> No: RPC in
On Fri, Oct 8, 2021 at 9:57 PM Sergey Bugaev wrote:
> type recnum_t = uint64_t | array[*:2] of uint32_t;
Hm, no, that wouldn't actually work, it's still a type mismatch. And
'polymorphic' is not polymorphic enough. type recnum_t = array[*:2] of
uint32_t would work, but
I've done some debugging of the sudo / PAM issue, here's where I'm at:
Thread 4 hit Breakpoint 4, __dlopen (file=0x100169e0
"/lib/i386-gnu/security/pam_unix.so", mode=2) at dlopen.c:75
75 in dlopen.c
(gdb) finish
Run till exit from #0 __dlopen (file=0x100169e0
"/lib/i386-gnu/security/pam_uni
On Sun, Oct 10, 2021 at 5:38 PM Samuel Thibault wrote:
> Which version do you have?
Seemingly the same 1.18.3-7 as you do:
$ dpkg -l libkrb5-3:hurd-i386
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-
On Mon, Oct 11, 2021 at 1:31 PM Samuel Thibault wrote:
> Perhaps just
>
> apt install --reinstall libkrb5-3
>
> so that it reinstalls the libkrb5.so.3 symlink (which in version
> 1.18.3-7 is supposed to point to libkrb5.so.3.3).
That didn't help:
# apt install --reinstall libkrb5-3
Reading packa
On Mon, Oct 11, 2021 at 6:41 PM Samuel Thibault wrote:
> Diversions show up in /var/lib/dpkg/diversions.
There's nothing about libkrb5 in there :|
Are there any other tools left to investigate why dpkg is fine with
this, and where libkrb5.so.3.3~0 comes from? Should I just forcefully
delete libk
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
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
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
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
Hi,
this is a shameless self-promotion :) I have posted about the Terrible
mDNS responder on Mastodon before, but not on this list, and I have
been making minor changes to it recently, so I thought I might as well
announce it here, perhaps it could be useful to someone.
Debian GNU/Hurd comes with
> Hmmm... How do you run the Hurd? Do you run linux on bare metal and
> then Hurd on qemu?
Yes. I run Hurd on a qemu/libvirt VM that itself runs on GNU/Linux.
> When you are typing "herd.local" what does that
> mean?
>
> I suppose that means on your linux machine you are typing "ssh
> hurd.local
Hello,
On Fri, May 5, 2023 at 4:30 PM Samuel Thibault wrote:
> FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.g.
> dash built, I'll probably have rumpkernel built too. Essentially, we
> should be able to debootstrap a whole chroot.
Awesome!
Are these (binaries? debs?) avai
On Fri, May 5, 2023 at 9:07 PM Luca wrote:
> I'll try to build a ramdisk with these packages and see where we get
> (not far I suppose, mainly because of the issues introduced by my last
> fs/gs base patch... :( ).
Quick update, I'm already running ramdisk (with glibc and Hurd built
locally, not
Hello,
On Wed, May 10, 2023 at 3:55 AM Samuel Thibault wrote:
> With the available .debs you should now be able to enable these.
I'm afraid I'm going to need more guidance here. Your little tutorial
in readme [0] is helpful (thank you!), but I still have questions.
[0]: https://people.debian.or
On Wed, May 10, 2023 at 1:43 PM Samuel Thibault wrote:
> For now you'll just be faced with library dependencies, so I'd say just
> unpack all lib*.deb (+zlib1g*.deb) and you'll be done.
I see, thanks.
By the way, I'm now getting
../../isofs/lookup.c:224:1: error: conflicting types for
‘diskfs_g
An update from me:
/hurd/startup starts up (which means that exec is now working -- how
cool is that!) and then spawns auth and proc. But then proc
task_terminate's itself (= exists with some error, likely), seemingly
somewhere early, maybe even during ld.so startup -- before it gets a
chance to o
On Wed, May 10, 2023 at 7:39 PM Samuel Thibault wrote:
> Sergey Bugaev, le mer. 10 mai 2023 19:30:20 +0300, a ecrit:
> > Dynamic linking also adds its share of complexity,
>
> You can always create static builds of the various translators, by
> running e.g. make proc.static i
On Wed, May 10, 2023 at 9:05 PM Sergey Bugaev wrote:
> _hurd_startup crashes on accessing 'args' it has just received from
> the exec server in the __exec_startup_get_info. The data arrives
> out-of-line, and... broken:
>
>
>
> argvType is { msgt_inline = 0, msg
Hello,
On Sat, Jun 10, 2023 at 12:47 PM Samuel Thibault
wrote:
> Do you think about anything else to announce?
Not an announcement, but please consider backporting
346b6eab3c14ead0b716d53e2235464b822f48f2 "hurd: Run init_pids ()
before init_dtable ()" if it's not too late (or doing it after rele
On Sun, Jun 11, 2023 at 2:52 PM Samuel Thibault wrote:
> > This was an important fix; currently ctty handling is completely
> > broken in Debian.
>
> How does it manifest in practice?
A background process that tries to read (or write, if TOSTOP is set,
which you can do with 'stty tostop') the ter
Hello -- and congratulations to all involved!
Unfortunately the released installation ISO is very broken :( , which
spoils the whole thing.
Once you install it and try to boot for the first time, you are greeted
with a wall of errors about /dev//tty1 (yes, with a double slash) and
the other ttys
On Wed, Jun 14, 2023 at 4:14 PM Samuel Thibault wrote:
> ?? I'm not getting such a result at all of course. How did you run the
> installation *exactly*?
The image I downloaded was debian-sid-hurd-i386-NETINST-1.iso from [0]
[0]:
https://cdimage.debian.org/cdimage/ports/hurd-i386/12.0/debian-si
On Thu, Jun 15, 2023 at 2:14 AM Samuel Thibault wrote:
> > Well, if there was, say, a call for pre-release testing,
>
> Well, Debian did ask for testing.
>
> I guess I should explicitly tell debian-hurd@ "hey that's a matter for
> *us* too".
I don't think I understand what you mean; but what I me
On Wed, Oct 25, 2023 at 2:52 PM wrote:
>
> October 25, 2023 3:43 AM, "Samuel Thibault" wrote:
>
> > jbra...@dismail.de, le mer. 25 oct. 2023 03:40:16 +, a ecrit:
> >
> >> Or maybe GCC is partly at fault for the
> >> Hurd's X86_64 building troubles?
> >
> > It's not at all. Nor is libtool.
> >
On Mon, Oct 30, 2023 at 1:27 AM Samuel Thibault wrote:
> Samuel Thibault, le ven. 27 oct. 2023 08:48:19 +0200, a ecrit:
> > while [ "$(echo -n `echo internal/reflectlite.s-gox | sed -e
> > 's/s-gox/gox/' ` )" = internal/reflectlite.gox ] ; do : ; done
>
> For now, I could reproduce with
>
> tim
Hello,
On Wed, Nov 1, 2023 at 9:17 PM Samuel Thibault wrote:
> I tracked it a bit, it seems that libport is not always cleaning
> structures from the proc class. Below is the tracing that we get for
> instance with the while loop above. Alloc is the allocation of pi, free
> is the freeing from th
Hello!
I'm porting the Ladybird browser to build and run on the Hurd. After
having done a bunch of changes and finally getting something built, I
was rewarded with a SIGILL inside innocently looking Qt initialization
code.
Turns out Qt in Debian hurd-i386 was built with -msse2 -mfpmath=sse,
and t
Hello, and happy holidays!
Every now and then, I hear someone mention potential ports of gnumach
to new architectures. I think I have heard RISC-V and (64-bit?) ARM
mentioned somewhere recently as potential new port targets. Being
involved in the x86_64 port last spring was a really fun and
intere
Hello,
I guess this is where I ask (consistent with the subject line) about
how I would run the x86_64 system (to reproduce & debug this).
I've tried debootstrapping from
https://people.debian.org/~sthibault/tmp/hurd-amd64 as the wiki page
says; but that doesn't proceed beyond the rumpdisk. Rumpd
On Wed, Jan 3, 2024 at 11:27 AM Samuel Thibault wrote:
> Sergey Bugaev, le mer. 03 janv. 2024 11:17:53 +0300, a ecrit:
> > I guess this is where I ask (consistent with the subject line) about
> > how I would run the x86_64 system (to reproduce & debug this).
>
> You pr
On Wed, Jan 3, 2024 at 10:07 PM Luca wrote:
> Hi Sergey,
Hi,
> Recently I've been installing hurd-amd64 on another disk of my hurd-i386
> vm and booting from that. Basically I prepare the disk with debootstrap
> --foreign, then I reuse the i386 grub install to boot the 64 bit kernel
> with a cus
On Thu, Jan 4, 2024 at 10:57 AM Samuel Thibault wrote:
>
> Sergey Bugaev, le mer. 03 janv. 2024 21:56:54 +0300, a ecrit:
> > perhaps I need to try two of them in parallel and some I/O-heavy
> > workload in the background, as you're saying.
>
> Yes, that's need
On Fri, Jan 5, 2024 at 12:52 AM Samuel Thibault wrote:
> Which kind of activity?
I just had a loop spawning /bin/true — this should've triggered it
assuming it was related to some state getting corrupted on
context-switching.
> I use
>
> while true ; do apt install --reinstall wdiff ; done
That
I'm not seeing hurd-dbg / hurd-libs-dbg packages in your repo. Could
you please either teach me where to look, or if they're indeed
missing, upload them?
Also I can't help but notice that the hurd package (i.e the translator
binaries) is still not being built as PIE, unlike basically all the
other
On Sat, Jan 6, 2024 at 2:42 AM Luca wrote:
> I had this small patch applied that apparently is enough for me to have
> some kind of core dump, I'm not sure if it's a good solution:
> +#ifdef __x86_64__
> + struct _libc_fpstate fpstate;
> + memset(&fpstate, 0, sizeof(fpstate));
> +
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
51 matches
Mail list logo
