tsoome: does loader efi have some option to load a kernel via http or nfs? I would like to forge a USB EFI image that I can insert into our bHyve and boot. I would like to use static Ip for that. I see our pxeboot would work but I don't want DHCP on that etherstub

you can use tftp or nfs

but, loader enbaled network access on network boot (pxeboot)

enables*

let me check efi version however ...

hm, efi version does list net0:, but apparently we do not have option to set address locally, so it is still expecting the pxe boot to get address from dhcp or rarp

yep, if loader.efi does get dhcp response with root-path (like: option root-path "nfs://192.168.150.37/export/omni";) then you can set currdev=net0: and use that path.

bios version is more complicated, but if we do not provide bios for bhyve, then it does not matter anyhow

we can add support for static config too, ofc. but thats current default.

Yeah, I think we should provide those options. or find a way how we can do EFI stub like linux does so loaders like ipxe can load our kernel wehn in UEFI mode.

HTTP and HTTPS support would be awesome too :) with mTLS

efi stub by itself is totally different thing.

anyhow, need to go afk atm

Can someone confirm that unless you allocate more than 2^48 bytes of memory, 64-bit illumos user programs will have 0xffff as their top 16 bits?

(i.e. we start high and work our way down... yes I know it's actually a figure less than 2^48 because of USERLIMIT but an unnamed piece of software is assuming those high 16-bits are zeroed.)

what is actually happening danmcd?

the stack starts high and grows down, the heap starts low and grows up.

Node 24 is trying to update its v8 engine. The v8 engine, at least the one that is crashing on my local builds and their Jenkins ones, fails because it seems to use in some small place 0xFFFF000000000000ULL as a bitmask for marking pointers.

So with debug-by-printf I see this this:

that sounds like the thing openindiana work around in /etc/system, by poking the kernel limits

I think it bad for a project to assume what bits are and aren't available to them.

Hell, since we start at 0xffff, maybe we should build a "clear-bits-if-in-freelist" version?!

I think you're looking for the openindiana workaround, but I can't remember what it is.

See $UTS/i86pc/sys/machparam.h for what it does for ifdef xpv...

I bet OI might Just Be Doing That all the damned time.

so openindiana just take the high few bits off the address so that they're spare

Approx line 231 of said file.

yeah, just about

so if you drop that in /etc/system.d, do things change?

if they do, we should probably talk with smart people about doing it properly.

I haven't tried it yet richlowe, but maybe I should build a PI that does?

I would, I think it will work

I'm just not sure if their confidence 128TB of address space is enough holds here in the weird future :)

I'm not sure who the burden of "doing it properly" rests upon, but to my mind, this feels like laziness on the v8 side.

I do see richlowe that the LX brand does this for its own processes in userland.

kebe(src/uts)[0]% git grep -i LX_MAXSTACK64

common/brand/lx/os/lx_brand.c:#define LX_MAXSTACK64 0x7ffffff00000

common/brand/lx/os/lx_brand.c:uint64_t lx_maxstack64 = LX_MAXSTACK64;

common/brand/lx/os/lx_brand.c: args->maxstack = lx_maxstack64;

kebe(src/uts)[0]%

right, to look linux-y and get those bits

^^^

What's the QUICKEST (not cleanest/production-ready-ist) CPP symbol to indicate "This is illumos-or-even-Solaris" ? Is it `__sun` ?

It's __illumos__ if you just want illumos - that should be production ready these days, or __sun if you do want to include Solaris.

that 48-bit pointer mask is clearly not going to play well if you have 5-level paging enabled (which allows up to 57 bits of VA)

default openindiana install does indeed limit user va space to end at 0x7fffc0000000

somewhat complicates writing tests for overflow in pointer math if you can't map stuff in the upper half of the 64-bit space.

We don't have 5-level paging yet, but yeah that would be a problem.

this is all what I meant by "doing it properly" above, I think.

I'm not sure convincing 3rd parties to care about memory maps is necessarily practical, unfortunately.

does x86 have something like ARM's TBI these days?

("top byte ignore", it completely ignores the high byte of addresses)

so you can look up (user)-tagged pointers without masking

danmcd: we don't have 5-level, but linux does. Surprised that nobody has grumped about it on linux, if only to get more space for ASLR on biggish processes on new machines..

richlowe: "linear address masking" looks to be the x86-ville equivalent of TBI

It introduced more spectre attack surface: ieeexplore.ieee.org/document/10646870

ah, AMD does "UAI" which appears to be closer to TBI (ignores 8 bits in the top byte); UAI_57/UAI_48 do not mask bit 63 (the "sign bit") of the address

I'm engaging v8. This shit's code doesn't match its comments!!!

Uggh, It's a Process over there. I'm gonna screw around locally and see if my local screwings around help. I'm NOT bringing in the big-guns of hacking pointer bases yet.

I mean, look at these pieces of the v8 engine:

and tell me something's not sketchy here. (Read on down after the first highlighted line link. Code doesn't match comments.

danmcd: on the fdclose() thing - passing NULL is a convenience for when the caller already dknows what fileno(f) is. Doesn't necessarily result in an fd leak.

Okay... it should be in the man page, though.

Yes.

danmcd: and of course, in the upper bits, things are different between SPARC & x64 (though I know illumos proper doesn't care any more)

though if I'm remembering correctly, that may be because later SPARC MMUs already have 53 bits of VA in use

I know with spidermonkey (Mozilla's equivalent to v8) we have to link on SPARC with /usr/lib/ld/map.vas47 to mark anything above the 48-bit limit as "reserved" so the system won't put any pages up there

You can implement that in the v1 language, but not the v2 language as we have it

it would be easy to add to the v2 language though.

I'm pretty sure I mentioned the specifics in a bug report where postwait was trying to wall off all memory below 4G for lua