Re: proc leaking
On Sun, Nov 26, 2023 at 08:32:30PM +0100, Samuel Thibault wrote: > I found the issue, it's because of the quiescence support in libports, > which assumes that all threads will sooner or later go through a > quiescent state (because it finished processing a message). But that's > not true, proc doesn't set a thread timeout, and thus some threads can > stay indefinitely stuck in receiving messages. And thus the deferred > dereferencing used by ports_destroy_right never gets achieved. > > I'll push a fix. Very nice catch. -- Richard Braun
Re: [PATCH v3 gnumach] percpu area using gs segment
On Sun, Sep 24, 2023 at 12:31:20AM +0200, Samuel Thibault wrote: > For an inline to actually get optimized, you have to put it in the .h > file, otherwise the compiler won't be able to inline it at all since it > won't have the definition when compiling other .c files. It could be a good thing to add whole program optimizations like LTOs, although this requires the code quality to be excellent, but that should eventually be the case anyway. -- Richard Braun
[PATCH] libps: Fix memory leak
--- libps/procstat.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libps/procstat.c b/libps/procstat.c index d0423410..131d3a4b 100644 --- a/libps/procstat.c +++ b/libps/procstat.c @@ -1097,6 +1097,7 @@ _proc_stat_free (ps) 0, >task_events_info_buf, char); MFREEMEM (PSTAT_THREAD_WAITS, thread_waits, ps->thread_waits_len, ps->thread_waits_vm_alloced, 0, char); + MFREEMEM (PSTAT_EXE, exe, sizeof(string_t), ps->exe_vm_alloced, 0, char); FREE (ps); } -- 2.37.2
Re: date bug
On Sat, Nov 13, 2021 at 11:13:13AM +0100, Samuel Thibault wrote: > There used to be a bug that was making GNU Mach erroneously jump to year > 2032 or something like that. In april 2021 I had committed > Did anybody notice the bug again since then? If not, we can probably > revert I'm happy to report it's been a long time since I've seen this indeed. Thanks ! -- Richard Braun
Re: Hurd wiki in https
On Tue, Aug 17, 2021 at 10:29:42AM +0200, Richard Braun wrote: > On Mon, Aug 16, 2021 at 11:23:23PM +0200, Denis 'GNUtoo' Carikli wrote: > > While it's relatively easy to create an account on the Hurd wiki[1] and > > to edit it, everything is in http. > > > > So at the account creation and during the login, the password is most > > probably transmitted in clear. > > > > Would it be possible to fix that? > > On vacation right now, but I'll get to it eventually. Done. -- Richard Braun
Re: directmap vs highmem usage in gnu mach?
On Wed, Aug 25, 2021 at 04:23:23PM +0200, Samuel Thibault wrote: > Richard Braun, le mer. 25 août 2021 15:59:12 +0200, a ecrit: > > I can't recall exactly, but that's why we write comments, right ? > > See [1]. > > > > Fixing this requires changing all callers to not assume that allocated > > memory can always be directly mapped, in particular some kvtophys calls. > > Ok, I was not sure which way to interpret the comment: it says "Instead > of updating all users" and talks about wiring, so I wasn't sure it was > really talking about directmap vs highmem (which AIUI doesn't matter for > wiring), or something else, and whether it was already done/optimized. > > I have a patch that makes the vm_fault_page, vm_map_copy_steal_pages, > vm_page_convert, and vm_page_alloc use highmem. It boots fine, can build > packages without problems, I guess that's a good-enough test? For practical purposes, sure, but in the long run, there must be some kind of very clear (preferrably explicit) policy about all that. Personally, I'd do the same as Linux, with all callers explicitely passing flags, instead of having various versions of vm_page_grab. These flags may become useful on multiple layers of the "memory stack". -- Richard Braun
Re: directmap vs highmem usage in gnu mach?
On Mon, Aug 23, 2021 at 01:56:52PM +0200, Samuel Thibault wrote: > Do you know if it is on purpose that all vm_page_grab() calls use the > directmem segment, and not the highmem segment? Notably vm_page_fault() > ends up filling the directmem segment first, I even wonder how the > highmem segment ends up getting filled :) > > Is that perhaps to rather try allocating in directmem that has faster > access from kernel than highmem? (although for e.g. all kmsg purpose the > kernel just uses the userland page table so it's not faster, right?) > > I was thinking about adding a vm_page_grab_high() that can be used when > there are no directmap constraints, that will probably solve the > (relatively rare) OOM issues on the buildds. Hello, I can't recall exactly, but that's why we write comments, right ? See [1]. Fixing this requires changing all callers to not assume that allocated memory can always be directly mapped, in particular some kvtophys calls. -- Richard Braun [1] https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/vm/vm_resident.c?id=4dbaa718038fadc51d9b95d2383868a229d91457#n776
Re: Hurd wiki in https
On Mon, Aug 16, 2021 at 11:23:23PM +0200, Denis 'GNUtoo' Carikli wrote: > While it's relatively easy to create an account on the Hurd wiki[1] and > to edit it, everything is in http. > > So at the account creation and during the login, the password is most > probably transmitted in clear. > > Would it be possible to fix that? On vacation right now, but I'll get to it eventually. -- Richard Braun
Re: Hurd Security vulnerabilities, please upgrade!
On Tue, Aug 10, 2021 at 02:26:54PM +0300, Sergey Bugaev wrote: > 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. > > I urge everybody to upgrade (and reboot!) their systems as soon as > possible. I have already updated mine, and can confirm that all my > exploits fail now. I have issues mounting /home (or rather, keeping it mounted) on darnassus.sceen.net since the reboot. Samuel already has root access so he can look at it when he has time. I haven't looked at the work, but if Samuel merged it, I trust it's good. Thanks :). -- Richard Braun
Re: PTHREAD_MUTEX_ADAPTIVE_NP undefined in Gecko
On Tue, Feb 09, 2021 at 10:36:28AM +0100, Riccardo Mottola wrote: > how is compilation of Gecko related browsers going on? I am trying to > compile ArcticFox and I get this: > > 3:43.44 > /home/multix/code/Arctic-Fox/nsprpub/pr/src/pthreads/ptsynch.c:60:48: error: > ‘PTHREAD_MUTEX_ADAPTIVE_NP’ undeclared (first use in this function); did you > mean ‘PTHREAD_MUTEX_FAST_NP’? > 3:43.44 60 | rv = pthread_mutexattr_settype(&_pt_mattr, > PTHREAD_MUTEX_ADAPTIVE_NP); > 3:43.44 | ^ > 3:43.44 | PTHREAD_MUTEX_FAST_NP > > > The code is almost unchanged with current gecko, so I wonder if there were > any workarounds attempted and/or upliftable patches for that. The _NP suffix means non-posix, and is generally used for system-specific features. The use of "adaptive" mutexes is probably just an optimization, so it should be completely safe to just comment it out on systems where the macro doesn't exist (assuming it's a macro). -- Richard Braun
Boot issue with e1000 netdde driver
On Tue, Sep 22, 2020 at 01:28:42PM +0200, Richard Braun wrote: > On Fri, Aug 28, 2020 at 06:39:29PM +0200, Samuel Thibault wrote: > > One way to avoid the bug is to use the e1000 hardware network type. I > > guess the rtl8139 driver that we ship in netdde has a bug in its irq > > handling (we had already seen that kind of bug a long time ago in the > > IDE driver). Moving to rump-based network drivers will probably help > > fixing this kind of issue long-term :) > > It does seem to help. Thanks. > > For information, the virtual machines were using the pcnet device, > not the rtl8139 one. Actually, with the e1000 driver, very often, network is not functional at boot time and I have to manually kill netdde and trigger some activity for it to work. -- Richard Braun
Re: exec hang at boot.
On Thu, Oct 08, 2020 at 12:16:51AM +0200, Samuel Thibault wrote: > I might have found the trigger for the exec hang at boot. The symptoms > were that very early during the program loading by ld.so, it would > overflow its stack with 0x40, apparently because there were odd things > happening with the GOT. One odd thing was that ld.so was getting loaded > at 0x0. That's because it is a PIE. Issues that might come up are that > pointer 0x0 could then actually be a should-be-valid pointer... I > modified gnumach to load PIE binaries at 0x800, like our exec server > does, and couldn't reproduce the exec hang at boot. This is now in > debian as gnumach version 2:1.8+git20201007-1. Very nice. -- Richard Braun
Re: A few questions: Libre SoC, website, Rust
On Fri, Aug 28, 2020 at 06:39:29PM +0200, Samuel Thibault wrote: > One way to avoid the bug is to use the e1000 hardware network type. I > guess the rtl8139 driver that we ship in netdde has a bug in its irq > handling (we had already seen that kind of bug a long time ago in the > IDE driver). Moving to rump-based network drivers will probably help > fixing this kind of issue long-term :) It does seem to help. Thanks. For information, the virtual machines were using the pcnet device, not the rtl8139 one. -- Richard Braun
Re: A few questions: Libre SoC, website, Rust
On Sat, Aug 15, 2020 at 06:51:27PM +0200, Jan Wielkiewicz wrote: > Also navigation is too complicated and messy, searching doesn't work at > all, because https://darnassus.sceen.net/cgi-bin/hurd-web is dead half > of the time. > Any special wishes? By the way, the main reason why that website is so often unreachable is netdde freezing. I've restored an old trick I used in the past to mitigate the problem, which is merely a cron script that kills it every hour. If you want that to improve, someone will have to hunt that bug down. -- Richard Braun
Re: A few questions: Libre SoC, website, Rust
On Fri, Aug 21, 2020 at 01:28:42AM +0200, Richard Braun wrote: > On Thu, Aug 20, 2020 at 11:10:53PM +0200, Almudena Garcia wrote: > > We have to leave the 90s ideas, and think as younger people thinks nowadays I mean, really, you have to keep in mind that the Hurd originated in the 80s/90s, and is meant to be compatible with a system that dates from the 70s. So what is this nonsense about "90s ideas" ? -- Richard Braun
Re: A few questions: Libre SoC, website, Rust
On Thu, Aug 20, 2020 at 11:24:50PM +0200, Jan Wielkiewicz wrote: > Please stop arguing, everyone. > I already made some notes about how to make the web page more readable, > we'll be judging the effects when its done. > Don't waste more time on arguing than it's worth. This discussion relates to the culture of the project itself, so I don't think it's wasted. > As for Samuel's and yours opinion about people with cognitive biases, > etc, remember not everyone who visits the page is a system developer - > sometimes an unrelated person can visit the page. In this case if that > person finds the web page interesting (even due to cognitive bias), > there's a possibility the person will tell others about the finding. > If the web page looks bad, abandoned, isn't convincing, then the person > just won't care or even worse, will tell others the Hurd is abandonware. > There's a small chance an incompetent person will tell their more > competent friends about it, and that's our chance. > All I want to do is to increase the probability. My point isn't to have a bad looking web site, just not to turn it into something that it shouldn't be for all kinds of stupid reasons. I personally like what you wrote so far about your intentions. -- Richard Braun
Re: A few questions: Libre SoC, website, Rust
On Thu, Aug 20, 2020 at 11:10:53PM +0200, Almudena Garcia wrote: > > I don't want to work with people who give up because it takes them > > more than a few seconds to find information, or who evaluate a project > > based on the look of its web site. > This is a prejudice, in fact. The definition of a prejudice includes "not being based on reason or actual experience". That doesn't apply here. > If we want to attract new users who can become contributors, we have to > make the beginning and the initial steps as easy as we can. > You talk about "a few seconds" to find information but, when you are a > noob, these searches can take hours or even days, because you don't know > what is the term to search. > If the website is user-friendly, this type of "explorers" can quickly find > all the information about this project, and even know new details that this > person doesn't know about. Again, you're mixing "beautiful" and "useful". In any big code base, it's perfectly normal for a newcomer to spend hours or even days looking for obscure pieces of information without an interactive way to get your answer (think mailing list or mentor). Anyone who expects things to happen more quickly and gives up is very likely not willing to make the proper effort to get things right in their code afterwards. > If the website looks "modern" (not necessarily following the latest hype, > simply "elegant"), this explorer will think that the project is in active > development and It feels attracted to continue researching about this. > If the website looks ugly and old, the explorer will think that the project > is mostly dead, and doesn't take the effort to continue the research. Tell me the state of the Hurd project again ? I think the web site is pretty honest about that. If I were a newcomer looking at a "beautiful" web site, whatever that would be, and found an old code base with roughly one serious maintainer and a few contributors here and there, I'd get to think the project is vaporware with good marketing and feel pretty cheated, and may not want to go on further either. > We have to leave the 90s ideas, and think as younger people thinks nowadays > (It don't refers to think as a teenager, simply remove elitists ideas and > prejudices about "who merit work in this project") I don't see why the "90s ideas", whatever you're referring to, must be abandoned. I don't see why "we" should adapt to how younger people think, especially considering how many I know do think (or, really, don't). I do claim to be an elitist for a project such as the Hurd, in so far as I am convinced that the project failed in no small part because the initial code was written by someone who just wasn't good enough for the task, unlike a project like, say, Linux. Finally, it's not about merit, it's about who can make the project progress well and who can't. I claim that, for the most part, people who are not willing to make serious efforts should just stay away. The Hurd is already buggy enough as it is and this is not a school. -- Richard Braun
Re: A few questions: Libre SoC, website, Rust
On Thu, Aug 20, 2020 at 03:19:56PM +0200, Almudena Garcia wrote: > But, about the website, if I remember well, this thread started because of > an offer to update the website. > Why don't we accept the offer? > > It's a bad idea to reject this type of offer only for prejudices about the > attractive. The help was not refused. Samuel actually said it's all fine after clarifying a few things. > As I told before, I know many people who reject Hurd after showing some > interest, simply because the webpage seems to show a dead project (search > about "halo effect") > Not only because of the latest news, but the 90s style appearance of the > website, and the outdated documentation. Who's prejudiced now ? And if we're going that way, then the point I was making in my previous message, which I hoped you would have understood, is that I don't want to work with people who give up because it takes them more than a few seconds to find information, or who evaluate a project based on the look of its web site. You're mentioning the halo effect and you're right, I'd much rather work with people who have as few cognitive biases as possible, so call me prejudiced against the others if you want, at least I have a strong argument for my case. -- Richard Braun
Re: A few questions: Libre SoC, website, Rust
On Thu, Aug 20, 2020 at 02:32:03AM +0200, Almudena Garcia wrote: > > Every year or couple of year has its own marketting trend, and if you > > don't follow it each time (thus consuming your time just for that), > In fact, It's not necessary to follow the hype about a technology or a > trend. > But It's not necessary to follow the hype to create a beautiful webpage. > The current page is many 90s style. > The FSF webpage (https://www.fsf.org/) is more beautiful than the current > Hurd webpage, for example. The GNU project's main website ( > https://www.gnu.org/) is a good example too. As Samuel said, don't mix "beautiful" and "useful" or even "easy to use". State the subject clearly and stick to it. The reason the Hurd doesn't have a good web site, or good documentation, or good performance, or good device support, etc..., is the same as always : too few people. I'm pretty sure changing the web site won't change much to that, there needs to be some momentum to bootstrap the first changes in what people care most about (which for me is a much more reliable system than what it currently is, or could be without too much effort) and then it'll attract people. To all who whine about information not being easy to find : sure, it could be better, but it's there, so if people give up that quickly, I believe it says more about our current culture, or even the character of these people, than it says about the project itself. Grow up and focus on what matters. -- Richard Braun
Re: [PATCH] SMP initialization: detection and enumeration
On Thu, Jul 30, 2020 at 10:09:01PM +0100, Jessica Clarke wrote: > > It's physically memory mapped to the local APIC address space, but > > because of that, it's also not optimal. All systems I know use a scheme > > similar to TLS, i.e. using the fs or gs segment register, to fetch > > a per-CPU structure and from it, per-CPU data. This avoids relying on > > hardware running at a lower frequency than the CPU. > > You need to do that anyway if you want any guarantees over _what_ the > IDs are (normally you want 0 for the BSP, 1 to N-1 for the APs). Not really. You can build a CPU ID table on the BSP, and associate CPU IDs with all local APIC IDs discovered, and use that look-up table later to obtain a CPU ID from the local APIC ID of the CPU running the code. It's just too slow compared to using a segment register. -- Richard Braun
Re: [PATCH] SMP initialization: detection and enumeration
On Thu, Jul 30, 2020 at 10:44:40PM +0200, Samuel Thibault wrote: > > > I'm wondering: is it really *that* simple to get the current cpu number, > > > just read a memory location? I'm surprised that this would provide > > > different results on different cpus. > > > > The APIC ID is stored in the Local APIC of each cpu. This address is common > > for > > all Local APIC: accessing this from each cpu, it shows the Local APIC of > > this > > cpu. > > By example, if you access this address from cpu1, you can see the Local > > APIC of > > cpu1. > > So it's a special address whose accesses are trapped within the chip and > don't actually get out on the memory bus? It's physically memory mapped to the local APIC address space, but because of that, it's also not optimal. All systems I know use a scheme similar to TLS, i.e. using the fs or gs segment register, to fetch a per-CPU structure and from it, per-CPU data. This avoids relying on hardware running at a lower frequency than the CPU. -- Richard Braun
Re: Problems in Debian GNU/Hurd with Xorg and GCC
On Fri, Jul 03, 2020 at 06:13:16PM +0200, Samuel Thibault wrote: > It's not "every" package. But yes, sure, the Hurd way is bumpy. Just > like Linux was when its was much less used. People seem to have > completely forgotten that. Setting up Xorg used to be a nightmare there. The people who didn't know those times couldnt't have forgotten them. Also, it's not the 90s any more :). -- Richard Braun
Re: real hardware and ethernet cards
On Wed, Jun 10, 2020 at 11:34:55AM +0200, Riccardo Mottola wrote: > Put HD back in old laptop. > Boot halts at: > Hurd server bootstrap: ext2fs[defice:hd0s1] exec > > Tried rebooting, it is stuck twice, This is an old race that definitely needs fixing. -- Richard Braun
Re: Three Cheers for Samuel!
On Wed, Jun 10, 2020 at 02:07:32AM +0200, Samuel Thibault wrote: > One thing is: starting exploring stuff early. I started programming > around when I was 10. And then spend a *hell* lot of time exploring > stuff, experimenting with things, doing whatever teaches anything. > (heck, I even read a 10-book series on the X protocol, and that did end > up being useful in the end). > > One thing worth thinking: you may be amazed by people that came before > you. You will quickly see younger people be amazed by *you*, simply > because comparatively you will have spent a lot more time doing stuff > than they have. Everything is relative :) I completely agree. While I appreciate the compliments, I'm worried about the excessive aspect of it. Calm down, we're not gods, we're just decent developers. -- Richard Braun
Re: Three Cheers for Samuel!
On Sun, Jun 07, 2020 at 08:29:14AM -0400, Joshua Branson wrote: > I just want to thank you for being so diligent at maintaining and > continuing to develop the GNU/Hurd. You are one of my heroes, and I > love how dedicated you are to the project! > > Wishing you a good day, Likewise. -- Richard Braun
Re: Google Summer of Code
On Wed, Feb 05, 2020 at 10:18:35AM +0100, Almudena Garcia wrote: > To do a "serious work" as OOP, It's necessary to think about the current > work, separating the pieces of the project, thinking what relationship will > be between the pieces... Write empty code structures, without a previous > rethinking about the final architecture and structure of this code, can > cause even more problems than current "dirty" design. That's not true, otherwise noone would use agile software development with OOP. You have a very rigid, almost V-model way to think about this. Also you're focusing on OOP, while to me, it's only one of the elements required for such a project. And all these requirements are driven by a single motivation : to reduce maintenance costs. The Hurd is developped by a very small group of people, very sporadically, but has virtually no deadline constraints. Event the GSoC deadline doesn't matter that much since, in the end, mentors are the ones who evaluate your work, and it can easily be decided that the result is a success even if it didn't meet all the initial conditions. As a result, it's even more important than in other projects that original code be as good as it can get. Mach code is in essence OOP, something you're throwing out the window for no good reason. Mach is in essence portable, something you also decided to forego without much thought. Yes, Mach code has some extern variables, but these concern a handful of global objects only, like the kernel task, map and pmap, and that's code from the 80s and there's no reason to continue that trend. > But these tasks are too long for a GSOC. I'm really interested in GSOC, but > the OOP objective is too ambitious for It. They're not "tasks". They're requirements for success, especially for something as difficult as correct concurrent code with shared memory involved. They're not work in a sequence of coding sessions, they're part of all coding sessions. What's ambitious is the project itself, namely SMP. Well be ambitious, or don't. > So, I prefer continue with my current code, doing simpler refactors to ease > the future redesign, but without stop the current objectives (scheduler > synchronization, and load system with cpu 0 as bound processor). You'll just waste a lot of time getting there, if at all, with that approach. Refactors are only good if applied on code that is already fit for incremental change. Your existing SMP implementation is not. It needs a complete rework. The fact that you were never able to understand why it's not able to handle more than 2 CPUs is a frightnening indicator of that state. Imagine the day you'll be facing apparently random crashes that can occur almost right away or after hours of run time. Without completely mastering what you're doing, it's almost guaranteed that you won't be able to fix those, let alone identify them. And without reducing the individual complexity of the functional modules involved, you won't be able to master what you're doing. And my requirements to work on this project have everything to do with reducing that complexity. It's also important to make it easy for other people to work on that code. I wouldn't be insisting so much on these points if I didn't think they were critically important. All this is not new. You're a student, so learn from it. -- Richard Braun
Re: Google Summer of Code
On Fri, Jan 31, 2020 at 08:58:41PM +0100, Almudena Garcia wrote: > > That's not exactly what I mean. Let's talk on IRC to sort this out. > > I've not seen you today in freenode, so I'll write my opinion here: I'm always on IRC, just not in #hurd. You can message me directly. > I think that a better idea could be to continue the current work with easy > refactors (change some names, create functions to avoid duplicated code, > moved some data (as apic_id) to more correct structures... etc), which is > simpler than a fully OOP redesign. > > what do you think? I think any work that is meant to last and ends up in a form that isn't fit for long term maintenance isn't serious work. -- Richard Braun
Re: Google Summer of Code
On Mon, Jan 27, 2020 at 05:09:38PM +0100, Almudena Garcia wrote: > I'm a student, and my knowledge is limited. But, in my previous SMP work, I > got develop most tasks guided by more experienced developers than me. > If any person is able to guide my work, teaching me the most important > concepts and solving my questions about this, probably I'm able to do this > task That's not exactly what I mean. Let's talk on IRC to sort this out. I'm braunr@Freenode. -- Richard Braun
Re: Google Summer of Code
On Mon, Jan 27, 2020 at 10:48:26AM +0100, Almudena Garcia wrote: > > Thanks for your interest! As Joshua wrote: "need to find a Hurd > > developer to mentor you". > > Are there any volunteer for this? > I need anyone with knowledge in this area (and with a bit of patience, > anyway) because I'm a student, and I've very low knowledge in real > operating system development. > My current work is here: https://github.com/AlmuHS/GNUMach_SMP I could, but this is a tough one. It will require a lot of work on your side. If you're going to do this, you need to make sure you are able to commit to the task. -- Richard Braun
Re: Hey please how can I get shell account
On Sun, Oct 13, 2019 at 10:02:31AM +0700, ofenja oscar wrote: > Man thanks for your help but honestly i still find it very difficult to get > it, please is there any simple way i can get it well or understand it as > well? because i have tried all my best to get this shell account , if its > possible for you maybe any simple way i will understand it please try to > help me i will appreciate and also maybe you can create it by your self, if > possible you can use my email address(ofenja2...@gmail.com) and do that for > me and use anything you like as for the password and send me the link to > login > Thanks First sentence : "There are GNU/Hurd boxes that we're offering shell accounts on. These are generally available for people interested in contributing, and who have already shown some level of involvement in the project. If you simply want to try the Hurd, the easiest way is running it in a virtual machine." In other words, just use a virtual machine. And don't put a mailing list address in the BCC field. By the way, I suggest any mention of these shell accounts to be removed and the accounts to be discussed orally at the initiative of someone who can give them. They've just become a regular source of annoyance. -- Richard Braun
Re: Detect word size in the Hurd from the preprocessor
On Sat, Jun 01, 2019 at 01:26:54PM +0200, Joan Lledó wrote: > Is there a reliable way for the C preprocessor to know whether the > system is 32 or 64 bit, in the Hurd? I know the Hurd is only 32 bit > for now, but I wonder if is there a macro somewhere which contains > this information. With GCC and Clang, __LP64__ is the most reliable one. Note that this is specific to the ILP32 and LP64 data models though. On Windows, which uses the LLP64 data model, it wouldn't work. -- Richard Braun
Re: Page sharing between a block device and a mounted file system?
On Thu, May 16, 2019 at 08:58:07AM -0700, Raymond Jennings wrote: > So um...I may be totally missing the mark on this but if I have one task > running a file system and another task managing a block device mounted as > that file system, how does one manage a file in such a way that it won't > store data in memory redundantly that is also stored in the block device? > > Criteria that I'm guessing at: > > * The file needs to be mmap'able as well as accepting read/write requests > * The file is stored on the block device at locations determined by the > file's inode/extent tree > * The block device itself presumably can also be mmap'ed and accept > read/write requests, including to the same area of the "disk" that the file > data occupies > * The same data, and presumably, the same pages in memory, are being used > to cache both > * A read or write in one will reflect immediately in the other > > I must admit that I have no idea beyond the theoretical stuff gleanable > from the mach reference guide how this would work. > > As a thought exercise I'm trying to design my own microkernel inspired by > mach so I'm curious how one would prevent redundancy or inconsistency in > this sort of scenario. > > By contrast, I'm assuming that the file's metadata itself (extent trees, > directory listings, and so on) would just be read/write direct to the block > device without worrying about being "aliased" from the file itself. Ditto > if the file is accessed/mmap'ed uncompressed, but stored in a compressed > form on the block device. You could take a look at the ext2fs translator. Although I don't see the difficulty here. The file system should be the only server to cache file data in the page cache, and should merely use direct access to the block device. -- Richard Braun
Re: Documentation and ideas for related work
On Fri, Apr 19, 2019 at 06:43:41PM +0200, Paul Boddie wrote: > > What's not described, obviously, is external memory managers, but it's > > similar to how kernel memory managers (file systems) interface with > > the VM. > > I don't really follow the distinction between external and kernel memory > managers, but perhaps this is pertinent to NetBSD but not to a microkernel- > based system. Please let me know if I missed something. It's only relevant for microkernel-based systems, in that, in a classical Unix-like system, all files systems (which are the most common memory managers) run from kernel space, whereas on a microkernel-based system, they normally run outside. The two main classes of memory managers are file systems and device drivers, with the exception of the default pager for anonymous memory and swapping. -- Richard Braun
Re: Documentation and ideas for related work
On Tue, Apr 16, 2019 at 03:12:21PM +0200, Paul Boddie wrote: > What interests me most at the moment is how filesystem content is paged into > processes, whether there is some kind of sharing of accessed pages between > processes (some kind of page cache, maybe), and how such things are organised. That question relates much more to the Mach kernel than to the Hurd. And since the Mach VM is the ancestor of most "modern" operating systems (the BSDs in particular, but the Linux memory management code uses a mostly similar design), documentation shouldn't lack. I recommend the NetBSD UVM paper, which extensively describes the BSD VM, and in turn much of the Mach VM. What's not described, obviously, is external memory managers, but it's similar to how kernel memory managers (file systems) interface with the VM. -- Richard Braun
Re: Error with gnumach compilation
On Fri, Feb 15, 2019 at 03:56:03PM +0100, Almudena Garcia wrote: > After a couple of changes, this assembly errors disappeared, but now It > show newer errors in the linker step. There's a "trick" in the building process that cherry picks functions from the C library when they're undefined in the kernel (correct me if I'm wrong about this). But when a symbol is undefined in both the kernel and the C library, the link just fails. The symbol in question here is APIC_LOCAL_APIC_ID. The fix should be obvious. -- Richard Braun
Re: Error with gnumach compilation
On Fri, Feb 15, 2019 at 02:33:55PM +0100, Almudena Garcia wrote: > I removed this macro tonight, to write a better solution. > > https://github.com/AlmuHS/GNUMach_SMP/commit/342b7d62168bcaca944d01c0550b899da5d7f0c5 > > I've got to enabled correctly this macro, and feels that CPU_NUMBER > assembly macro is enabled, but compiler shows another error > > ../i386/i386/cswitch.S: Mensajes del ensamblador: > ../i386/i386/cswitch.S:46: Error: operandos inválidos (secciones *UND* y > *UND*) para «+» > ../i386/i386/cswitch.S:64: Error: operandos inválidos (secciones *UND* y > *UND*) para «+» > ../i386/i386/cswitch.S:116: Error: operandos inválidos (secciones *UND* y > *UND*) para «+» You should recognize, without others telling you, that the very least would be to switch your locale so that the error messages can be understood by everyone on this list, even if those particular ones are obvious. -- Richard Braun
Re: proxy-defpager for all users?
On Mon, Nov 05, 2018 at 11:02:47PM +0100, Samuel Thibault wrote: > proxy-defpager is typically set on /servers/default-pager, but its > permissions are by default 644, which makes it unusable by normal users, > it'd need to be 755 (see the x check in the defpager source). > > Apart from allowing users to eat memory, which they currently already > can do anyway, is there any downside to making this 755 so people can > mount their own tmpfs? I personally wondered why it wasn't the case from the start. That being said, I'll use this as an opportunity to restate a core problem of Mach memory management, as I couldn't find it on the wiki. This problem may or may not be even more triggered by using unprivileged tmpfs instances. Thu Dec 29 2016 : < braunr> i've identified a fundamental flaw with the default pager < braunr> and actually, with mach in general i suppose < braunr> i assumed that it was necessary to trust the server only < braunr> that a server didn't need to trust its client < braunr> but mach messages carry memory that is potentially mapped from unprivileged pagers < braunr> which means faulting on that memory effectively makes the faulting process a client to the unprivileged pager < braunr> and that's something that can happen to the default pager during heavy memory pressure < braunr> in which case it deadlocks on itself because the copyout hangs on a fault, waiting for the unprivileged pager to provide the data < braunr> (which it can't because of heavy memory pressure and because it's unprivileged, it's blocked, waiting until allocations resume) < braunr> the pageout daemon will keep paging out to the default pager in the hope those pages get freed < braunr> but sending to the default pager is now impossible because its map is locked on the never-ending fault -- Richard Braun
Re: How do I learn the Hurd stuff?
On Thu, Aug 30, 2018 at 06:15:28PM +0200, Almudena Garcia wrote: > It's not only a test. Obviously, It must start as a test, but I want to add > this to Hurd if runs. > > > > El jue., 30 ago. 2018 a las 18:02, Richard Braun () > escribió: > > > On Thu, Aug 30, 2018 at 05:53:42PM +0200, Almudena Garcia wrote: > > > I've said It yet. > > > > > > > As this > > > > form, we don't need to know how many cores has the processor and set > > the > > > > core number in Mach in compilation time. Instead, the same processor > > will > > > > detect the cores number and configure SMP automatically. > > > > > > I don't know the exact assembly instructions, but I read about the > > > processor can be configured from assembly to run in multicore mode. > > > Then, what we had to do is to write a routine that initializes the > > > processor with this multicore support, during Mach boot. > > > > > > In this guide, in Chapter 8.4 feels to be a better explanation about how > > to > > > do this (initialization example in 8.4.4): > > > > > https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html > > > > Oh, so it's merely runtime probing. That's not what I meant. Please improve your English. You're heavily misusing words here. You're not talking about a "hardware SMP implementation", just asking the system how many processors it has. That's a very tiny detail among all that's required to write a decent scalable SMP kernel. -- Richard Braun
Re: How do I learn the Hurd stuff?
On Thu, Aug 30, 2018 at 05:53:42PM +0200, Almudena Garcia wrote: > I've said It yet. > > > As this > > form, we don't need to know how many cores has the processor and set the > > core number in Mach in compilation time. Instead, the same processor will > > detect the cores number and configure SMP automatically. > > I don't know the exact assembly instructions, but I read about the > processor can be configured from assembly to run in multicore mode. > Then, what we had to do is to write a routine that initializes the > processor with this multicore support, during Mach boot. > > In this guide, in Chapter 8.4 feels to be a better explanation about how to > do this (initialization example in 8.4.4): > https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html Oh, so it's merely runtime probing. -- Richard Braun
Re: How do I learn the Hurd stuff?
On Thu, Aug 30, 2018 at 05:32:40PM +0200, Almudena Garcia wrote: > Excuse me, It's a little offtopic. > > I was talking about implement SMP via hardware in Hurd (Mach really). In > this implementation, Mach configures the processor during the boot, > enabling multicore support. (All Pentium 4 or modern x86 processor supports > this) > > In the current SMP support, this multicore support feels been build from > software, generating the threads and assigning It to the processor from > software. Then, my idea is to start a project to change this SMP software > to a newer implementation via hardware, as I previously said. As this > form, we don't need to know how many cores has the processor and set the > core number in Mach in compilation time. Instead, the same processor will > detect the cores number and configure SMP automatically. > > https://c9x.me/x86/html/file_module_x86_id_45.html > > https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html What is "a newer implementation via hardware" ? Can you be very specific about what you're referring to ? -- Richard Braun
Re: How do I learn the Hurd stuff?
On Thu, Aug 30, 2018 at 04:52:28PM +0200, Almudena Garcia wrote: > > But this solution would be specific to Intel chips? ie: this method of > > SMP wouldn't work on AMD or POWER right > > All x86 architecture, I think What on Earth are you talking about ? -- Richard Braun
Re: How do I learn the Hurd stuff?
On Sat, Aug 25, 2018 at 01:20:55PM -0400, Joshua Branson wrote: > Is there something else I could be doing? How much time should I try to > devote to this a week? With 1 hour a day get me somewhere in 6 months? > Or should I be spending more like 2 hours a day? You should like what you're doing, and set yourself real-world goals like developing a project doing something that actually interests you. -- Richard Braun
Re: Fwd: The GNU C Library version 2.28 is now available
On Wed, Aug 01, 2018 at 09:53:59AM +0200, Samuel Thibault wrote: > NEWS for version 2.28 > = > > [...] > > * Building and running on GNU/Hurd systems now works without out-of-tree > patches. I didn't think it would actually happen. Great work :). -- Richard Braun
Re: Question about protected payloads
On Tue, Jul 24, 2018 at 08:31:18AM +0200, Joan Lledó wrote: > > Just to be sure, do you see what protected payloads are ? > > I think I don't, to be honest. Very briefly, they are an optimization to avoid a lookup. Instead of receiving a port name and looking up the associated object from it, we use protected payloads, which are merely user-assigned arbitrary values associated to ports, to store the address of the associated object directly, and that's what you receive instead of the port name. -- Richard Braun
Re: Question about protected payloads
On Sat, Jul 21, 2018 at 10:48:07AM +0200, Joan Lledó wrote: > I'm blocked with a bug in the lwIP translator that's driving me crazy: > under some particular circumstances, calling select() over two ports > results on only one of these io_select RPCs being received by the > translator. The other one is returned to glibc as EOPNOTSUPP. > > I debugged enough to identify the source of this errno at > ports_manage_port_operations_multithread() [1], particularly, the > problems seems to be the bucket passed to > ports_manage_port_operations_multithread() not matching the one inside > the payload. > > Anyone has a hint on what could be happening here? I'm lost :( > > Reproducing this bug is easy: just install the liblwip0 package and > try to open a ssh connection to our lwip translator. Just to be sure, do you see what protected payloads are ? -- Richard Braun
Re: Enable SMP support
On Sat, Jun 16, 2018 at 01:17:57PM +0200, Almudena Garcia wrote: > Finally, we got to write a test function to get the apic_id, and It feels > to run correctly. > Now, we're trying to implement another function, to transform the apic_id > in the kernel cpuid. > > I attach the current test function to get apic_id with its test file One other thing. No sane operating system uses the cpuid instruction each time they need to identify the current processor, because of its cost (it's a fully serializing instruction). Instead, they make the fs or gs segment register refer to a per-processor area in memory, where the ID of the current processor can be found, among other things. See the cpu_id() function at [1] for a reasonably simple (but not naive) implementation. -- Richard Braun [1] https://git.sceen.net/rbraun/x15.git/tree/arch/x86/machine/cpu.h?id=7615ab33c6d9e0b858aa3f183095a83f7a1d0620#n471
Re: Enable SMP support
On Fri, Jun 15, 2018 at 07:18:55PM +0200, Richard Braun wrote:
> On Fri, Jun 15, 2018 at 06:27:21PM +0200, Almudena Garcia wrote:
> > I'm trying to define the cpu_number() in multiprocessor.
> >
> > To do this, I tried to use CPUID assembly x86 instruction, to get the CPU
> > SMP number.
> > The function, in C, is this:
> >
> > static inline char smp_processor_id(void) {
> > char apic_id = 0;
> > asm("mov $1, %%eax\n\t"
> > "cpuid\n\t"
> > "mov %%bh, %0\n\t" : "=g" (apic_id));
> > return apic_id;
> > }
> >
> > In Linux, after executing this in a test source, It returns '8'
> >
> > But, when I try to execute It in Hurd, It shows a segmentation fault.
> >
> > I attach the test source file
> >
> >
> > Can you help me?
Also note here that you're confusing the APIC ID, a device identifier at
the hardware level, with the CPU ID, a processor identifier at the kernel
level. On some machines, the APIC ID may be higher than or equal to the
maximum number of processor installed.
--
Richard Braun
Re: Enable SMP support
On Fri, Jun 15, 2018 at 06:27:21PM +0200, Almudena Garcia wrote:
> I'm trying to define the cpu_number() in multiprocessor.
>
> To do this, I tried to use CPUID assembly x86 instruction, to get the CPU
> SMP number.
> The function, in C, is this:
>
> static inline char smp_processor_id(void) {
> char apic_id = 0;
> asm("mov $1, %%eax\n\t"
> "cpuid\n\t"
> "mov %%bh, %0\n\t" : "=g" (apic_id));
> return apic_id;
> }
>
> In Linux, after executing this in a test source, It returns '8'
>
> But, when I try to execute It in Hurd, It shows a segmentation fault.
>
> I attach the test source file
>
>
> Can you help me?
You said in your initial message that you were willing to start all this
at your own risk. Well this is it, and it's only the very beginning.
This inline assembly snippet is invalid because it doesn't tell the
compiler that it uses registers, which may conflict with the code
generated by the compiler. Read the GCC extended inline assembly
documentation carefully, and especially the machine constraints [1]
for the x86 family. The idea is to create an eax variable with the
value 1 in C, pass that to the inline assembly expression with the
appropriate constraint, and do something similar for the returned
value in ebx, and then extract bh from it.
--
Richard Braun
[1]
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Machine-Constraints.html#Machine-Constraints
Re: race condition destroying condition variables
On Tue, Dec 19, 2017 at 09:25:16AM +0100, Samuel Thibault wrote: > Brent W. Baccala, on mar. 19 déc. 2017 00:08:44 -0500, wrote: > > Looks like there's a race condition when we destroy a condition variable. > > My > > understanding of the expected behavior is that once all the threads have > > been > > signaled (i.e, pthread_cond_broadcast is called), the condition variable > > can be > > safely destroyed with pthread_cond_destroy. > > Err, I don't think that POSIX allows to assume that. The fact that > pthread_cond_broadcast has returned doesn't mean that other threads have > finished with pthread_cond_wait. Besides, the threads should also all go through reacquiring the associated mutex, usually sitting right next to the condition variable, and usually both embedded in a parent object. What you're normally really interested in is releasing this parent object, including destroying the mutex, which means you also have to wait for all threads to unlock it. One common way to deal with this is reference counters on the parent object. -- Richard Braun
Re: gnumach - Page fault error
On Thu, Nov 09, 2017 at 10:34:33AM +0100, Samuel Thibault wrote: > Jens Arm, on jeu. 09 nov. 2017 08:56:21 +0100, wrote: > > Sorry for the late answer. > > This fix fixes the crashes. > > Cool :) Nice catch :). -- Richard Braun
Re: gnumach - Page fault error
On Tue, Oct 03, 2017 at 12:14:39AM +0200, Samuel Thibault wrote: > Jens Arm, on lun. 02 oct. 2017 19:20:57 +0200, wrote: > > Here is the trace to the error in the attached PNG. > > Is is reproduced with the mini.iso from Samuel. > > The trace shown after I type "trace" is the same as shown automatically. > > Ok, it looks like traces I have already seen in our buildd VMs. It > means the IDE driver is trying to push data to disk some memory which > doesn't exist any more. I was wondering whether perhaps it's just that > the IDE layer misses putting some reference to make sure that the memory > doesn't get swapped out while being written to disk. > > Richard, does that ring a bell? It's possible. I didn't work much on the IDE driver because it already did what was required for highmem support, but I may have been wrong. The code in linux/dev/glue/block.c:device_write uses vm_map_enter with a NULL object, which normally prevents paging, but I see some scary code in vm_map_enter that may merge the new mapping with another with a valid object. I wonder if map entry merging should just be disabled completely, as it wouldn't be the first time it caused problems, and isn't that useful considering how unoptimized the VM system is in general, and that scalable data structures are now used. I don't have time to look at the details, but I could see a mistake right at the beginning of linux/dev/glue/block.c:device_write, where the local vm_map_copy object may be discarded while still uninitialized. Probably unrelated but still noteworthy. -- Richard Braun
Re: [GSoC 2017] LwIP translator
On Sat, Aug 26, 2017 at 09:38:39AM +0200, Joan Lledó wrote: > The Google Summer of Code is about to end and it is time to summarize my work > on the lwip translator. Excellent work, one of the best GSoC projects I've seen. -- Richard Braun
Re: multi page memory object operations
On Sun, Jul 30, 2017 at 10:20:55PM -0400, Brent W. Baccala wrote: > It seems that the current libpager's data-request and data-unlock routines > only handle single page requests, while the Mach documentation suggests > that the kernel can make multi page requests using these routines. No, the kernel can't, even if the interface seems to allow it. > Looking at the gnumach code, it sure seems that the kernel only makes > single page requests. > > Does anybody know the history of multi page requests? Was it ever > implemented in the kernel? Maksym Planeta worked on it as part of the 2012 GSoC. I tried to review it for merging, but was never satisfied with some details, too afraid of what it would break (in both the API and ABI), and didn't consider the gain worth at the time (I always thought improving the page cache internally first, without involving the external pagers, would yield much better results, and it did). Both Maksym and I went on to do other things and the work just lingered, as is often the case. It could make sense to revive the work now that paging was globally improved, but you'll likely get conflicts, and the work isn't trivial, IOW it really needs careful review. -- Richard Braun
Re: [GSoC 2017] Multithreading
On Sun, Jul 09, 2017 at 10:18:05PM +0200, Joan Lledó wrote: > However, after all the pending threads still were not being canceled. > The problem here was that the standard function where the threads > where blocked on, pthread_cond_wait(), didn't respond to cancel > requests from hurd_thread_cancel(). It was strange, because > pthread_cond_wait() is a valid cancellation point. But in the Hurd > servers we need to call our own non-standard version, > pthread_hurd_cond_wait_np()[7], which reacts to requests from > hurd_thread_cancel() and stops blocking the thread. Cancellability and interruptibility are two different things. In particular, note how POSIX explicitely mentions that "These functions shall not return an error code of [EINTR]." -- Richard Braun
Stupid drama with Svante Signell
Hello, We're lucky enough to have almost no drama-related issue, thanks in no small part to the tiny number of contributors. But we have Svante Signell. His inability to decently work with others is known beyond the Hurd, so it should come as no surprise that I've always had a hard time putting up with him along the years. Once more, his childish behaviour has struck, but this time I've had enough. So I write this message to let those concerned know that I'll just be away, working on something else until he's banned, and to leave yet another archive of yet another Svante screw up. -- Richard Braun
Re: Heads up: Recent status: emacs24/25 FTBFS since a long time on GNU/Hurd
On Thu, Dec 08, 2016 at 10:44:09AM +0100, Svante Signell wrote: > Since a long time emacs FTBFS due to unknown reasons. The latest version > building was Debian 24.5+1-5, from 28 Nov 2015. As already mentioned, the real issue is in Emacs. See the relevant LWN article [1] for details. > Even before successful builds were by pure luck. One suspicious issue is that > emacs use sbrk() for memory allocation, right? Notably sbrk() is not > fool-proof > as implemented for Hurd in glibc: Is it or is it not? No it's not. And this is the real point I want to make in this message. For performance reasons, the implementation of virtual memory maps was changed in GNU Mach [2]. Basically, VM maps maintain a red-black tree of holes for O(log(n)) allocations of virtual memory. This is what Linux does too, except they have "augmented" their red-black tree to use the one that already stores entries, instead of adding one for holes. It also works a bit differently because it still allows bottom-up / top-down allocations. That's the big difference. GNU Mach used to implement a bottom-up policy prior to this change, on which the sbrk() implementation relied. This is no longer true. Mappings can be created anywhere in the map, and it turns out that some are created immediately following the heap, preventing sbrk() from doing its job. Now, we could fix this by doing the same thing Linux does, but as usual, someone has to do it, and the benefits aren't that big. Our virtual spaces have never been as tidy as on other systems, and it doesn't prevent most programs from working just fine. It usually matters for things like emulators, such as Wine, or debuggers like Valgrind, which have strong requirements regarding address values, but we currently don't build them because other dependencies are missing. On the other hand, the performance improvement is really, really needed. It is now common, even on monolithic systems, to have processes with thousands of entries in their address space, but keep in mind the Hurd is a multi-server system, which basically means that what would be in the kernel for Linux is in a userspace process on the Hurd, and with the improvements on the page cache, it's actually normal for an ext2fs server to have between 1k and 10k map entries, sometimes more. Here is an example, run on one of our buildd systems : # vminfo -v 410 | wc -l 20157 And that's one file system instance. At the time, the system was using a total of around 56k map entries. In other words, we can't go back for now, especially not just to make an obsolete interface used by only one piece of software that is likely to fix the issue soon. Unless you really want to work on those red-black trees, stop pinging about this issue. -- Richard Braun [1] https://lwn.net/Articles/673724/ [2] https://git.sceen.net/hurd/gnumach.git/commit/?id=1db202eb8406785500f1bc3ceef7868566e416a1
Re: port leak in select
On Fri, Dec 02, 2016 at 10:43:04AM +0100, Samuel Thibault wrote: > Or simply > > (d[i].reply_port != MACH_PORT_NULL)) Aren't there cases where an entry could remain uninitialized ? -- Richard Braun
Re: port leak in select
On Fri, Dec 02, 2016 at 08:41:21AM +0100, Samuel Thibault wrote:
> About the port leak in select discussed on IRC, I checked history a bit,
> this (000ef460744786571f51604e6de631b7168e239a):
>
> - if (d[i].type)
> + if (d[i].type & ~SELECT_ERROR)
> __mach_port_destroy (__mach_task_self (), d[i].reply_port);
>
> was added when handling EBADF , for which there is no reply port to
> destroy. Then I added this (099f8d2b7ecedc4f6fc895d2c35912f995289c24):
Indeed, so type != 0 doesn't imply port creation.
> I guess we could simply do this:
>
> for (i = firstfd; i <= lastfd; ++i)
> - if (d[i].type & ~SELECT_ERROR)
> + if (d[i].type & SELECT_ERROR)
> + {
> + d[i].reply_port = MACH_PORT_NULL;
> + }
> else
> {
> int type = d[i].type;
> d[i].reply_port = __mach_reply_port ();
>
> as well as in the error case of __io_select_request, and then just check
> against MACH_PORT_NULL before destroy.
So the condition would look like
if (d[i].type && (d[i].reply_port != MACH_PORT_NULL))
I agree.
In the mean time, I've built libc packages that partially fix the issue
(there will still be spurious destruction attempts on EBADF, which could
destroy a legitimate right) but the leak is so severe I found it useful.
If you want those, add
deb http://ftp.sceen.net/debian sid main
to sources.list, and add the GPG key D50E6AD4 to APT.
--
Richard Braun
Re: Unreclaimed swap space upon process termination?
On Tue, Nov 29, 2016 at 10:11:34AM +0100, Thomas Schwinge wrote: > Early after a system reboot (second run of the executable), I ran into a > GNU Mach "panic ../vm/vm_page.c:2058: vm_page_evict: vm_page: unable to > recycle any page"; see attached. As this is new code in GNU Mach (commit > 5d1258459ad618481a4f239e8ce020bdecda1d3f "Rework pageout to handle > multiple segments"): anything you'd like me to do/preserve before > rebooting? It's known, and just needs to be fixed, something I plan to do when I have more free time. For information, the problem is caused by the lack of threshold on the number of dirty pages. -- Richard Braun
Re: Unreclaimed swap space upon process termination?
On Mon, Nov 28, 2016 at 04:03:44PM +0100, Thomas Schwinge wrote: > Unless this a known issue, or somebody can quickly pinpoint the problem, > I'll try to bisect core system packages, between the version of the > "good" and "bad" disk images. It's a known issue, a side effect of the page cache changes that I merged some months ago. Because of increased cache usage, there is more memory pressure, and therefore more swap usage (mostly through double paging, since the kernel always tries to evict external pages first). The default pager has never been able to correctly reclaim these pages in the past, but now there are a lot more of them. -- Richard Braun
Re: aptitude not working
On Wed, Nov 16, 2016 at 11:03:44AM +0100, Riccardo Mottola wrote: > Miguel Figueiredo wrote: > >I think not. I've "always" seen one the annoying small thing in aptitude > >in Hurd, pressing q to quit and it does not quits. If i repeat the q and > >then Ctrl+C, it quits and I see the on the console. > >I've seen this on Virtualbox, but now i have it on qemu with the same > >behavior. > > the behaviour is similar to mine then. I never use the curse based interface of aptitude. -- Richard Braun
Re: aptitude not working
On Mon, Nov 14, 2016 at 04:52:25PM +0100, Richard Braun wrote: > > (btw: can you read out these values later on, with a command similar to > > dmesg? pausing VirtualBOX and typing out things is boring) Ah, by the way, practically none of us run the Hurd on VirtualBox, and it's known to behave badly in some cases, so you're on your own about that. -- Richard Braun
Re: aptitude not working
On Mon, Nov 14, 2016 at 11:55:46AM +0100, Riccardo Mottola wrote: > how do I know actually which console I am running? could it be meaningful? > I have the issue also when running aptitude from a remote console (e.g. > through telnet) Well, telnet and ssh are remote so they're subject to netdde hangs. The hurd and machs console use the VGA interface (or something similar). You can identify the hurd console by switching to virtual terminals with ALT-FX [1-6]. You can disable it by editing /etc/default/hurd-console. When the hurd console is disabled, the system remains on the default mach console, with a single terminal only. -- Richard Braun
Re: aptitude not working
On Mon, Nov 14, 2016 at 11:53:44AM +0100, Riccardo Mottola wrote: > I increased the allocated RAM size of the VM to 1024MB and now I read this: Try 2g or even 3g. > (btw: can you read out these values later on, with a command similar to > dmesg? pausing VirtualBOX and typing out things is boring) See /var/log/dmesg. > I think something dies: it might have to do with the console, I find it > strange that if I type into aptitude while it appears hanging, after killing > it in ctrl-c I actually see what I type in console. Do you want a > screenshot? I'm not sure what's happening there and it's likely a screenshot won't help. > I did an upgrade with apt-get which works fine and which included an > aptitude update. > I retried aptitude afterwards: having updated everything with apt-get, I > just tried to remove package, thus, no actual download needed! Yet it > hangs. Always keep an eye on swap usage, and maybe /proc/slabinfo. One problem with increasing swap usage is that it requires more kernel objects to track memory, and it can in some cases (and easily with older kernels) exhaust kernel memory. > If I am doing something wrong, I guess it is not in the usage of aptitude > itself, but more in something in my HURD setup? I don't think you're doing something "wrong", I think we (the developers) know the system enough to avoid most of the caveats. But yes, it's probably caused by a Hurd defect. -- Richard Braun
Re: aptitude not working
On Mon, Nov 07, 2016 at 05:34:23PM +0100, Riccardo Mottola wrote: > do you mean what vm_page reports at the earliest stages of boot? > It says 751M in pages, 733M free Yes, but specifically : vm_page: page table size: 786414 entries (43008k) vm_page: DMA: pages: 4080 (15M), free: 0 (0M) vm_page: DMA: min:500 low:600 high:1000 vm_page: DIRECTMAP: pages: 233472 (912M), free: 217899 (851M) vm_page: DIRECTMAP: min:11673 low:14008 high:23347 the "high" threshold. If you add all the high thresholds together, you'll know how much memory must be free before the pageout daemon stops. > After loading aptitude, it tells me there are 535M free. Just before hang, > I see 526M free and it remains there with "total progress" not even starting > and nothing to do > (since the system was freshly upgraded with apt-get, I just removed a > package, thus there was nothing to download) > > Should I check memory differently? at a glance, I don't think we are going > out of mem here. >From what you describe, it doesn't seem to be a hang caused by this. With your amount of memory, you shouldn't even have a HIGHMEM segment, which makes bugs even less likely. So I don't know what happened to your system, or if you're doing something wrong or not. I've just installed a Hurd system on a VM myself, and I had paging problems when upgrading from the snapshot to unstable, but once I assigned 2g of RAM, I could upgrade without too much trouble with aptitude. I use it on all my machines, Linux and Hurd, and never have such issues. -- Richard Braun
Re: aptitude not working
On Mon, Nov 07, 2016 at 04:59:09PM +0100, Riccardo Mottola wrote: > it still had plenty of free RAM, the system wasn't doing anything else. Let's assume that's the case, although it may still happen that, between two top samples, the system could allocate a huge amount of memory and hang. And it's not that unlikely. Check how much of free RAM you have compared to the high thresholds of free memory reported at boot. > I was using telnet to the system. It happens also when I use the local > console though. The local console (hurd-console, not the mach console) was very recently fixed [1] with regard to paging. -- Richard Braun [1] https://git.sceen.net/hurd/hurd.git/commit/?id=81fb68fee81769d81c373e3af5a508d706b7e3d6
Re: aptitude not working
On Mon, Nov 07, 2016 at 03:51:26PM +0100, Riccardo Mottola wrote: > I did try checking top in a second terminal. > On opening, aptitude has 66mb RES 132MB virtual > after "g" it grows just a little more, I hit gh once again and It ramps up > to 72Mb RES, 128 VIRT... and staus there, 9% of memory. > The virtual machine is configured with 768MB of RAM. Don't look at aptitude alone, look at the system globally. > No network activity: there are no packages scheduled to download, the hang > happens *after* the download. In case of a crash, I restart and there is > nothing to download and it will hang again. Are you logged in locally or through SSH ? -- Richard Braun
Re: aptitude not working
On Mon, Nov 07, 2016 at 02:49:35PM +0100, Richard Braun wrote: > So, what's your version of GNU Mach ? And how much memory do you have > on your system ? We also know network can just randomly hang because of bugs in the netdde server. -- Richard Braun
Re: aptitude not working
On Mon, Nov 07, 2016 at 02:44:13PM +0100, Riccardo Mottola wrote: > anybody of you using aptitude? > It has a strange malfunction to me: I select the action on packages (e.g. > opdate or install) then confirm the next review step then, if necessary, > downloads will happen, then it hangs. It never starts unpacking/configuring > things. I can hit ctr-lc and notice that if I typed something (like Q for > quit or G for go) that has been written on the command prompt! > It is not a new bug, but a nuiseance for sure. Does it happen only for me? I use aptitude and have no such problem. On the other hand, the Hurd may be hanging. Using aptitude can lead to large memory usage, which can increase swap usage, and fill kernel memory (in older kernels at least). So, what's your version of GNU Mach ? And how much memory do you have on your system ? -- Richard Braun
Re: Time for another round of releases
On Wed, Oct 19, 2016 at 08:10:03PM +0200, Thomas Schwinge wrote: > ..., and again I want to excuse my radio silence... The good news: we're > getting married. The bad news: that basically didn't allow to spend any > time on pet projects, in the last weeks/months. The good news (well, for > us, anyway): we'll soon be leaving for the honeymoon trip. The bad news: > I didn't manage to squeeze in enough time to prepare the releases. I > still need to better document/automate what needs to be done (in > particular for updating the web pages). Will it be OK to move the > release date towards end of November? (Yay, one more month for getting > stuff finished for inclusion...) ;'-\ Congratulations :-). -- Richard Braun
Re: libpager multi-client support
On Tue, Oct 18, 2016 at 01:56:48PM -1000, Brent W. Baccala wrote: > Can it be done in C? Sure. But following my principle of asking how to > write the code in the simplest manner, this one is obvious: STL containers > win. I'm not saying it can't be done. I'm saying it's not that hard. -- Richard Braun
Re: libpager multi-client support
On Mon, Oct 17, 2016 at 09:51:41PM -1000, Brent W. Baccala wrote: > What do you guys think? >From my fifteen years or so experience working in various projects with C++ and other languages, my opinion is that C++ is never the best choice. It makes you trade lines of code for increased complexity in understanding and following the code. You should either go with C for excellent control, or another higher level langguage for e.g. user interfaces and tasks that don't require the highest performance. I really don't think the problem you describe would be so hard to solve in C. -- Richard Braun
Re: Time for another round of releases
On Tue, Oct 04, 2016 at 03:22:32PM +0200, Ludovic Courtès wrote: > >> Is it possible to make a release of Hurd until mlockall/munlockall is > >> implemented? From what I understand these functions are needed to build > >> Hurd on > >> top of glibc2.24. > > > > Yes, but our current glibc tree is based on glibc 2.22, as guix needs > > it. > > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently > in the process of switching from 2.23 to 2.24), and we’d prefer to have > the same version on both GNU/Linux and GNU/Hurd, modulo the > Hurd-specific patches. The real problem is that we still have nothing about mlockall... Until we have, there is really not much to talk about. -- Richard Braun
Re: RFC: Revised authentication protocol
On Mon, Sep 19, 2016 at 09:52:38PM +0200, Olaf Buddenhagen wrote: > I'm a bit confused here: my understanding was that you essentially > wanted to implement a "single system instance" cluster. I would have > thought that would imply only a single instance of most servers -- > including auth -- rather than separate ones for each node?... I would think it best to make that a distributed process. -- Richard Braun
Re: firmlink deleting files on boot / interpretation of find -xdev switch
On Tue, Sep 20, 2016 at 01:33:44AM +0200, Samuel Thibault wrote: > I don't think we want to make /tmp use trustiness to determine whether > to follow a translator or not. If as root I run > > settrans -c /tmp/foo /hurd/firmlink /some/where > > I'd expect only foo to be removed. If we want to stick to the Unix interface, and I strongly think we do want that, then we'd need to make any translator visible as a separate file system indeed. On my Debian jessie, the clean_tmp() in /lib/init/bootclean.sh does use find -xdev, so this would work as intended. I don't know if that's already the case or not since Justus' work on /proc/mounts. The work required here is to rely on the parent to report whether a node is a separate file system. This could also break programs assuming a file system is a directory if the attached translator presents itself as something else. -- Richard Braun
Re: firmlink deleting files on boot / interpretation of find -xdev switch
On Wed, Sep 07, 2016 at 03:57:08PM -1000, Brent W. Baccala wrote: > OK, I understand. I personally lean in the direction of adding something > like an "-xtrans" switch to find, telling it not to enter translators, > because that's a lot clearer than usurping the interpretation of existing > switches from systems without translators. However, I also appreciate the > wisdom in what you say, in which case I revert to my earlier suggestion of > modifying the FTS code in glibc to interpret FTS_XDEV to mean "don't enter > translators". I think it's an acceptable workaround. > > We'd also have to make sure that remove()/unlink()/rmdir() don't cross > > the file system into the untrusted translator. > > > How do we do that without modifying programs? Probably the FTS code; > that's what both rm and find seem to use to transverse directory structures. Probably. > Also, I agree with Kalle that not entering translators should be the > default for "rm". If so, and we modify FTS without touching the programs, > then it also becomes the default for "chmod", "chown", "chcon", "grep", and > "du". In particular, I don't think we want that for "grep" (not so sure > about the others). > > If I understand you, Richard, you'd like to see grep's default be to enter > trusted translators, but not untrusted ones. Am I correct? Yes, but not only grep. > I'm not sure I understand when you say "More limited in that our trust > > set is finite". Actually, we'd like our trust set _not_ to be finite, > > since we want the system to be extensible, by both the admin and any > > unprivileged user. Again, too rigid. > > > I meant that we have a standard set of trusted translators in /hurd, and > that set is finite, just like the set of programs in /bin is finite. We > certainly don't have a means for verifying any old program in a user's bin > directory to see if it's safe to run as root. Unless that user has root access. > Would you like to see a scheme where only a limited set of trusted > translators were accessible to a process, and the user had the ability to > extend the trust set of his own processes? Something like adding > directories to your own PATH, but this would apply to translators running > under different UIDs, and not just programs that you started yourself? My current idea is something like Plan9 factotum, an agent that would be used by any program, client or server, to validate that it's safe to communicate through a given port. -- Richard Braun
Re: firmlink deleting files on boot / interpretation of find -xdev switch
On Tue, Sep 06, 2016 at 02:49:31PM -1000, Brent W. Baccala wrote: > Consider the case with symlinks. If "rm" transversed them, it could be a > big problem. Let's see... what's the option for that?... oh, there is > none! Isn't that interesting? "rm" has no option to follow symlinks! > > "find" does, however. "find -L -delete" is a dangerous combination, and > when run as root will trigger the exact same behavior that we're seeing > with firmlinks in /tmp. > > So, part of the solution is just making sure that the system scripts and > binaries do what we want. That "find" command used to clean /tmp should > not recurse into translators. It should delete the underlying nodes > instead. We really, really don't want to make standard Unix tools aware of Hurd-specific stuff, because that allows us to completely reuse the work of others. With a trend towards systemd, it's even more likely that our efforts will be put into providing some of the stuff specific to _others_ system instead. Personally, I would consider any solution that isn't entirely contained in the Hurd (kernel, servers, glibc and related) to be a no-go. > Makes sense. The parent is where you've got all that information. Is > there no way to retrieve it? There might, I haven't looked thoroughly, and it could be implemented if needed. > > The solution, whatever it is, should focus only on determining whether > > a server can be trusted or not. This should affect everything (servers, > > (active) translators and translator records). > > Yes, we need to clearly determine when a server is trusted. Yet I think it > has to be both more comprehensive and more limited than that. More > comprehensive in that we need to determine whether programs can be trusted > as well. More limited in that our trust set is finite. > > In this case, our trust set is "ext2fs", "find", and "bootclean.sh" (plus > shared libraries, the kernel, the shell, etc). We trust ext2fs to notify > us when it's handing off to a different translator. We trust "find" to > respect those notifications and not to cross those boundaries. We trust > "bootclean.sh" to clean /tmp without touching the rest of the filesystem. How do you define "trusting programs". If it's the path to the binary, then I disagree, it's far too rigid. If it's a process, and it can be determined that this process has a property that tells us we can trust it, then yes. The "more comprehensive" part would be what property, and how to manipulate and check them. I'm not sure I understand when you say "More limited in that our trust set is finite". Actually, we'd like our trust set _not_ to be finite, since we want the system to be extensible, by both the admin and any unprivileged user. Again, too rigid. Finally, I also disagree that we trust "ext2fs" or "find". We trust root. When a program is started, it trusts the initial ports it receives. We trust the root translator, and we trust what belongs to root inside of it. What I want is to safely extend that trust to other users (root and self should be default), and again, to other properties (like POSIX style capabilities). And I'd like to merely avoid contact with servers that aren't part of this trust computing base. We'd also have to make sure that remove()/unlink()/rmdir() don't cross the file system into the untrusted translator. -- Richard Braun
Re: firmlink deleting files on boot / interpretation of find -xdev switch
On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote: > I haven't been able to find any other places on my system where find uses > -xdev; just bootclean.sh, but my search has not been exhaustive. > > Obviously there's been a long history behind this problem, and I'm new on > the scene. Does this change make sense? Any solution that isn't a global system solution is doomed to fail, since this problem may affect any RPC, including those that don't exist yet. > On a related note, how do you find the owner of a passive translator? I > expected either showtrans or ls to provide that information (perhaps with a > verbose switch), but it had eluded me... I'm not sure you can from outside the parent. Besides, note that Justus and I are currently pushing towards the use of "translator records" instead of "passive translators" to more accurately reflect what they truely are. The solution, whatever it is, should focus only on determining whether a server can be trusted or not. This should affect everything (servers, (active) translators and translator records). -- Richard Braun
Re: RFC: Revised authentication protocol
On Sun, Sep 04, 2016 at 10:29:54PM -1000, Brent W. Baccala wrote: > For those of you who have followed my netmsg threads, you may remember that > there were two major issues when I first got it running. One was > libpager's lack of multi-client support, which has been discussed at > length, and the other was authentication, which we haven't discussed at all. Well, not exactly. I think I've mentioned Plan9's factotum at some point, which I'll remind again in this message as a reference we can draw from. > Here's my proposal for dealing with the authentication issue. > > Comments? I'm not completely familiar with the inner workings of the auth server but they look easy enough to imagine. Still, an opinion from someone more familiar with it like Olaf would be great. >From what I've read, it looks good. I can't imagine a scenario that would defeat your assertions. -- Richard Braun
Re: mach_msg blocking on call to vm_map
On Fri, Sep 02, 2016 at 01:18:26AM +0200, Richard Braun wrote: > In my opinion, your network server should do what all servers do, > i.e. dedicate a thread to the processing of a complete RPC and spawn > as many as necessary when receiving messages. At least for RPCs. Is there a way you can detect whether a message implies a reply ? -- Richard Braun
Re: mach_msg blocking on call to vm_map
On Thu, Sep 01, 2016 at 01:02:18PM -1000, Brent W. Baccala wrote: > Here's the call: > > mach_msg(msg, MACH_SEND_MSG | MACH_SEND_TIMEOUT, msg->msgh_size, > 0, msg->msgh_remote_port, > 0, MACH_PORT_NULL); > > Why should I specify MACH_RCV_TIMEOUT? It's not a receive call. Oh, OK. But then why pass msg->msgh_remote_port as rcv_name ? > The way my code is structured, one thread handles the traffic from the > network to IPC, and a separate thread handles the traffic from IPC to the > network. This call is in the network-to-IPC thread. This thread never > receives anything except network traffic, which it blocks for. > > I want a non-blocking send. This one blocks if the message is vm_map, the > memory object passed in is goofed, and the message is targeted at a task > port on the local kernel (and it doesn't have to be the task that calls > mach_msg). I don't think you can have that. Remember what I wrote about select ? It's a bit similar here. a timeout of 0 means mach_msg isn't going to block and instead return immediately, but that only concerns message passing, not the server operation itself. In this case, the server is the kernel, and the vm_map call itself has no associated timeout. In my opinion, your network server should do what all servers do, i.e. dedicate a thread to the processing of a complete RPC and spawn as many as necessary when receiving messages. -- Richard Braun
Re: mach_msg blocking on call to vm_map
On Thu, Sep 01, 2016 at 11:54:20AM -1000, Brent W. Baccala wrote: > On Thu, Sep 1, 2016 at 10:28 AM, Richard Braun <rbr...@sceen.net> wrote: > > I completely disagree. > > Thank you, Richard. Really! Thank you for disagreeing. Now we can have a > good discussion about this! This is how it works. People have opinions, express them with no ambiguity (including the level of disagreement), and hopefully the discussion and the results benefit from that. > > Most modern microkernels use synchronous IPC > > that just block, and many operations on top of them do block. The > > overall system on the other hand must be careful to avoid such > > deadlocks. > > OK, I read the Mach documentation for mach_msg() and concluded that it was > like a POSIX read(), that I could operate it in a mode where the kernel > absolutely would not block my process, and would return EWOULDBLOCK > instead. That's basically a kernel guarantee, at least as much as it is. > (Notice that it doesn't guarantee how long the system call will take - 1 > ms? 1 s? 1 week? - because it's not a real time system, which is why I > say "as much as it is") Yes, you can think of mach_msg as such a system call. Note that if the timeout is 0, it will return immediately instead of blocking, which is what a real-time system would do too. Real time systems aren't about that at all. > Are you now saying that's not how it works on Mach/Hurd? If so, please let > me know, because I've been under a big misunderstanding that I need to get > cleared up! I think your mistake here is using MACH_SEND_TIMEOUT instead of MACH_RCV_TIMEOUT. Your message certainly was sent, so there is no reason to get a timeout error for that. > Can a bunch of screwy translators legitimately cause mach_msg() to block > for some user space thing that might never happen, even if I've supplied > MACH_SEND_TIMEOUT? No, but I personally don't think it would be a problem if they could. > Yes, but libpager is in user space. Isn't one of the great selling points > for Hurd is that we put so much stuff into user space, and the kernel > offers us guarantees (read: "guarantees") that we're protected from > misbehaving stuff in user space? Does the kernel protect your web browser from a server stealing your data, corrupting them, or slowing you down on purpose ? The kernel is merely a messenger. My position is that, when you contact a server you implicitely assign it a level of trust that cannot be measured by the kernel. The Hurd merely allows the client to detach from the server, which I don't think is a very useful thing in practice. So no, the kernel definitely does _not_ protect users from misbehaving stuff in userspace. On the contrary, since we allow any user to plug their own servers on the file system, it actually becomes less secure. This was famously shown with the example of the firmlink translator used in /tmp, which would cause the removal of any file targeted by the firmlink on /tmp cleanup during system startup. Again, this is personal, and becoming off-topic, but I think the Hurd should not allow communication with untrusted servers whatsoever, and we should build a user-friendly mechanism from which the code could determine whether to trust a server or not. The current state is that this is indeed still a problem that needs to be solved. It doesn't necessarily mean that we cannot make it secure. > > My personal opinion on the matter is that you should only invoke > > remote objects if you trust them. > > How pervasive is this in the design? Is vm_map only one of many RPCs that > can block mach_msg() if some critical system translator is on the blink? Now that you know you should be using MACH_RCV_TIMEOUT, you should see that no server can block you indefinitely. But again, that's the only guarantee you get from the "mutually untrusting" principle application of the Hurd... Again, I don't think it's very useful in practice. It can even lead to serious mistakes like the original implementation of select, where the mach_msg timeout was used to implement the select timeout, and if 0, implement non-blocking behaviour. Since mach_msg couldn't possibly know when the server routine had completed a single non-blocking action, it would always return a timeout error prematurely. The select timeout simply had to be passed to the server and implemented there. > > The original Hurd design, > > however, was explicitly meant to allow clients and servers to > > be "mutually untrusting". I'm not exactly sure what this means > > in practice but it seems that clients can detach themselves from > > servers at any time. So making the timeout work, and allowing the > > transaction to be interrupted (usually with a - hardcoded ? check > > how glibc handles Ctrl-C/SIGINT during
Re: mach_msg blocking on call to vm_map
On Thu, Sep 01, 2016 at 09:58:00AM -1000, Brent W. Baccala wrote: > The big problem, as I see it, is that mach_msg() is blocking, and that > hangs my entire thread. It seems to me that these low-level RPC operations > like vm_map can't block, otherwise it would defeat the purpose of > MACH_SEND_TIMEOUT. So vm_map() should record the mapping and then return, > putting the copy operation on some kind of queue. I guess. > > Any thought on how to resolve this? I completely disagree. Most modern microkernels use synchronous IPC that just block, and many operations on top of them do block. The overall system on the other hand must be careful to avoid such deadlocks. I don't see anything wrong with vm_map misbehaving if the underlying implementation is wrong, just fix that implementation, e.g. by actually taking the send timeout into account here, or making libpager handle multiple clients like you want. Queuing the operation would only add tremendous complexity to an already extremely complex IPC mechanism where messages are allowed to be partially sent... Besides, the Unix semantics often require blocking, since the original system calls are, well, completely synchronous with respect to user thread execution (it's actually the very same thread running kernel code). So you'd only add another layer of synchronization, and it would block there. My personal opinion on the matter is that you should only invoke remote objects if you trust them. The original Hurd design, however, was explicitly meant to allow clients and servers to be "mutually untrusting". I'm not exactly sure what this means in practice but it seems that clients can detach themselves from servers at any time. So making the timeout work, and allowing the transaction to be interrupted (usually with a - hardcoded ? check how glibc handles Ctrl-C/SIGINT during an RPC - 3 seconds grace delay before brutal interruption) may be the only things required to make the behaviour comply with "Hurdish expectations". -- Richard Braun
Re: netmsg can now exec files (sort of)
On Mon, Aug 29, 2016 at 03:56:00PM -1000, Brent W. Baccala wrote: > I've figured out why the patched exec server didn't work with mmap, and > just opened a bug on it, with a fix attached. > > So now I've got a working, mmap-less exec server that burns a lot of extra > RAM (each process gets its own private copy of the C library), but lets me > execute files across a netmsg TCP/IP session. > > I think the next logical step is to get it to attempt an mmap, and only > fall back if that doesn't work. You might also want to consider making the mmap-less case more efficient by carefully copying the data. I didn't insist on COW zero-copy for no reason. -- Richard Braun
Re: Denial of service attack via libpager
On Mon, Aug 29, 2016 at 03:58:29PM -1000, Brent W. Baccala wrote: > On Sun, Aug 28, 2016 at 11:15 PM, Richard Braun <rbr...@sceen.net> wrote: > > OK, this comes from the fact that io_map directly provides memory > > objects indeed... Do we actually want to pass them around ? How > > come calls like memory_object_init (specifically meant to be used > > between the kernel and the pager) can be made from any client ? > > Good question! > > How could we authenticate the kernel to avoid unprivileged access? The usual method is to add a new unprivileged abstraction. We would have privileged memory object rights on which all calls are possible (something like memory_object_priv_t) and unprivileged ones (the regular memory_object_t). This is a kernel modification. We could also temporarily refuse to hand out memory objects and make the client pass its own task so the server does the mapping. This would take care of the DoS issue at least. This would be a pure Hurd change. > My goal is to build a single system image Hurd cluster. We need to support > multiple processes mmap'ing the same file, for basic POSIX compatibility. > If those processes are on different nodes, then the file server needs to > handle multiple kernels as paging clients. OK I forgot the context. And in this context, I agree. > > In addition, I've just thought about something else : if we handle > > multiple clients, how do we make sure that two kernels, caching the > > same file, don't just completely corrupt its content ? We'd need > > some kind of cooperation to prevent the file being mapped more than > > once I suppose, right ? > > > > They can already do that with ordinary io_write's. It's not that clients > can trash the file if they don't have write access; they can't. It's a > denial of service issue. No, what I mean is that the in-memory view of the same file on two different systems would become different, and this is why cache coherence would be required. > Or, well, a complete cache coherence protocol, with a very large > > overhead per operation. > > > > That's what I'm talking about! > > Let's think about the "very large overhead" for a minute. If we've only > got a single client, there's no extra overhead at all. That's the case > we've got now, so we're not losing anything. I'm not sure about this, since for one the kernel would have to (synchronously) notify a pager when a mapping is upgraded from read to write access, so that the pager can invalidate all other mappings. So just for this, we would effectively add constant overhead for every shared mapping that would become writable. But agreed, even in that case, it shouldn't happen often in the single client case. > If two processes on separate nodes have mmap'ed the same file with write > permissions, you bet that could generate some very large overhead! The > programmer has to take that into account, and avoid using that technique in > critical sections of code. It's more complicated than that. We would want regular POSIX programs to be able to map and still have the proper behaviour. We would really not want the programmer to take that into account, so we'd need strong ordering constraints. And because of that, this would be the same as cache line bouncing in multiprocessor machines, except across a network. But if that's what's required, then so be it. Users can adjust their own use if they want better performance. > Yet it needs to be supported for POSIX compatibility, and in non-critical > code it might not be a problem at all. Two tasks could probably bat a 4KB > page back and forth a hundred times and you'd never notice, just so long as > they settled down and stopped doing it once they got initialized. I'm not saying we shouldn't do this because of the overhead, but it has to be considered. > Furthermore, my reading of the memory_object protocol suggests that Mach's > designers already had this in mind. We don't need to design a cache > coherence protocol, since we've already got one. We just need to implement > it. I agree they certainly thought about it, but I really don't think it's complete. I understand what you want, and I'm all for it actually. Your results with your network server are already impressive. Good luck. -- Richard Braun
Re: Denial of service attack via libpager
On Mon, Aug 29, 2016 at 11:20:47AM +0200, Richard Braun wrote: > In addition, I've just thought about something else : if we handle > multiple clients, how do we make sure that two kernels, caching the > same file, don't just completely corrupt its content ? We'd need > some kind of cooperation to prevent the file being mapped more than > once I suppose, right ? Or, well, a complete cache coherence protocol, with a very large overhead per operation. -- Richard Braun
Re: Denial of service attack via libpager
On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote: > I should elaborate on what I found with exec. After I fixed the problem > with the exec server mmap'ing the library's ELF headers, it just got on a > little bit further in the process, and then croaked when it tried to mmap > the program binary itself. In addition, I've just thought about something else : if we handle multiple clients, how do we make sure that two kernels, caching the same file, don't just completely corrupt its content ? We'd need some kind of cooperation to prevent the file being mapped more than once I suppose, right ? -- Richard Braun
Re: Denial of service attack via libpager
On Sun, Aug 28, 2016 at 05:12:35PM -1000, Brent W. Baccala wrote: > So we still have to mmap across the network. We certainly don't want to > avoid mmap's entirely for program text and (especially) for shared > libraries. Although I admit that it would be best to detect when the mmap > fails and fall back on ordinary reads. Again, we could avoid mmap entirely by passing memory out-of-line, with copy-on-write zero-copy. When I say zero-copy, it means that the underlying memory will not be actually copied until accessed. > The obvious additional client would be a remote kernel, but as the exploit > program that I posted shows, it could just as easily be an unprivileged > process. You don't need much permission to get a memory object, just read > access on the file. OK, this comes from the fact that io_map directly provides memory objects indeed... Do we actually want to pass them around ? How come calls like memory_object_init (specifically meant to be used between the kernel and the pager) can be made from any client ? If we don't want to pass them around, we could instead let the server handle the mapping on behalf of the client, but this violates Hurd's principle of "mutually untrusting clients and servers". Although I personally believe this principle is impossible to apply in practice (one basic denial of service is to merely sleep and never wake up, where an explicit action from the user is required to break the ipc call, no different in practice from killing a process), I recognize the user might want to apply his own policy to the mapping, so it might be advantageous to allow passing the memory objects anyway. If we consider Unix as a reference, then the map call uses a file descriptor. It's equivalent to a memory object because the translation is done privately in the kernel, but we could also change the mapping interface to provide some proxy object to the client, which could be thought of as an unprivileged memory object. When mapping, the kernel would then invoke the proxy object to obtain the memory object, which, in addition to replacing mmap with COW zero-copy, solves the problem. What I'm stressing here is the importance of viewing a memory object as a private communication channel between the kernel and a pager. The changes involved here are heavy, which is one reason we'd want to avoid them. It also makes the system slightly slower by adding a new layer of abstraction. So we may just want to support multiple clients at the pager level, but I really don't see the benefit other than "it works". You really need to justify why it's a good thing that any unprivileged client is allowed to perform memory object management calls... -- Richard Braun
Re: exec server behavior
On Thu, Aug 25, 2016 at 12:20:45PM +0200, Richard Braun wrote: > I started thinking about these only a couple of weeks ago, and so far > the only solutions my limited brain can come up with is to either use > the client context (by perhaps passing its root) but that could cause > security issues, or have a third-party like auth (or proc or whatever) > store enough of this context that the server can use it. Of course the problem with these approaches is making sure the user context can be trusted by the server, something that other systems such as Plan9 don't have to deal with, allowing them to implement solutions like the factotum. -- Richard Braun
Re: exec server behavior
On Wed, Aug 24, 2016 at 07:24:16PM -1000, Brent W. Baccala wrote: > So, I'll modify libpager to handle multiple clients. Not trivial, but it > seems necessary and correct. Don't start that immediately, wait for more discussions. I'm not so sure it would make sense to support more than one client. > One question is whether the exec server really needs to do a vm_map to > examine an ELF header. A simple read would suffice. Which should be > preferred? I agree that read should be preferred. In a completely separate non-existent issue, it would be the only way to support nommu systems. > A more serious question is why the exec server is running on the server > side at all. Shouldn't it be running on the client? Then the only network > operation it would need is to map the one file that it's trying to execute. > > Examining diskfs_S_file_exec reveals some interesting behavior. The file > server caches a port to its exec server, so the same exec server gets used > by all of its clients! Furthermore, it gets the exec server in the first > place by looking up _SERVERS_EXEC in its own name space, not the client's! > > Shouldn't the exec server be looked for in the client's name space? You're getting into the same kind of "light virtualization" issues we have with e.g. chroot. Many operations are done by servers, from their execution context, and this breaks that kind of behaviour. I started thinking about these only a couple of weeks ago, and so far the only solutions my limited brain can come up with is to either use the client context (by perhaps passing its root) but that could cause security issues, or have a third-party like auth (or proc or whatever) store enough of this context that the server can use it. -- Richard Braun
Re: [GSoC] Implement xattr Support Update
On Fri, Aug 19, 2016 at 11:06:32AM +0800, Shengyu Zhang wrote: > GSoC is coming to an end. It is time to report my work during this summer. I've just completed the evaluation, everything is in order, and we'll have more time in September to really dive into the code, finish the review and merge it. Congratulations :) -- Richard Braun
Re: netmsg
On Mon, Aug 22, 2016 at 04:40:58PM -1000, Brent W. Baccala wrote: > I've gotten a basic netmsg server/translator running that relays Mach > messages across a TCP/IP connection. > > The code is available at g...@github.com:BrentBaccala/netmsg.git That's great. > It's got a lot of problems. No authentication handoff; everything the > client requests happens with the permissions of the server. exec'ing a > file doesn't work; the last RPC before the hang is memory_object_init. > emacs doesn't work; the last RPC before the hang is io_reauthenticate. That's a very interesting problem indeed, not sure how to fix it. -- Richard Braun
Re: Simple contribution please?
On Wed, Aug 17, 2016 at 10:50:56AM +0200, Samuel Thibault wrote: > Mmm. This is a clobber, so it's supposed to indicate what is written, > not what is read :) But I agree with the "move" rationale, let's be safe > (it doesn't really matter here, there's a memory compiler barrier at the > function call anyway). My thinking was rather to let gcc know that memory is being read so that it wouldn't generate instructions that might change it in parallel, although I don't think it's possible considering the instructions actually used. -- Richard Braun
Re: Simple contribution please?
On Wed, Aug 17, 2016 at 08:53:51AM +0200, Samuel Thibault wrote: > - also, in strstr, is it really better to use strncmp instead of strcmp? If I understand correctly, strcmp wouldn't behave right since it compares the terminating null byte. -- Richard Braun
Re: Simple contribution please?
On Wed, Aug 17, 2016 at 08:46:34AM +0200, Samuel Thibault wrote:
> - Are we sure that the direction flag is cleared on entry of the assembly
> snippets?
Yes, gcc makes sure it's cleared on entry. See [1] for reference.
> - I don't think the memcmp, strlen and strcmp snippets need a memory clobber?
I'm not sure. Nothing here tells the compiler that the memory
referenced is read and I don't know what kind of side effects this
could introduce. After a bit of research, I found this message [2]
which seems to support this thinking.
> - should we really use assembly snippets for strcpy and strcmp? In my
> non-virtualized tests, a simple C loop such as
> do { test = *dest++ = *src++; } while(test);
> actually goes quite faster thanks to the gcc optimizer, and the
> non-rep snippet won't buy virtualized time (and I guess we don't run
> str functions on memory-mapped devices anyway...)
Actually, assembly isn't used for these functions. Take a look at the
ARCH_STRING_XXX macros at the beginning of the file. These are used in
X15 to select between machine specific and generic versions, which we
could also use later.
--
Richard Braun
[1] https://gcc.gnu.org/ml/gcc/2008-03/msg00330.html
[2] https://lkml.org/lkml/2011/8/11/356
Re: Simple contribution please?
On Fri, Aug 12, 2016 at 09:16:02PM +0200, Richard Braun wrote: > Note that it's not that "simple" since we'd like implementations that > aren't naive, i.e. assembly with rep instructions. In particular, it > makes a huge difference in virtualized guests compared to C-based ones > because of vmenter/vmexit. When such functions are used on device mapped memory. -- Richard Braun
Re: Simple contribution please?
On Fri, Aug 12, 2016 at 07:57:48PM +0200, Samuel Thibault wrote: > It becomes more and more clear that we shouldn't steal functions from > glibc into gnumach, it poses cross-building issues from Linux. > > Could somebody contribute, or steal from a BSD the following functions, > to be included in gnumach/kern/strings.c? > > - memcmp > - memcpy > - memmove > - strchr > - strsep > - strstr Note that it's not that "simple" since we'd like implementations that aren't naive, i.e. assembly with rep instructions. In particular, it makes a huge difference in virtualized guests compared to C-based ones because of vmenter/vmexit. -- Richard Braun
Re: Fwd: Hurd shutdown problems
On Fri, Aug 12, 2016 at 09:07:48PM +0200, Samuel Thibault wrote: > > I'm curious: what makes it definitely wrong on a PC ? > > A PC has BIOS stuff between A and 10. Right, misread a 0 again. -- Richard Braun
Re: Fwd: Hurd shutdown problems
On Fri, Aug 12, 2016 at 07:53:08PM +0200, Samuel Thibault wrote: > That's what I'm talking about, and that's the second part of the printfs > above, and they are wrong: 1-100 is definitely wrong on a PC, > and it includes the debugging symbols. I'm curious: what makes it definitely wrong on a PC ? > Yes, but only the heap. The load of segments not containing the heap is > full: > > vm_page_load 1-100 1-100 > vm_page_load 7a00-7ffe 7a00-7ffe That's indeed a problem, and one that I don't see in X15... I guess I didn't have the case where a segment didn't clip with the heap until now, in which case, instead of being completely loaded as available, it should be loaded as reserved, and only later made available. -- Richard Braun
Re: Fwd: Hurd shutdown problems
On Fri, Aug 12, 2016 at 07:57:10PM +0200, Richard Braun wrote: > On Fri, Aug 12, 2016 at 05:17:26PM +0200, Samuel Thibault wrote: > > biosmem: heap: 114f000-7a00 > > > > and objdump shows: > > > > LOAD off0x1000 vaddr 0x8100 paddr 0x0100 align 2**12 > > filesz 0x00114700 memsz 0x00114700 flags r-x > > LOAD off0x00116000 vaddr 0x81115000 paddr 0x01115000 align 2**12 > > filesz 0xd151 memsz 0x00039384 flags rw- > > > > It seems biosmem's heap doesn't even exclude the kernel data?! > > Could be a mistake with regard to the linker script. Misread it too :). -- Richard Braun
