Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

[Michael van Elst]

mar...@duskware.de (Martin Husemann) writes:

>I agree with both. Leave it an admin decision (and maybe default to
>"encrypt"). Also assume that it is possible to complete enough of /etc/rc.d
>without any swapping ;-} so a simple setting in /etc/sysctl.conf will do.

If you don't allow to disable encryption, the code could be simplified to
not track encrypted and non-ecnrypted parts of the swap. Instead the
setting should be fixed before swap is enabled. Otherwise you still end
with unencrypted bits in the swap partition.


-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

[Martin Husemann]

On Mon, May 18, 2020 at 06:21:10PM -0400, Mouse wrote:
> >> Always encrypted swap would be even better but ... slow machines.
> > Compared to the time required to put the pages out to disk?
> 
> That comparison is relevant only if the system has nothing better to do
> than wait for the page out/in.  A few systems probably don't.  Most, I
> suspect, do, and if there _is_ something else the CPU could usefully be
> doing, I suspect spending the (scarce) cycles there is preferable.
> 
> At least for most systems.  There certainly is a place for allowing the
> admin to insist on encrypted swap even on slow machines.

I agree with both. Leave it an admin decision (and maybe default to
"encrypt"). Also assume that it is possible to complete enough of /etc/rc.d
without any swapping ;-} so a simple setting in /etc/sysctl.conf will do.

I can run tests on slow + small memory machines (but not really sure what
a good test would be - maybe compiling a few things with MAKE_JOBS >= 2 from
pkgsrc?).

Martin

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

[Mouse]

>> Always encrypted swap would be even better but ... slow machines.
> Compared to the time required to put the pages out to disk?

That comparison is relevant only if the system has nothing better to do
than wait for the page out/in.  A few systems probably don't.  Most, I
suspect, do, and if there _is_ something else the CPU could usefully be
doing, I suspect spending the (scarce) cycles there is preferable.

At least for most systems.  There certainly is a place for allowing the
admin to insist on encrypted swap even on slow machines.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

[Taylor R Campbell]

> Date: Mon, 18 May 2020 17:51:51 -0400
> From: Thor Lancelot Simon 
> 
> On Mon, May 18, 2020 at 09:08:14PM +0100, Alexander Nasonov wrote:
> > matthew green wrote:
> > > what's the use-case for disabling encrypted swap later?
> > 
> > It might be too slow on some machines.
> > 
> > > i'd argue we should avoid kauth for this and simply disable
> > > it always as i've been unable to think of any use case that
> > > is the only solution.
> > 
> > Always encrypted swap would be even better but ... slow machines.
> 
> Compared to the time required to put the pages out to disk?

If anyone is concerned with the overhead of encryption on top of the
cost of swapping to disk, we could:

1. Always prohibit disabling it for now -- no new kauth required.
   Wanna disable it, gotta reboot.

2. While it is off by default, measure the additional impact on slow
   machines of doing the bit of extra computation when we're already
   swapping.

3. Decide on the basis of (2) whether, if/when we later flip on
   vm.swap_encrypt=1 by default, to add a kauth to control whether it
   can be disabled at all, or whether to just always encrypt swap
   unconditionally and forget about the bad old days when we wrote
   ephemeral memory out to nonvolatile storage in cleartext.

> Could try chacha8.

This does not work on its face, because we may need to encrypt many
different pages over time in the same swap slot, and the only
additional input available is the swap slot number.  That's why I
chose AES-CBC with iv=AES_k(slotno).

To use ChaCha8 with the same key and same slot number twice we would
need to maintain a nonce to distinguish the two versions, which adds
extra storage when we're already swapping.

We could improve on it by using a better wide-block tweakable PRP
construction than CBC, and by using a better primitive than AES, but
that would require slightly more work and thought that may not be
worthwhile.  (My calculus last weekend was that I wanted to make swap
encryption JFW, preferably some time over a decade ago.  My calculus
for a rainy day later on depends on the results of measurement.)

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

[Thor Lancelot Simon]

On Mon, May 18, 2020 at 09:08:14PM +0100, Alexander Nasonov wrote:
> matthew green wrote:
> > what's the use-case for disabling encrypted swap later?
> 
> It might be too slow on some machines.
> 
> > i'd argue we should avoid kauth for this and simply disable
> > it always as i've been unable to think of any use case that
> > is the only solution.
> 
> Always encrypted swap would be even better but ... slow machines.

Compared to the time required to put the pages out to disk?

Could try chacha8.

-- 
 Thor Lancelot Simon t...@panix.com
  "Whether or not there's hope for change is not the question.  If you
   want to be a free person, you don't stand up for human rights because
   it will work, but because it is right."  --Andrei Sakharov

Re: sys/idtype.h unused enumeration values

[Christos Zoulas]

The *used* enum values are already burned into existing programs.
Reordering/removing from the list breaks ABI. They are best left alone.

christos

> On May 18, 2020, at 4:55 PM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> On 18.05.2020 22:18, Christos Zoulas wrote:
>> 
>> 
>>> On May 18, 2020, at 3:40 PM, Kamil Rytarowski  wrote:
>>> 
>>> If I delete P_TASKID ... P_P_CPUID ones, P_SETID will be reordered (but
>>> we can force the number anyway). If I delete P_CID there is an inelegant
>>> hole. Naturally P_SETID -> P_CID can fill the gap.
>>> 
>>> This is in theory ABI change, but no users could use in a useful
>>> approach previously.
>>> 
>>> My intention isto g/c unused values and keep this clean and elegant (as
>>> this is still possible).
>>> 
>> 
>> Why don't you leave them alone for the same reason FreeBSD did (source 
>> compatibility)
>> and append the ones you want? If you look they #define P_ZONEID P_JAILID when
>> they made the change...
>> 
>> christos
>> 
> 
> My point is that there is no source code (at least in base) that we gain
> compatibility with, no ABI compatibility layer and these concepts do not
> match the current NetBSD kernel features. If there is anything in 3rd
> party pretending to use these values, it would not work anyway.
> 
> If we want to these compat defines, they already live in:
> 
> external/cddl/osnet/dist/uts/common/sys/procset.h
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=170346 
> 
> 
> Regarding FreeBSD, I don't see rationale for inclusion of these values.
> It looks like it was copy-pasted (there were also Solaris-specific
> preprocessor guards in the initial version).
> 
> But if there is intention to keep these values around (as it might be in
> theory too late as they leaked somewhere), it's fine. Thanks.
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: sys/idtype.h unused enumeration values

[Kamil Rytarowski]

On 18.05.2020 22:18, Christos Zoulas wrote:
> 
> 
>> On May 18, 2020, at 3:40 PM, Kamil Rytarowski  wrote:
>>
>> If I delete P_TASKID ... P_P_CPUID ones, P_SETID will be reordered (but
>> we can force the number anyway). If I delete P_CID there is an inelegant
>> hole. Naturally P_SETID -> P_CID can fill the gap.
>>
>> This is in theory ABI change, but no users could use in a useful
>> approach previously.
>>
>> My intention isto g/c unused values and keep this clean and elegant (as
>> this is still possible).
>>
> 
> Why don't you leave them alone for the same reason FreeBSD did (source 
> compatibility)
> and append the ones you want? If you look they #define P_ZONEID P_JAILID when
> they made the change...
> 
> christos
> 

My point is that there is no source code (at least in base) that we gain
compatibility with, no ABI compatibility layer and these concepts do not
match the current NetBSD kernel features. If there is anything in 3rd
party pretending to use these values, it would not work anyway.

If we want to these compat defines, they already live in:

external/cddl/osnet/dist/uts/common/sys/procset.h

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=170346

Regarding FreeBSD, I don't see rationale for inclusion of these values.
It looks like it was copy-pasted (there were also Solaris-specific
preprocessor guards in the initial version).

But if there is intention to keep these values around (as it might be in
theory too late as they leaked somewhere), it's fine. Thanks.



signature.asc
Description: OpenPGP digital signature

Re: sys/idtype.h unused enumeration values

[Taylor R Campbell]

> Date: Mon, 18 May 2020 21:40:16 +0200
> From: Kamil Rytarowski 
> 
> If I delete P_TASKID ... P_P_CPUID ones, P_SETID will be reordered (but
> we can force the number anyway). If I delete P_CID there is an inelegant
> hole. Naturally P_SETID -> P_CID can fill the gap.
> 
> This is in theory ABI change, but no users could use in a useful
> approach previously.
> 
> My intention isto g/c unused values and keep this clean and elegant (as
> this is still possible).

Just leave the numbers as they are, and add new ones to the end if you
need.  There are billions of free numbers here.

However inelegant unused numbers are, I think it would be a lot less
elegant to play russian roulette with binary compatibility.  Programs
that use what P_SETID is today -- for whatever reason, even if it's
not useful -- just get no matching process.  Boot a new kernel with
the `clean and elegant' renumbering, and who knows, maybe they'll
accidentally start sending SIGKILL to processes they didn't even mean
to match.  There's no need to waste time even thinking about this if
you just leave the numbers as they are.

Re: sys/idtype.h unused enumeration values

[Christos Zoulas]

> On May 18, 2020, at 3:40 PM, Kamil Rytarowski  wrote:
> 
> If I delete P_TASKID ... P_P_CPUID ones, P_SETID will be reordered (but
> we can force the number anyway). If I delete P_CID there is an inelegant
> hole. Naturally P_SETID -> P_CID can fill the gap.
> 
> This is in theory ABI change, but no users could use in a useful
> approach previously.
> 
> My intention isto g/c unused values and keep this clean and elegant (as
> this is still possible).
> 

Why don't you leave them alone for the same reason FreeBSD did (source 
compatibility)
and append the ones you want? If you look they #define P_ZONEID P_JAILID when
they made the change...

christos



signature.asc
Description: Message signed with OpenPGP

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

[Alexander Nasonov]

matthew green wrote:
> what's the use-case for disabling encrypted swap later?

It might be too slow on some machines.

> i'd argue we should avoid kauth for this and simply disable
> it always as i've been unable to think of any use case that
> is the only solution.

Always encrypted swap would be even better but ... slow machines.

-- 
Alex

Re: sys/idtype.h unused enumeration values

[Kamil Rytarowski]

On 18.05.2020 21:31, Taylor R Campbell wrote:
>> Date: Mon, 18 May 2020 21:11:36 +0200
>> From: Kamil Rytarowski 
>>
>> On 18.05.2020 20:24, Robert Elz wrote:
>>> Date:Mon, 18 May 2020 19:45:55 +0200
>>> From:Kamil Rytarowski 
>>> Message-ID:  
>>>
>>>   | I have got a local use-case for another P_type (premature to discuss it
>>>   | in this thread) and I would rather recycle an unused value.
>>>
>>> Don't do that, it is just a number, use one that hasn't been used
>>> for this purpose before.
>>>
>>>   | Do we plan to get Solaris feature-parity with all the types? I assume
>>>   | that the answer is NO. If so, can we delete the P_ values that are not
>>>   | applicable for NetBSD?
>>>
>>> I have no problem with that - just don't reuse the values for some
>>> different purpose, keep them reserved (assign them meaningless reserved
>>> names) just in case there's ever a need to implement one of those things
>>> (this is very very cheap insurance).
>>
>> I propose to delete P_CID and recycle its place for P_PSETID.
> 
> There are 2,147,483,630 different numbers you can choose from, if I
> counted right -- that's over two billion.  It's not that important to
> be economical with reuse when there's a scary comment above it
> exhorting you not to mess with the existing numbers...  Also, P_PSETID
> already appears to be assigned the number 15, so why would you want to
> change that?
> 

If I delete P_TASKID ... P_P_CPUID ones, P_SETID will be reordered (but
we can force the number anyway). If I delete P_CID there is an inelegant
hole. Naturally P_SETID -> P_CID can fill the gap.

This is in theory ABI change, but no users could use in a useful
approach previously.

My intention isto g/c unused values and keep this clean and elegant (as
this is still possible).



signature.asc
Description: OpenPGP digital signature

Re: sys/idtype.h unused enumeration values

[Taylor R Campbell]

> Date: Mon, 18 May 2020 21:11:36 +0200
> From: Kamil Rytarowski 
> 
> On 18.05.2020 20:24, Robert Elz wrote:
> > Date:Mon, 18 May 2020 19:45:55 +0200
> > From:Kamil Rytarowski 
> > Message-ID:  
> > 
> >   | I have got a local use-case for another P_type (premature to discuss it
> >   | in this thread) and I would rather recycle an unused value.
> > 
> > Don't do that, it is just a number, use one that hasn't been used
> > for this purpose before.
> > 
> >   | Do we plan to get Solaris feature-parity with all the types? I assume
> >   | that the answer is NO. If so, can we delete the P_ values that are not
> >   | applicable for NetBSD?
> > 
> > I have no problem with that - just don't reuse the values for some
> > different purpose, keep them reserved (assign them meaningless reserved
> > names) just in case there's ever a need to implement one of those things
> > (this is very very cheap insurance).
> 
> I propose to delete P_CID and recycle its place for P_PSETID.

There are 2,147,483,630 different numbers you can choose from, if I
counted right -- that's over two billion.  It's not that important to
be economical with reuse when there's a scary comment above it
exhorting you not to mess with the existing numbers...  Also, P_PSETID
already appears to be assigned the number 15, so why would you want to
change that?

Re: sys/idtype.h unused enumeration values

[Kamil Rytarowski]

On 18.05.2020 20:24, Robert Elz wrote:
> Date:Mon, 18 May 2020 19:45:55 +0200
> From:Kamil Rytarowski 
> Message-ID:  
> 
>   | I have got a local use-case for another P_type (premature to discuss it
>   | in this thread) and I would rather recycle an unused value.
> 
> Don't do that, it is just a number, use one that hasn't been used
> for this purpose before.
> 
>   | Do we plan to get Solaris feature-parity with all the types? I assume
>   | that the answer is NO. If so, can we delete the P_ values that are not
>   | applicable for NetBSD?
> 
> I have no problem with that - just don't reuse the values for some
> different purpose, keep them reserved (assign them meaningless reserved
> names) just in case there's ever a need to implement one of those things
> (this is very very cheap insurance).
> 
> kre
> 

Solaris ABI compat is something that has small chances of being useful
in future. Solaris is also not a reference for NetBSD here.

Linux uses the POSIX types: P_ALL, P_PID, P_GID + extension P_PIDFD.

https://github.com/torvalds/linux/blob/master/include/uapi/linux/wait.h#L16

FreeBSD already recycled the P_ZONEID value for P_JAILID.

Keeping these unused Solaris values in tree has no added value. If we
want it for the sake of defining it, push this to src/external/.

On 18.05.2020 20:19, Christos Zoulas wrote:
> I copied these from FreeBSD who in turn copied them from solaris and
changed
> P_ZONEID to P_JAILID. The FreeBSD comment is:
> http://bxr.su/FreeBSD/sys/sys/wait.h#100
> I decided to keep all the names too.
>

I propose to delete: P_TASKID, P_PROJID, P_POOLID, P_ZONEID, P_CTID as
they have no equivalent objects in NetBSD. (If they could have, these
objects could be designed differently).

P_CID could be in theory used, but has no users and could be deleted.

P_PSETID shall be used in pset_bind(3)/pset_unbind(3), but it looks like
it was not implemented (and thus, has no users today).

http://netbsd.org/~kamil/patch-00256-cleanup-waitids.txt

I propose to delete P_CID and recycle its place for P_PSETID.

If we will ever have a need for P_CTID or similar, we could readd them
to the enumeration.

Next, I can add my value at the end of list (and before _P_MAXIDTYPE).



signature.asc
Description: OpenPGP digital signature

Re: sys/idtype.h unused enumeration values

[Robert Elz]

Date:Mon, 18 May 2020 19:45:55 +0200
From:Kamil Rytarowski 
Message-ID:  

  | I have got a local use-case for another P_type (premature to discuss it
  | in this thread) and I would rather recycle an unused value.

Don't do that, it is just a number, use one that hasn't been used
for this purpose before.

  | Do we plan to get Solaris feature-parity with all the types? I assume
  | that the answer is NO. If so, can we delete the P_ values that are not
  | applicable for NetBSD?

I have no problem with that - just don't reuse the values for some
different purpose, keep them reserved (assign them meaningless reserved
names) just in case there's ever a need to implement one of those things
(this is very very cheap insurance).

kre

Re: sys/idtype.h unused enumeration values

[Christos Zoulas]

I copied these from FreeBSD who in turn copied them from solaris and changed
P_ZONEID to P_JAILID. The FreeBSD comment is:
http://bxr.su/FreeBSD/sys/sys/wait.h#100 

I decided to keep all the names too.

christos

> On May 18, 2020, at 1:45 PM, Kamil Rytarowski  wrote:
> 
> Signed PGP part
> POSIX notes:
> 
> "The type idtype_t shall be defined as an enumeration type whose
> possible values shall include at least the following: P_ALL P_PGID P_PID"
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_wait.h.html
> 
> For some reason we copied as-is solaris types into our public headers
> with fields that will possibly never apply to NetBSD, such as P_CTID,
> P_POOLID etc.
> 
> I have got a local use-case for another P_type (premature to discuss it
> in this thread) and I would rather recycle an unused value.
> 
> Do we plan to get Solaris feature-parity with all the types? I assume
> that the answer is NO. If so, can we delete the P_ values that are not
> applicable for NetBSD?
> 
> If something is used in some compat shim for sunos software (dtrace,
> zfs) we could easily add a compat wrapper in the 3rd party code.
> Defining the types does not make the features to work.
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

sys/idtype.h unused enumeration values

[Kamil Rytarowski]

POSIX notes:

"The type idtype_t shall be defined as an enumeration type whose
possible values shall include at least the following: P_ALL P_PGID P_PID"

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_wait.h.html

For some reason we copied as-is solaris types into our public headers
with fields that will possibly never apply to NetBSD, such as P_CTID,
P_POOLID etc.

I have got a local use-case for another P_type (premature to discuss it
in this thread) and I would rather recycle an unused value.

Do we plan to get Solaris feature-parity with all the types? I assume
that the answer is NO. If so, can we delete the P_ values that are not
applicable for NetBSD?

If something is used in some compat shim for sunos software (dtrace,
zfs) we could easily add a compat wrapper in the 3rd party code.
Defining the types does not make the features to work.



signature.asc
Description: OpenPGP digital signature