rmustacc always userland... I'm not smart enough for kernel-land :))) I ended up using chroot

Where did you chroot into?

I mean, I wouldn't sell yourself short on the kernel. It's just software!

rmustacc /tmp/onu.XXXX

I see. I wouldn't generally recommend that path, but if it's working for you, it's working.

rmustacc yeah... but I really need to understand C better... Pascal spoiled me with its proper syntax :P

rmustacc so... does that mean that the "proper" way is to always reboot into the BE?

"proper" yes, but there are safer and less safe shortcuts depending on the differences that are present between your build system and what you're building.

For example, if the libc/kernel sytsem call interface changed, running in the chroot would fail.

But also if you just changed a single command, then it's much easier to just work and run it directly (depending on specifics).

[illumos-gate] 16234 BIOS PCI detection failure results in only bus 0 being enumerated -- Andy Fiddaman <illumos⊙fn>

rmustacc may I ask, what do you mean by "running it directly" ?

antranigv: I suspect he means you can just run the built binary out of the illumos-gate tree. as always, details matter, but many things can be tested directly in-tree

antranigv: What did you modify?

rmustacc cut(1). I'm having a hard time using bldenv to compile the AST contrib individually... also, how the hell does cut not have a main function? :D

Because that's not how ksh works.

By that I mean, that the construction of ksh (which doesn't come from us) is that it compiles all these things that are built-ins.

And so it's just a bit different.

What's failing about running 'dmake install' in usr/src/cmd/ast? I may be able to give you more specific things / next steps based on what's going on.

I got confused... isn't usr/src/contrib/ast/src/lib/libcmd/cut.c the source of /usr/bin/cut ?

trying now

It is, but not where you build it.

I see

The contents of contrib are basically things taken directly from an upstream.

that... I do get! I always check contrib/bhyve :D

dmake: Fatal error: No arguments to build ; Current working directory /code/usr/src/contrib/ast

Correct, I wouldn't expect that to work.

try usr/src/cmd/ast/ksh/builtins

heh.. we still have some class action scripts in the gate apparently.. figured those all went away with pkg(5)

[illumos-gate] 15991 SMB long readdir should be cancellable -- Matt Barden <mbarden⊙rc>

[illumos-gate] 16068 Want umem debugging enabled for DEBUG-built idmapd -- Matt Barden <mbarden⊙rc>

What I don't get is, why is dmake calling /opt/onbld/bin/amd64/ld instead of the other ld in the system build0.illumos.am/log/builtins.log

bad paths! fixed

Nice, were you in a bldenv? That should have taken care of everything

btw, if you are fixing something in `cut`, it is worth checking for any patches at github.com/ksh93/ksh - that's the continuing development of the ksh93/ast stuff. One day we might switch to that instead of the version we currently have, but for now we generally cherry pick fixes from there if they've already fixed something we hit.

andyf I was in bldenv indeed. I did some changed to cut.c, but I can't see it in the proto :( maybe I'm doing something wrong, I read the Makefiles again

andyf that sounds like something I'd be interested in working on... I'll get more into the code of ksh and see what I can learn

Do install it into proto, you need to `dmake install` (or `make install`)

did

Still the same

in a bldenv, you should have $ROOT set, so it should be $ROOT/usr/bin/cut

oh, maybe I can compare hashes to see if something is modified or not

Root is ALSO set

hah, bldenv does many things, turns out

`cut` will be a hard link to `alias` if I remember correctly

On my system, see - paste.ec/paste/ciY6QYsO#ycY2dtXerT4XIyYGosOvCCcRbHpsGDbbv6cOgGku8fe

I don't what Mr. Korn has done here, but everything seems to be somehow generated.

like even the man page is written in the .c file

Yes, it was controversial when first integrated into Solaris..

But we did get David Korn breakdancing youtube.com/watch?v=UwHufBvUdn0

ptribble is that Alec Muffet?

oh god, I totally forgot that he used to work at Sun

I don't *think* Alec was there

ptribble then I must be confusing faces. I *did* forget my classes today

glasses*

It's been a while, I would struggle to put names to all the faces now

damn, I forgot the zfstest will destroy all other disks but boot disk :/

The good news is that thanks to andyf fixing the ena driver I no longer see my EC2 nitro instances go into a panic loop when I enable static networking

An oddity is that the instances have lost the Time Of Day clock, which means that 'sleep 10' takes more like 40s

Ah right - you need to do something like 'echo set pit_is_broken = 1 > /etc/system.d/pit'

And I don't believe the reported clock speed of 11050 MHz

Until illumos 16222 is integrated, which will extend the vmware time source to encompass EC2 instances too (well, KVM with the frequency leaf feature enabled, which it is by default)

illumos 16222 fenix

BUG 16222: TSC vmware calibration could be more general (New)

↳ illumos.org/issues/16222 | code.illumos.org/c/illumos-gate/+/3251

Thanks! That seems much better.

11GHz is ok - I had one instance boot with a clock speed of 9MHz

Does illumos have any kind of source-code level security? For example, FreeBSD has Capsicum, OpenBSD has pledge, unvail, and gezilion other things. What is implemented (or wanted) in illumos?

Source-code level security being a security feature implemented at the software level, not the operator layer. If that even makes sense.

Yes, privilege dropping and related is somewhat similar to pledge.

Though a bit different in nature / execution.

A prime use case and example are daemons or tools dropping priviliges which may be administrative powers or basic privileges like fork(2).

A great example is bhyve, which drops a lot of privileges once it no longer needs them - for example: paste.ec/paste/FwXjvpZ4#pZCbGAmK0SgLfQVP7ehajbcEoiDNqigsMgkDj0Ly+5U

that's really nice!

The pcieadm command also does something similar. It drops most privileges, but retains the ability to read from a device, but temporarily drops it while parsing the binary data.

is that code upstreamed too with ifdefs???

that might be a nice task for a CTF

find where the code is misusing a privilage and exploit at that part

We can also use privileges to do things like allow a web server process to open port 80, without needing to be root, and make binaries like traceroute gain access to raw ICMP but nothing else extra. If you want some further reading - illumos.org/man/7/rbac / illumos.org/man/7/privileges

Soo many things to learn. I was planning on reading the OpenSolaris Bible or Solaris Internals book, but the man pages are really good anyway

I compiled the system, I modified a file (cut.c) and then I did `make install`. I checked the sha1sum before and after, and it's the same :/

I'm doing something wrong for sure

I think the actual implementation of `cut` is in `libcmd.so`

yep, the /usr/bin/cut executable is also about 28 other executables -- ls -li and look at the link count and inode number, and then "find /usr -inum xxxx" to find its other avatars; it looks at argv[0] and dispatches to the desired program within libcmd

andyf: so I have function entry/exit dtrace probes working again in python 3.12

Oh, that's fantastic. I am hopeful we can get the ustack helper functional again, but it has been stuck behind that. How did they break it going from 3.10 to 3.11?

they deleted a bunch of DTRACE_FUNCTION_ENTRY() and DTRACE_FUNCTION_EXIT() macro invocations. Put them back (and put back the helper functions they call if the probe is enabled) and you're back in business

the helper function needed a little porting to get the line numbers

Don't have the "line" probe building just yet - there was more change to that.

you poor soul

I'm sorry

jlevon - oh, the ustack helper is on top of this I imagine. I got it working again in 3.10 and it was incredibly useful. I really missed it in 3.11

if you've heard the joke about the engineer and the hammer, well, I feel like that guy now.

Someone raised an issue about `pkgrecv` doing a chown on the catalogue at the end, and dtrace would have been so quick to find out which bit of python code was responsible. With the ustack helper in particular.

sommerfeld - I brushed off my branch last night and there still a lot of test failures that I haven't got to the bottom of yet. A lot of the tests work when run by hand.. sod's law.

andyf: flaky tests are a menace

A slew of them were due to not compiling the socket module with XPG6 at least (to expose CMSG_* and the new recvmsg() semantics)

[illumos-gate] 16247 zfs-tests: default_raidz_setup should use all provided disks -- Toomas Soome <tsoome⊙mc>

is there any way to power off a specific pci device (e.g. nvidia gpu on a laptop)? , or something like freebsd where any device without a driver can be powered off?

xaero: maybe see what shows up with cfgadm -al

xaero: In that world are you referring to changing the device's power state (i.e. go to D3) or using the PCIe slot control register to cut off power because there's an actual power controller on the system.

sommerfeld when you say "they deleted a bunch of...", who's they? they python team? and if so, why did they delete that? and finally, if that gets enabled in upstream, will it be available in the pkgsrc version as welll?

antranigv: Slow down. "They" = the upstream python maintainers, at some point during the development of 3.11. they didn't understand what the hooks did, and they were reworking code around them, so they deleted them.

antranivg: I first put them back yesterday afternoon, and first told others about it this morning. Haven't heard back from any python insiders yet.

(that's to say, put them back in my development copy of oi-userland).

as to where they will appear? I hope in openindiana and omnios's packaged pythons. upstream python may be resistant.

gosh stacks from python would be delightful

We should figure out how to put that into pstack as well :P

I wonder how hard it would be to produce a context in which you could just run the existing ustack helper inside the pstack process

jclulow: there is an mdb plugin for python stacks that works through python 3.9

porting it is on my todo list

(which is to say, I've bludgeoned it into building for 3.12 but haven't tried to get it to work yet)

pstack has some hooks for java and python.. i'm guessing they no longer work?

doesn't seem to kick in. Looks like it's trying to load the same thing mdb is loading. unclear why it fails to load for pstack but works for mdb

truss says it opens and mmaps /usr/lib/amd64/libpython3.9_db.so.1.0 so it must be something further along that's missing.

is that built in illumos-gate, or by python?

that's built by python.

it looks like it looks for 3 symbols, and also expects PYDB_VERSION to be 1

(at least obviousl things that'd cause it to fail)

oh!

python likely not built with the option to force a frame pointer

it gets to print_frame() but argc is zero, I think.

pydb_pc_frameinfo() is returning -1

aha!

missing -msave-args perhaps?

jclulow: I don't think making the D vm execute in that context would be... too bad.

Especially if you don't have to support every action.

[illumos-gate] 16244 DFv4 DRAM Offset register is incorrect -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16249 SMB C$ share should require administrative privileges -- Gordon Ross <gwr⊙rc>

nope, -msave-args is insufficient.

ah, needs ctf to get argcount

That's exciting