OpenSSL RSA keys by reference in PKCS#11 keystores through the PKCS11 engine [PSARC/2009/555 FastTrack timeout 10/20/2009]
Jan Pechanec wrote: On Tue, 13 Oct 2009, Darren J Moffat wrote: there is one nit. I did not understand properly how mlock(3C) worked. It does not prevent the page to end up in core dumps. So, mlocked-memory for OPENSSL_PKCS11_PIN_CACHING_POLICY will only prevent it to end up in a swap. the paragraph below explicitly mentions that mlock(3C) will help in those core dump situations as well. Should I fix the fasttrack? Sending the email like you did is sufficient in my opinion but if you give me an updated spec I will put it in the case directory. -- Darren J Moffat
OpenSSL RSA keys by reference in PKCS#11 keystores through the PKCS11 engine [PSARC/2009/555 FastTrack timeout 10/20/2009]
On Tue, 13 Oct 2009, Darren J Moffat wrote: there is one nit. I did not understand properly how mlock(3C) worked. It does not prevent the page to end up in core dumps. So, mlocked-memory for OPENSSL_PKCS11_PIN_CACHING_POLICY will only prevent it to end up in a swap. the paragraph below explicitly mentions that mlock(3C) will help in those core dump situations as well. Should I fix the fasttrack? J. 4.1.4 PIN Caching Policy The PKCS#11 engine does NOT cache the PIN in memory by default. We assume that if the application does not fork then caching the PIN by default would not be only useless but also potentially dangerous (PIN could end up in swap or system and process core dumps). However, we provide 2 options for PIN caching so that the PIN can be used in the child to relogin to the token. The engine honors a special environment variable: OPENSSL_PKCS11_PIN_CACHING_POLICY which can have none, mlocked-memory, and memory values. The none value is the default where the PIN is forgotten after the login. memory will keep the PIN in the memory, and mlocked-memory will keep the PIN in a locked page via mlock(3C). Note that mlock() requires the PRIV_PROC_LOCK_MEMORY privilege which is not in the default user set. An admin must grant the application or the user the relevant privilege if the mlocked-memory option is to be used. With that option and without the privilege the load function will fail on loading the 1st private key if the token requires the PIN - it will NOT resort to use the memory option. Also, if the PIN is required then any incorrect value of OPENSSL_PKCS11_PIN_CACHING_POLICY will result in a failure in the load function. If the PIN is not required (eg. providing a PIN in URIs for public keys only) the PIN will not be used and will be erased from memory no matter how OPENSSL_PKCS11_PIN_CACHING_POLICY is set. While we could use the ENGINE control API to provide such information to the engine the use of an enviroment variable seems to be more apropriate here since it will provide more options to applications using RSA keys by reference without any need for code modifications. -- Jan Pechanec
Provide minor private interface modifications to support mntfs [PSARC/2009/566 FastTrack timeout 10/23/2009]
Hi Gordon, Gordon Ross wrote: I'm pleased to see this improvement moving forward. Not sure if these are design or interface questions, but: Why is the mount time (vfs-vfs_mtime) not suitable for use in place of the new created time you're adding? Also, is the destroyed time not needed because elements will be removed from the list immediately upon unmount? If so, how is the snapshot behavior retained for an existing open performed before some mounts were removed? My implementation has deviated slightly from your original suggestion: rather than use nothing but the existing linked-list of mounted resources, I am creating a second data structure as and when required. This database reflects the state of the in-kernel mnttab that is seen by all currently-open vnodes. On each new open, the in-kernel mnttab and the database are scanned with the goal of updating the latter to reflect the current state of the former. The destroyed time is required so that a database element can be killed when the corresponding mounted resource is found to be absent. When updating the database it is necessary to be able either to find the vfs_t that corresponds to a given element or to determine that the vfs_t is no longer present. This requires something akin to a serial number that is unique to each vfs_t. The mount time is not suitable for this purpose because it can change over the lifetime of the vfs_t. In addition, a resource remains in place when remounted, and therefore one has to be able to determine not simply whether a particular entry in the mnttab is new but whether it obsoletes a previous one. I chose to use a separate database because the in-kernel mnttab is in some senses fragile. I think that the changes that would be required if one were to use the in-kernel mnttab alone would be considered too invasive. The existing proposal puts almost all of the complexity into mntfs with only a minimal intrusion into other subsystems. Regards, Robert
2009/566 [interface modifications to support mntfs]
Hi Glenn, Glenn Skinner wrote: Not really architecture, but rather design review: Why is a high resolution timestamp required? Wouldn't a counter that's incremented every time a file system is mounted or unmounted (across all zones) suffice? Yes, a counter would suffice and was considered. From a design perspective, the chief advantage of a timespec_t is that it's human-readable, making observation and diagnosis simpler. From a practical perspective, the existing vfs code already updates a timespec_t with a unique time whenever a file system is mounted or unmounted. It made more sense to ensure that these time stamps were not only unique but also monotonically increasing, and then to use the same source for mntfs. Regards, Robert
ZFS Deduplication Properties [PSARC/2009/571 FastTrack timeout 10/21/2009]
On 20.10.09 21:26, Adam Leventhal wrote: The second allows the administrator to select a threshhold afterwhich 2 copies of a block are stored rather than 1. For example, if many duplicate blocks exist deduplication would reduce that count to just 1; at some threshhold, it becomes desirable to have multiple copies to guard against the multiplied effects of the loss of a single block. The default value is '100'. Is it actually necessary to expose this tunable ? Given there is already a per dataset copies property how does this interact with that ? Good questions. The per-dataset ncopies property is obeyed in that if one were to dedup many blocks with ncopies set to 2 there would result in 2 copies total after deduplication. The 'dedupditto' property guides what we're calling auto-ditto in which ZFS chooses to store an additional copy once some threshhold is reached. This is independent of the per-dataset 'ncopies' property. What does happen to the auto-ditto copies once reference count drops below threshold? Are auto-ditto-copies freed immediately or when reference count drops below e.g. half-threshold or never? Victor
PSARC 2009/538 EOF of Tadpole SPARCLE
Having read this case and PSARC/2007/152 I'm happy to give my +1 for this case EOF and removal case. I see no need to an announcement on this since it only ever appeared in the ONNV derived products -- Darren J Moffat
Provide minor private interface modifications to support mntfs [PSARC/2009/566 FastTrack timeout 10/23/2009]
My implementation has deviated slightly from your original suggestion: rather than use nothing but the existing linked-list of mounted resources, I am creating a second data structure as and when required. This database reflects the state of the in-kernel mnttab that is seen by all currently-open vnodes. [...] Sounds reasonable to me. Thanks, Gordon
EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009]
On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems wrote: The following fast track (submitted on my own behalf) straddles (IMO) the boundary between a full-case and a fast track, primarily because of the impact it has on what are presumed to be Committed interfaces. It seems fairly straight-forward to me, but other members may feel otherwise. With that in mind, if a member feels discussion or an explicit vote is required, please don't hestite to derail it. I've also used a two-week timer to ensure that sufficient time is given for members to review and derail if that is appropriate. Thanks. I don't see a release binding associated with this case. I give this case a +1 assuming that the binding is not less than Minor (i.e., this is not applicable for Patch or Micro). -Seb
FMA for Nehalem_EX [PSARC/2009/543 FastTrack timeout 10/15/2009]
On Thu, 2009-10-08 at 03:38 -0600, Tim Haley wrote: I am sponsoring this case on behalf of Yanmin Sun. This case seeks micro/patch binding. Timeout is 10/15/09. The case introduces new FMA events and a new fmd plug-in module supporting the Nehalem_EX architecture. From the ARC perspective, this case is mostly about carving out a piece of the FMA namespace. +1 -Seb
door_xcreate - extended door creation interface for private doors [PSARC/2009/554 FastTrack timeout 10/20/2009]
On Tue, 2009-10-13 at 02:21 -0700, Darren J Moffat wrote: 4. Technical Description: 4.1. Details: A new member is added to the doors API - door_xcreate, dedicated to the creation of private (as in a having a dedicated pool of server threads) doors. This case seeks Micro/Patch binding (additional libraries that depend on this interface will require that binding). +1 -Seb
gnome keyboard switcher re-integration [PSARC/2009/558 FastTrack timeout 10/21/2009]
On Tue, 2009-10-13 at 12:42 -0700, Suresh Chandrasekharan wrote: Submitting gnome keyboard switcher re-integration fasttrack. Solaris Minor release binding. This case has not been reviewed and times out today. This seems like an LSARC case that was mis-filed as a PSARC case. Can an LSARC member with more experience reviewing Gnome cases please review this? -Seb
ARC cases sponsored by Jyri Virkki
Uma, Per ARC minutes from yesterday: On 10/21/09 06:40, Uma Sabada wrote: Hi, Jyri filed 3 ARC cases on behalf of the web stack project before his 2 week vacation. I would appreciate if other ARC members can take a look at the cases and approve or comment. The cases are: http://arc.opensolaris.org/caselog/LSARC/2009/553/ Approved http://arc.opensolaris.org/caselog/LSARC/2009/562/ Approved http://arc.opensolaris.org/caselog/LSARC/2009/564/ Let it run until timeout, when Jyri returns. Asa Thanks -Uma
gnome keyboard switcher re-integration [PSARC/2009/558 FastTrack timeout 10/21/2009]
On Wed, 2009-10-21 at 11:40 -0400, Suresh Chandrasekharan wrote: The reason why this is filed as a PSARC case is related dependency libxklavier re-integration (PSARC/2009/483 ) is a major component of this case. Since PSARC already approved that case, I thought it will be an easier approval without cross reference. Anyways I'm open to review by LSARC. The decision about which ARC a case should be reviewed by has to do with the architecture introduce by the case in question, and not about case dependency. This case is 100% entirely about changes to Gnome GUIs that were introduced through LSARC. -Seb
OpenSSL RSA keys by reference in PKCS#11 keystores through the PKCS11 engine [PSARC/2009/555 FastTrack timeout 10/20/2009]
On Tue, 20 Oct 2009, Kais Belgaied wrote: I may add a note to our openssl(5) draft change that high level API must be used for that, and can add an example of few such functions so that a user can get the picture. Is that OK? sounds good. hi Kais, I'll add this at the end of the section. Obviously, precise wording might be changed by the doc writer: Note that in order to use the RSA keys by reference, high level API functions must be used, like RSA_public_decrypt(), EVP_PKEY_set1_RSA(), or EVP_SignInit(). Low level functions might go around the engine and thus fail to make use of the feature. J. +1. Kais thanks, Jan. -- Jan Pechanec
ARC cases sponsored by Jyri Virkki
Hi, Jyri filed 3 ARC cases on behalf of the web stack project before his 2 week vacation. I would appreciate if other ARC members can take a look at the cases and approve or comment. The cases are: http://arc.opensolaris.org/caselog/LSARC/2009/553/ http://arc.opensolaris.org/caselog/LSARC/2009/562/ http://arc.opensolaris.org/caselog/LSARC/2009/564/ Thanks -Uma
gnome keyboard switcher re-integration [PSARC/2009/558 FastTrack timeout 10/21/2009]
The reason why this is filed as a PSARC case is related dependency libxklavier re-integration (PSARC/2009/483 ) is a major component of this case. Since PSARC already approved that case, I thought it will be an easier approval without cross reference. Anyways I'm open to review by LSARC. Suresh Sebastien Roy ??: On Tue, 2009-10-13 at 12:42 -0700, Suresh Chandrasekharan wrote: Submitting gnome keyboard switcher re-integration fasttrack. Solaris Minor release binding. This case has not been reviewed and times out today. This seems like an LSARC case that was mis-filed as a PSARC case. Can an LSARC member with more experience reviewing Gnome cases please review this? -Seb
libfmevent - external subscriptions to FMA protocol events [PSARC/2009/573 FastTrack timeout 10/29/2009]
This case seeks patch binding. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: libfmevent - external subscriptions to FMA protocol events 1.2. Name of Document Author/Supplier: Author: Gavin Maltby 1.3 Date of This Document: 21 October, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
Provide minor private interface modifications to support mntfs [PSARC/2009/566 FastTrack timeout 10/23/2009]
This fast track was approved during ARC business today, 10/21/2009. -- - Rick Matthews email: Rick.Matthews at sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USAmain: +1(651) 554-1500 -
OVF Support in virt-convert [PSARC/2009/548 FastTrack timeout 10/16/2009]
On Fri, 2009-10-09 at 15:57 -0400, Sebastien Roy wrote: I'm submitting this fast-track for Susan Kamm-Worrell, it times out on 10/16/2009. The release binding is Patch. The proposed man page changes are contained in the case's materials directory. This case was approved during today's PSARC meeting. -Seb
ZFS Deduplication Properties [PSARC/2009/571 FastTrack timeout 10/21/2009]
The per-dataset ncopies property is obeyed in that if one were to dedup many blocks with ncopies set to 2 there would result in 2 copies total after deduplication. The 'dedupditto' property guides what we're calling auto-ditto in which ZFS chooses to store an additional copy once some threshhold is reached. This is independent of the per-dataset 'ncopies' property. What does happen to the auto-ditto copies once reference count drops below threshold? Are auto-ditto-copies freed immediately or when reference count drops below e.g. half-threshold or never? When the reference count drops below the threshold the second block is deleted. Yes, the possibility of creating and deleting exists if we're right on the boundary of the threshold, but that degenerate case is identical to what would happen without dedup: deletion of a block deletes a block and creation of a block creates a block. Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl
EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009]
Sebastien Roy wrote: On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems wrote: The following fast track (submitted on my own behalf) straddles (IMO) the boundary between a full-case and a fast track, primarily because of the impact it has on what are presumed to be Committed interfaces. It seems fairly straight-forward to me, but other members may feel otherwise. With that in mind, if a member feels discussion or an explicit vote is required, please don't hestite to derail it. I've also used a two-week timer to ensure that sufficient time is given for members to review and derail if that is appropriate. Thanks. I don't see a release binding associated with this case. I give this case a +1 assuming that the binding is not less than Minor (i.e., this is not applicable for Patch or Micro). -Seb Yes, it should have been minor. Thanks. This case was approved at PSARC today, and has minor binding. - Garrett
Pass-through iconv code conversion [PSARC/2009/561 FastTrack timeout 10/21/2009]
This case was approved at today's PSARC review meeting. Ienup
[2009/471] OpenSolaris Distribution Constructor - Inception AIs
Hello All, Here are the AI's from today's inception review of PSARC 2009/471. Please let me know, in case any corrections/modifications are required: 1) Investigate whether JSON is better than XML for the manifest. 2) ManifestServ and ManifestRead o man page needed for ManifestRead documenting how it can be used. o Check to make sure ManifestRead and ManifestServ meets the utility syntax guideline for commands. 3) Schema for the DC manifest. o Need to include schema for the manifest in the design specification. o Need to detail how version control is done for the schema. 4) Finalizer scripts o Need to specify sample finalizer scripts that's delivered as part of DC as exported interfaces, with low stability level. o When the ARC case detailing those scripts are presented, their stability level can be raised. 5) Requirement for uid==0 o Need to make sure DC does not require uid==0 o To provide better user experience, have finalizer scripts register the privileges as it needs to run successfully, and have DC check for those privileges when it starts. 6) Checkpointing/zfs: o Need to have explicit statement in design document about the requirement that the build area needs to be on it's own ZFS file system. Thanks, -Suha
FMA for Nehalem_EX [PSARC/2009/543 FastTrack timeout 10/15/2009]
This case was approved in today's PSARC meeting. -tim
EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009]
So, in the process of going about the work to remove these utilities, I found a few surprises. First off, it is possible to take graph output, and generate postscript, using the postplot utility (located in /usr/lib/lp/postscript). Second, it turns out that there are other postscript filters related to postplot in some way, but which possibly could also be removed as they are unlikely to be found useful in modern systems. (I'm speaking specifically of posttek and postdaisy, which convert Tek 4014 and Diablo 630 format files into PostScript.) What isn't clear to me here is what the best approach is. Some options: 1) Decline to remove /usr/bin/graph at this point, and remove it only later when/if we find we can remove the postscript commands. 2) We could also leave the -g option in LPR, although I think its better to remove it since CUPS can't support it. 3) We could remove postplot (which mostly exists for the purpose of dealing with lpr -g), as well. 4) We could decline to implement the case at all, although I think that is silly. There is clearly at least *some* baggage here that we can remove. My personal preference is to just remove it all, probably in two phases. Phase 1 will implement the stuff specified here, as specified and approved. Phase 2 would be a new case to remove the posttek, postplot, postdaisy utilities, subject to separate PSARC and C-Team/P-Team review. Any strong opinions here? - Garrett Garrett D'Amore wrote: Sebastien Roy wrote: On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems wrote: The following fast track (submitted on my own behalf) straddles (IMO) the boundary between a full-case and a fast track, primarily because of the impact it has on what are presumed to be Committed interfaces. It seems fairly straight-forward to me, but other members may feel otherwise. With that in mind, if a member feels discussion or an explicit vote is required, please don't hestite to derail it. I've also used a two-week timer to ensure that sufficient time is given for members to review and derail if that is appropriate. Thanks. I don't see a release binding associated with this case. I give this case a +1 assuming that the binding is not less than Minor (i.e., this is not applicable for Patch or Micro). -Seb Yes, it should have been minor. Thanks. This case was approved at PSARC today, and has minor binding. - Garrett
GCC4: The GNU Compiler Collection 4.X [LSARC/2009/575 FastTrack timeout 10/28/2009]
This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GCC4: The GNU Compiler Collection 4.X 1.2. Name of Document Author/Supplier: Author: George Vasick 1.3 Date of This Document: 21 October, 2009 4. Technical Description Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GCC4: The GNU Compiler Collection 4.X 1.2. Name of Document Author/Supplier: George Vasick 1.3. Date of This Document: 10/19/2009 1.5. Email Aliases: 1.5.1. Responsible Manager: kurt.goebel at sun.com 1.5.2. Responsible Engineer: george.vasick at sun.com 1.5.4. Interest List: sfwnv-discuss at opensolaris.org 2. Project Summary 2.1. Project Description: Provide GCC 4.X and allow for the coexistence of multiple versions of GCC installed simultaneously. GCC 3.4.3, the current build compiler for OpenSolaris and Nevada, will remain unchanged in /usr/sfw. 4. Technical Description: 4.1. Details: Commands will be installed in /usr/bin with versioned suffixes, e.g. gcc-4.3.2. The runtime libraries will be installed /usr/lib with major, minor, and patch suffixes as appropriate along with a link for the major version, e.g libstdc++.so.6.0.10 and libstdc++.so.6 - libstdc++.so.6.0.10. See section 4.5 Interfaces below for additional details. This case proposes to modify the previous release, LSARC/2008/776 GNU Developer Collection, as follows: 1) Localized message files will be moved from /usr/share/locale to /usr/lib/gcc/machine/version/share/locale. 2) Runtime libraries will be refactored from a single package into multiple packages, one package per library, to allow individual libraries to be upgraded in future releases. 4.2. Bug/RFE Number(s): 6674032: Introduce GCC 4.3.x (or later) in Nevada 4.5. Interfaces: Exported Interfaces Comments === SUNWgcc432 GCC 432 compiler package. All interfaces Uncommited. usr/bin/c++-4.3.2=g++-4.3.2 usr/bin/cpp-4.3.2 usr/bin/g++-4.3.2 usr/bin/gcc-4.3.2 usr/bin/gccbug-4.3.2 usr/bin/gcov-4.3.2 usr/bin/gfortran-4.3.2 usr/bin/machine-c++-4.3.2=g++-4.3.2 usr/bin/machine-g++-4.3.2=g++-4.3.2 usr/bin/machine-gcc-4.3.2=gcc-4.3.2 usr/bin/machine-gfortran-4.3.2=gfortran-4.3.2 usr/include/c++/4.3.2/* usr/lib/gcc/machine usr/lib/gcc/machine/4.3.2 usr/lib/gcc/machine/4.3.2/cc1 usr/lib/gcc/machine/4.3.2/cc1obj usr/lib/gcc/machine/4.3.2/cc1plus usr/lib/gcc/machine/4.3.2/collect2 usr/lib/gcc/machine/4.3.2/crt1.o usr/lib/gcc/machine/4.3.2/crtbegin.o usr/lib/gcc/machine/4.3.2/crtend.o usr/lib/gcc/machine/4.3.2/crtfastmath.o usr/lib/gcc/machine/4.3.2/crti.o usr/lib/gcc/machine/4.3.2/crtn.o usr/lib/gcc/machine/4.3.2/f951 usr/lib/gcc/machine/4.3.2/finclude/* usr/lib/gcc/machine/4.3.2/gcrt1.o usr/lib/gcc/machine/4.3.2/gmon.o usr/lib/gcc/machine/4.3.2/include usr/lib/gcc/machine/4.3.2/include-fixed/* usr/lib/gcc/machine/4.3.2/include/* usr/lib/gcc/machine/4.3.2/install-tools/* usr/lib/gcc/machine/4.3.2/libgcc.a usr/lib/gcc/machine/4.3.2/libgcc_eh.a usr/lib/gcc/machine/4.3.2/libgcc_s.so=../../../libgcc_s.so.1 usr/lib/gcc/machine/4.3.2/libgcov.a usr/lib/gcc/machine/4.3.2/libgfortran.so=../../../libgfortran.so.3 usr/lib/gcc/machine/4.3.2/libgfortranbegin.a usr/lib/gcc/machine/4.3.2/libgfortranbegin.la usr/lib/gcc/machine/4.3.2/libgomp.so=../../../libgomp.so.1 usr/lib/gcc/machine/4.3.2/libobjc.so=../../../libobjc.so.2 usr/lib/gcc/machine/4.3.2/libobjc_gc.so=../../../libobjc_gc.so.2 usr/lib/gcc/machine/4.3.2/libssp.so=../../../libssp.so.0 usr/lib/gcc/machine/4.3.2/libstdc++.so=../../../libstdc++.so.6 usr/lib/gcc/machine/4.3.2/share/locale* usr/lib/gcc/machine/4.3.2/mach64/crt1.o usr/lib/gcc/machine/4.3.2/mach64/crtbegin.o usr/lib/gcc/machine/4.3.2/mach64/crtend.o usr/lib/gcc/machine/4.3.2/mach64/crtfastmath.o usr/lib/gcc/machine/4.3.2/mach64/crti.o usr/lib/gcc/machine/4.3.2/mach64/crtn.o usr/lib/gcc/machine/4.3.2/mach64/gcrt1.o usr/lib/gcc/machine/4.3.2/mach64/gmon.o usr/lib/gcc/machine/4.3.2/mach64/libgcc.a usr/lib/gcc/machine/4.3.2/mach64/libgcc_eh.a usr/lib/gcc/machine/4.3.2/mach64/libgcc_s.so=../../../../mach64/libgcc_s.so.1 usr/lib/gcc/machine/4.3.2/mach64/libgcov.a
