What's the recommended cpp for building the gate with?

I just tried with github.com/illumos/cpp and the build blows up

with /usr/include/sys/isa_defs.h: 380: undefined control

which I think comes from

dtrace: failed to compile script ../port/threads/plockstat.d: Preprocessor failed to process input program

OmniOS uses github.com/omniosorg/cpp but it doesn't look like there is too much omnios-specific in that fork

It seems like omniosorg/cpp ffd0447 might be important though

has anyone looked at the recent openssh rce? It looks like _maybe_ illumos wouldn't be impacted, but there's enough going on in our syslog() implementation that i don't feel particularly confident in that assessment

[illumos-gate] 15685 iscsi: the comparison will always evaluate as 'true' -- Toomas Soome <tsoome⊙mc>

Reading on the openssh rce, given that it's a regression due to a missing #ifdef, then simply putting the #ifdef back ought to be a quick fix

Looking at the freebsd ports collection, that's essentially what they've done

Debian too - and it's the approach we're taking in omnios, other than in bloody where we will jump to 9.8p1, although that's not being as easy as I'd hope.

Yeah, I had a look at 9.8p1 and it's quite a large change, so punted on that and went for the quick fix instead

The other regression around chaff packets doesn't worry me as much

openwall.com/lists/oss-security/2024/07/01/2 has minimal patches for both bugs

andyf, if you need a test host for the updated sshd package for OmniOS let me know. I can drop it on the boxes I've been doing testing on.

nomad - pkg update -g pkg.omnios.org/r151046/staging openssh openssh-server

I don't think it will be too long before the update is published, like everyone else.

I've dropped it on fs2, one of the two test hosts.

aside from "can I still ssh in" are there any other tests you'd like run?

No, if it still works, that's good enough for this patch, thanks!

no problems.

kerberos ssh was unchallenged, un-ticketed ssh required a password for a valid account.

9.8 is a PITA.

We're respinning 20240627 to #if-0-out the async-unsafe code like OmniOS. Testing it now.

I'm looking at the dotnet port, and comparing illumos vs Linux behavior. To my surprise, this works on linux:

p = mmap(0, 2494763008, PROT_NONE, MAP_ANON | MAP_PRIVATE, 0);

Yes, that's 2GB of anon space.

Conceptually, it wants to "reserve" that space, maybe not actually allocate pages (not sure about that).

that's classic linux overcommit, no?

you ask for memory, and linux says yes as long as _virtual_ memory exists

maybe so

You may want MAP_NORESERVE.

That's pretty common in some of these ports if you don't mind getting a SIGBUS when you try to fault in the page.

yeah, that's where I was heading

Given it's an attempt at creating a deliberate hole. But that's assuming it'll never mprotect it back on.

I'd assume it's trying to make itself a contiguous heap

it's got that vibe, at least.

for the managed heap, that is

Ah, in that case the NORESERVE may be a bit spicier. But IIRC node.js did it a lot of the v8 heap with NORESERVE but it's been a long time.

Yeah, it's setting up a heap (dotnet uses potentially multiple heaps and garbage collection... quite complex)

I think MAP_NORESERVE will give you something approximating the linux behaviour, but it's hard for me to reason about because I don't really think the linux behaviour is ok

Would MAP_NORESERVE give me similar behavior as what the Linux mmap allowed?

I believe this will actually go touch the pages. I can try and see :)

The semantic difference between us and Linux here is that when you mmap and you later go to allocate the page, do you expect it to work or fail.

Well, do you want a guarantee it'll work vs. chance it'll fail.

If it's going to do touch the pages, it'll change the protection on them I assume.

right.

If basically you don't want a guarantee that you can use the pages you allocate, then sure MAP_NORESREVE will give you that I guess.

As it actually allocates segments for its heap manager.

right, the question is "does that manager handle SIGSEGV and SIGBUS" here, and it probably does for the garbage collector etc.

so I would say MAP_NORESERVE is at least close to what you want

if you want to be thorough, cause a lot of actual pressure for memory

it's going to be handling the protections, and faults on, the heap constantly regardless for the GC, so the common case it should give it exactly what it wants.

the problem is the case where there's no pages there for it

Still fails when asking for a little over 2GB (in a 64-bit program) using MAP_NORESREVE

What is the full invocation?

I wrote a sample program and it's working fine.

You're missing an arg there.

You're specifying -1 for the fd?

and 0 for the off?

not the other way around :)

not that I've ever tried that...

nevermind. bug in my test program.

32 lines of code, bug count = 2 :)

Maybe time for a break :)

Not too bad a ration for C.

*ratio