X

Recent Posts

Solaris

Private VLAN in Solaris 11.3

The first guest blog article here! This article is from my colleague, Eric yu.--In this blog we are going to talk about the Private VLAN feature in Solaris 11.3.PVLAN allows you to divide a VLAN into sub-VLANs to isolate network traffic.More details about Private VLAN can be found in here (https://en.wikipedia.org/wiki/Private_VLAN).In Solaris 11.3 we support isolated VLAN and community VLAN. As you may already familiar with the Solaris dladm create-vlan command, PVLAN can be managed bythis command too. Here's some quick examples on how to manage PVLAN vnics inSolaris 11.3.Create an isolated VLAN, and this isolated vlan can only talk to its primaryVLAN, and not other secondary VLANs.# dladm create-vlan -l net0 -v 3,100,isolated vlan0Create an community VLAN, this community VLAN can talk to other VNICs withinthe same community -# dladm create-vlan -l net0 -v 3,101,community vlan0And this is how we delete a PVLAN vnic, just like what we do with other types of Solaris VNICs:# dladm delete-vlan vlan0You can also assign a PVLAN to a Solaris zone:global# zonecfg -z zone1zonecfg:zone2> add anetzonecfg:zone2:anet> set vlan-id=100,200,communityzonecfg:zone2:anet> endzonecfg:zone2> verifyzonecfg:zone2> commitzonecfg:zone2> exitglobal# zoneadm -z zone rebootIn Solaris 11.3, you could also set the tag mode property for PVLAN, such that the outgoing traffic could be either tagged with the primary VLAN or secondary VLAN.Set the tag mode to secondary:# dladm set-linkprop -p pvlan-tagmode=secondary net0

The first guest blog article here! This article is from my colleague, Eric yu. -- In this blog we are going to talk about the Private VLAN feature in Solaris 11.3.PVLAN allows you to divide a VLAN...

Solaris

SO_FLOW_SLA socket option in Solaris 11.2

We have added a new socket option, SO_FLOW_SLA, in Solaris 11.2 to allow an application to create socket level flows and set resource control properties on them using setsockopt(). This socket option requires PRIV_SYS_FLOW_CONFIG privilege.The setsockopt(3C) man page has all the details of the programming API. It is simple to use as shown below -sock_flow_props_t sprop;sock = socket(AF_INET, SOCK_STREAM, 0);sprop.sfp_version = SOCK_FLOW_PROP_VERSION1;sprop.sfp_mask = SFP_MAXBW;sprop.sfp_maxbw = 500000000; /* 500 Mbps */setsockopt(sock, SOL_SOCKET, SO_FLOW_SLA, &sprop, sizeof (sprop));The flows created using setsockopt(3C) can be observed using flowadm(1M), flowstat(1M) as well as from pfiles(1).Consider the example of the nc(1)/netcat tool which uses this socket option to implement the -M option.a. Assume nc -l 80 is running on 10.2.3.118 and run# nc -M maxbw=100M 10.2.3.118 80...And in another window we observe -# flowadmFLOW LINK PROTO LADDR LPORT RADDR RPORT DSFLD24.sys.sock net1 tcp 10.2.3.117 38769 10.2.3.118 80 --# flowadm show-flowpropFLOW PROPERTY PERM VALUE DEFAULT POSSIBLE24.sys.sock maxbw rw 100 -- -- 24.sys.sock priority rw -- medium low,medium,high # pfiles `pgrep nc`18827: nc -M maxbw=100M 10.2.3.118 80... 3: S_IFSOCK mode:0666 dev:556,0 ino:5341 uid:0 gid:0 size:0 O_RDWR SOCK_STREAM SO_SNDBUF(49152),SO_RCVBUF(128872), SO_FLOW_SLA(maxbw: 100.000 mbits/sec) sockname: AF_INET 10.2.3.117 port: 38769 peername: AF_INET 10.2.3.118 port: 80 congestion control: newreno...

We have added a new socket option, SO_FLOW_SLA, in Solaris 11.2 to allow an application to create socket level flows and set resource control properties on them using setsockopt(). This socket...

Solaris

Priority flows and socket level flows in Solaris 11.2

A brief bit of background first - Crossbow flows have been there since Solaris 11. flowadm(1M) and flowstat(1M) are the admin commands. flowadm(1M) is used for enforcing bandwidth limit on a service by creating a flow and setting 'maxbw' property on it. flowstat(1M) is used to observe the traffic on the flow. Note that a flow can be created without any property set on it. This is useful for observability.We have extended Crossbow flows in Solaris 11.2 to support -1. socket level (a.k.a. fine-grained) flows2. A new flow property called 'priority'1. socket level flowsOne can now create a flow that corresponds to a listener socket or a fully-connected socket. To give an example, you can do the following in Solaris 11.2 -a. Specify both local IP and local port attributes in a flow# flowadm add-flow -l net0 -a transport=tcp,local_ip=192.168.200.102,\ local_port=22 sshd-flowb. Specify the 5-tuple attributes in a flow# flowadm add-flow -l net0 -a transport=tcp,local_ip=192.168.200.102,\ local_port=80,remote_ip=192.168.200.104,remote_port=12785\ -p maxbw=800M custom-flowIn addition to extending the flowadm command, we have also introduced a new socket option, SO_FLOW_SLA, to allow a privileged socket application to create a socket level flow and set properties on it using setsockopt(). I will talk about that API in my next blog entry.2. 'priority' flow propertyWe have also added a new property called 'priority'. From the man page"Setting the value to 'high' on a flow has the effect that packetsclassified to that flow are processed ahead of packets from normal flowson the same link. A high priority flow may offer abetter latency depending on the availability of system resources."One could use it for interactive and/or latency sensitive applicationslike sshd, and ntp. For example, one could do# flowadm set-flowprop -p priority=high sshd-flowto ensure better latency for ssh traffic even when the system is heavily loaded by other networking traffic.

A brief bit of background first - Crossbow flows have been there since Solaris 11. flowadm(1M) and flowstat(1M) are the admin commands. flowadm(1M) is used for enforcing bandwidth limit on a service...

Solaris

How to use crypto API in Solaris kernel code - Part 2

How to use crypto API in Solaris kernel code - Part 2Continuing from my previous post, we look at how to use the crypto APIin the asynchronous case. The header file, uts/common/sys/crypto/api.hdefines the crypto_call_req_t structure that needs to be passed in theasynchronous case. I am including a man pagestyle description of this structure here.As described in the man page, the default behavior is what is called anadaptive asynchronous mode (CRYPTO_ALWAYS_QUEUE flag is clear) asopposed to pure asynchronous mode (CRYPTO_ALWAYS_QUEUE flag isset).  kCF consists of various crypto providers some of themsoftware-based and someof them hardware-based. For a given mechanism, a software provider istypically capable of doing the operation without needing kCF to block.The default behavior is appropriate for an operation like digest or MACwhich do not take too many cycles. It may not be appropriate foroperations like encrypt/decrypt, especially for public key ciphers likeRSA. The caller needs to determine which behavior is suited for itscase. In the default case, a caller is required to handle aCRYPTO_SUCCESS return value. Of course, if the CRYPTO_ALWAYS_QUEUE flagis set, this is not the case.Looking at the ah_submit_req_inbound() code in uts/common/inet/ip/ipsecah.c. 2826 AH_INIT_CALLREQ(&call_req); 2827 2828 ii->ipsec_in_skip_len = skip_len; 2829 2830 IPSEC_CTX_TMPL(assoc, ipsa_authtmpl, IPSEC_ALG_AUTH, ctx_tmpl); 2831 2832 /\* call KEF to do the MAC operation \*/ 2833 kef_rc = crypto_mac_verify(&assoc->ipsa_amech, 2834 &ii->ipsec_in_crypto_data, &assoc->ipsa_kcfauthkey, ctx_tmpl, 2835 &ii->ipsec_in_crypto_mac, &call_req); 2836 2837 switch (kef_rc) { 2838 case CRYPTO_SUCCESS: 2839 AH_BUMP_STAT(crypto_sync); 2840 return (ah_auth_in_done(ipsec_mp)); 2841 case CRYPTO_QUEUED: 2842 /\* ah_callback() will be invoked on completion \*/ 2843 AH_BUMP_STAT(crypto_async); 2844 return (IPSEC_STATUS_PENDING); 2845 case CRYPTO_INVALID_MAC: 2846 AH_BUMP_STAT(crypto_sync); 2847 ah_log_bad_auth(ipsec_mp); 2848 return (IPSEC_STATUS_FAILED); 2849 }The call_req argument to crypto_mac_verify() is the one that is ofinterest here1. One thing tonotice here is thatthis routine,  ah_submit_req_inbound()can be called from interrupt context while processing the incomingIPSec packet. So, we ensure we won't be blocking by callingcrypto_mac_verify() in asynchronous mode. call_req is set on line 2826with the following macro 2777 #define AH_INIT_CALLREQ(_cr) { \\ 2778 (_cr)->cr_flag = CRYPTO_SKIP_REQID|CRYPTO_RESTRICTED; \\ 2779 if (ipsec_algs_exec_mode[IPSEC_ALG_AUTH] == IPSEC_ALGS_EXEC_ASYNC) \\ 2780 (_cr)->cr_flag |= CRYPTO_ALWAYS_QUEUE; \\ 2781 (_cr)->cr_callback_arg = ipsec_mp; \\ 2782 (_cr)->cr_callback_func = ah_kcf_callback; \\ 2783 }We specify a call back routine,ah_kcf_callback(), which kCF will call aftercompleting the operation. The call back routine gets two arguments -cr_callback_arg (in this case ipsec_mp) and  a status of the crypto operation. Thecall back routine must adhere  to  the same restrictions as adriver soft interrupt handler. Note that this code setsCRYPTO_ALWAYS_QUEUE flag conditionally(default is that IPSEC_ALGS_EXEC_ASYNC is not set). This explainswhy  we check for CRYPTO_SUCCESS on line 2838 after callingcrypto_mac_verify().This concludes a brief overview of using crypto API.  The best wayto get more details is to look at more code. You can find all theconsumers of these API by looking for files which include sys/crypto/api.h.1crypto_mac_verify()takes more arguments than crypto_digest() from our previous example.The third argument is the key used for mac'ing. The fourth argument isa context template which is used to precompute things like a keyschedule and reuse it several times later.Technorati Tag: OpenSolarisTechnorati Tag: Solaris

http-equiv="content-type"> Continuing from my previous post, we look at how to use the crypto API in the asynchronous case. The header file, href="http://cvs.opensolaris.org/source/xref/usr/src/uts/co...

Solaris

How to use crypto API in Solaris kernel code

How to use crypto API in Solaris kernel codeNow that OpenSolaris is areality, we can finally blog about the source code. I will start withhow to do crypto stuff from the kernel code.Solaris 10 has the kernel crypto framework (kCF) which offers cryptoAPI for other kernel modules or drivers. IPSec and Kerberos are some ofthecomponents that make use of it. This API is not public yet and henceyou won't see any man pages (They should very likely be public inNevada). The complete list of API is in uts/common/sys/crypto/api.h.Let us start with a simple digest operation. The digest API are    crypto_digest()    crypto_digest_init(), crypto_digest_update(),crypto_digest_final()If you are familiar with PKCS #11, these routines follow similar namingconventions except that crypto_digest() does not need ancrypto_digest_init(). Let us look at crypto_digest(). The prototype is    int crypto_digest(crypto_mechanism_t \*mech,crypto_data_t \*data, crypto_data_t \*digest, crypto_call_req_t \*cr);The structures are defined in uts/common/sys/crypto/common.h.It is best to explain each argument by looking at an actual example.Looking in uts/common/io/cryptmod.c,we find 692           rv = crypto_digest(&mech, &d1, &d2, NULL);The first argument specifies the cryptographic mechanism  to beused and its parameters. 672           mech.cm_type = digest_type; 673           mech.cm_param = 0; 674           mech.cm_param_len = 0;cm_type identifies the type of the mechanism. This field must be set tothe value returned by crypto_mech2id(). crypto_mech2id() gets the kCFinternal mechanism id assigned for a mechanism name. This call needs tobe made only once since the id stays the same till a reboot. Forexample in this file, aSHA1 mechanism id is obtained 294         sha1_hash_mech = crypto_mech2id(SUN_CKM_SHA1);and it is passed as digest_type to the kef_digest() routine.cm_param specifies the parameter for a mechanism. It is zero here. But,it needs to be specified for some mechanisms. For example, the IV for aCKM_DES_CBC mechanism is passed in this field. cm_param_len specifiesthe length of cm_param, in bytes.The second argument describes the data that is to be digested. 676           v1.iov_base = (void \*)input; 677           v1.iov_len = inlen; 678 679           d1.cd_format = CRYPTO_DATA_RAW; 680           d1.cd_offset = 0; 681           d1.cd_length = v1.iov_len; 682           d1.cd_raw = v1;cd_format specifies the format of the data which can be one ofCRYPTO_DATA_RAW, CRYPTO_DATA_UIO or CRYPTO_DATA_MBLK. CRYPTO_DATA_RAWformat means that the input is a iovec_t which basically means apointer to a buffer and its length. CRYPTO_DATA_MBLK format is usefulin networking code where mblk_t structures are common. cd_offsetspecifies an offset from the beginning of the data. The digestingstarts at that offset byte. cd_length specifies the length of the datato be used for the digesting. cd_raw is used to specify the address ofa iovec_t buffer. As can be guessed, this field  is valid only ifcd_format is equal to CRYPTO_DATA_RAW.The third argument describes the output data. 684           v2.iov_base = (void \*)output; 685           v2.iov_len = hashlen; 686 687           d2.cd_format = CRYPTO_DATA_RAW; 688           d2.cd_offset = 0; 689           d2.cd_length = v2.iov_len; 690           d2.cd_raw = v2;The fourth argument describes the calling conditions.  A NULLvalue, as is the case here, means that caller is prepared to block tillthe operation completes. Callers in an interrupt context usually can'tblock and need to specify a value for this argument making it anasynchronous interface.One asynchronous example is in uts/common/inet/ip/ipsecah.c.I will talk about it in my next post.Technorati Tag: OpenSolarisTechnorati Tag: Solaris

http-equiv="content-type"> Now that OpenSolaris is a reality, we can finally blog about the source code. I will start with how to do crypto stuff from the kernel code.Solaris 10 has the kernel crypto...

Oracle

Integrated Cloud Applications & Platform Services