Re: #pragma once

[Steffen Nurpmeso]

Mouse wrote in
 <202210152055.qaa24...@stone.rodents-montreal.org>:
 |> Traditionally to avoid problems with repeated inclusion of a header
 |> file, you put #include guards around it, say in sys/dev/foo.h:
 |> [...]
 |
 |> With newer compilers this can be replaced by a single line in the
 |> header file:
 |
 |> #pragma once
 |
 |Some newer compilers, perhaps.  Unless and until it is standardized,

tcc yes, pcc not.

  ...
 |> It's nonstandard, but using  #pragma once  is maybe a bit less
 |> error-prone -- don't have to have to pollute the namespace with

Wow.  I have never seen such an error.
(In fact _i_ use multiple inclusions consciously in a number of
places, and have always done so.  This would not change, of
course.)
If it would have been a different poster i would have thought it
is April 1st, actually.  #pragma once.  Hey.  It is a good thing.
I think it would have been cool to have it twenty years ago, most
of you would surely agree more so a decade or two earlier even.
Somehow they must have missed to implement it in the 70s.
(I personally struggle with

  #?0|kent:pcc.git$ xz -l /usr/ports/built/tcc#20220817-1.pkg.tar.xz
  Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
  1   1239.1 KiB   1149.5 KiB  0.208  CRC64   
/usr/ports/built/tcc#20220817-1.pkg.tar.xz
  #?0|kent:pcc.git$ xz -l /usr/ports/built/gcc#12.2.0-1.pkg.tar.xz
  Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
  1   1 47.6 MiB204.9 MiB  0.232  CRC64   
/usr/ports/built/gcc#12.2.0-1.pkg.tar.xz
  #?0|kent:pcc.git$ xz -l /usr/ports/built/clang#15.0.2-1.pkg.tar.xz
  Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
  1   1 90.8 MiB945.9 MiB  0.096  CRC64   
/usr/ports/built/clang#15.0.2-1.pkg.tar.xz
  #?0|kent:pcc.git$

but likely i am addressing the wrong people.)

A nice Sunday everybody.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: regarding the changes to kernel entropy gathering

[Steffen Nurpmeso]

Btw i track 

  https://github.com/smuellerDD/jitterentropy-library.git

for about two years, and i "never" (which is a couple of years at
least) understood why something like this isn't simply used.
For example in the myriads of times the scheduler runs each
second, a little bit of that can be done on pretty compact local
data.

Quite honestly speaking, this random and bits-worth shit always
annoyed me, not being mathematician, as most terrible pseudo
chatter.  Incorporating things like rdtsc with applied intermixing
etc. to pimpen an entropy that as such is never revealed in order,
not to talk about only serving bytes generated through it by
cryptographical checked digest algorithms.  I at least always
mixed low-order/high-order bits.  Wow.

Yes it is unscientific.  But whereas the new OpenSSL RNG
mysteriously can fail (which it never did in the past), the Linux
kernel now uses a pretty simple (last i looked) such wait-and-mix
thing to overcome the seeding-blocks problem.  So i (who still
uses random-entropy devastating Python Mailman to serve minor MLs)
have to use haveged, which, whereas the kernel with the I/O, the
network, the process starts, the mapping( addresse)s, the (VM host
served) timers etc., generates a bit of random in a second (or
something like that, last i looked), generates thousands and
thousands of bits of entropy at a glance.  That is sick.

Hopping off,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Restricting rdtsc [was: kernel aslr]

[Steffen Nurpmeso]

Maxime Villard  wrote:
 |Having read several papers on the exploitation of cache latency to defeat
 |aslr (kernel or not), it appears that disabling the rdtsc instruction is a
 |good mitigation on x86. However, some applications can legitimately use it,
 |so I would rather suggest restricting it to root instead.

I have used it for random noise in user space.  I don't want to
paste it, it is so ridiculous…, but then again a nice example of
user space horror – you may skip the rest at your will.

 |The idea is simple: we set CR4_TSD in %cr4, the first time an application
 |uses rdtsc it faults, we look at the creds of the lwp, if it is root we

I used it to add noise to my ARC4 random generator upon ()()/call()
time, as in

// strong (noisy) generator?
if(m_d.flags & f_strong) {
#if(__HAVE_RAND_CRYPTOHW)
if(__RAND_CRYPTOHW_OK) {
ret = ::__sf_sys_misc_rand_Strong();
goto jout;
} else
#endif
addNoise();
}


where this was

#if(__HAVE_RAND_CRYPTOHW)
if(!m_d.enpy)
goto jout;
#endif
#if(!__HAVE_RAND_NOISE)
ep.now().setSecond(ep.second() ^ ep.microsecond())
.setMicrosecond(_WEAK(ep.microsecond()));
addNoise(ep.tv(), szof(Epoch::TimeVal));
#else   
x = ::__sf_sys_misc_rand_Noise();
stack[0] = x;
x = _WEAK(x);
stack[1] = x;
addNoise(stack, szof(stack));
#endif
#if(__HAVE_RAND_CRYPTOHW)
jout:
#endif  

and that with args did a loop that used "random" bytes of the
given "stack" as noise additions to the internal entropy (and
doing one ARC4 stir after each addition).

 |What about this?

No longer of any value, it seems to me.

--steffen

Re: shipping processes between ttys

[Steffen Nurpmeso]

Christian Koch cfk...@sdf.lonestar.org wrote:
 |On Sun, Dec 07, 2014 at 07:02:42AM -0700, Andy Ruhl wrote:
 | I hate to ask an obvious question, but what is the application \
 | of this in a
 | world where screen exists? I went to the link and it says when you
 | forget to start something in screen which seems like the only obvious
 | reason to use something like this. Although screen isn't perfect I
 | suppose...
 |
 |This was the first thought that entered my head, as well. \
 |tmux(1) ships with the
 |base NetBSD system already, and I use tmux all the time for this express
 |purpose.

I thought the idea is pretty cool: you would loose a server and
a lot of I/O indirection via pseudo ttys.  Of course you'd loose
some (read: quite a lot of) flexibility regarding what can be
done.  It wouldn't work for my very own use case, which benefits
the most from the identical environment wherever i am paradigm;
and to get there i build or install screen, copy my usual config
file environment and am ready to go.  And screen(1) (ok ok, and it
is GNU, _but_):

  ?0[steffen@sherwood ]$ pla|grep -i screen
  steffen288   0.0  1.6  2482128  33760   ??  Ss   Mon10am   0:22.43 SCREEN
  steffen287   0.0  0.0  2435396 60 s000  S+   Mon10am   0:00.21 screen

That is just sensational given the amount of data that has passed
all those windows, just take these numbers of my MUA:

  Memory statistics:
Count cur/peek/all: 715/895/738364
Bytes cur/peek/all:  151782/ 872707/2913078747

  String usage statistics (cycle means one sreset() cycle):
Buffer allocs ever/max a time : 1/1
.. size of the builtin/dynamic: 8152/61400
Overall alloc count/bytes : 117043/6615192
.. bytes min/max/align wastage: 8/1080/329504
sreset() cycles   : 607 (440 performed)
Cycle max.: alloc count/bytes : 4680/269488+199936

not to talk about all the directory listings, git(1) log listings
and manual page views...

And i think it would be cool if NetBSD would reintroduce
cdrom.iso's, so that there would be a single image that works
offline.  At least you're done once you've got all the balls you
want in addition.

--steffen

Re: Proposal: kmem_valloc [was: Re: raspberry pi panic 7.0_BETA after install fs resize]

[Steffen Nurpmeso]

Maxime Villard m...@m00nbsd.net wrote:
 |  - kmem_intr_zalloc
 |After all, kmem_intr_zalloc is not needed since the caller can simply do
 | ptr = kmem_intr_alloc(...);
 | memset(ptr, 0, ...);

Well i never looked into the source but for my very own thing it
was a major benefit to pass a zero flag down to the bottom since
it allowed zeroing the real range, which was always on an aligned
boundary and of an aligned range (multiple of eight or sixteen,
multiple of pagesize for larger allocations), therefore ending up
using the fastest memset path without need for pointer alignment
and without the need for a do-the-remaining-byte thing, which
resulted in measurable boosts (and that on x86, but in artificial
use cases, of course).

--steffen