Re: [pca] can patch 147440-09 be trusted ?

[Don O'Malley]

Hi Dennis, Let me attempt to address some of the questions you raise below. Dennis Clarke wrote: I guess really the question is, can MOS and Oracle be trusted to provide a kernel patch that won't make things far worse? I agree that there have been issues with some of the Solaris 10 KUs that have been released in the past couple of months. Some of the more serious of these issues are a result of bad interactions between Solaris and third party software, while in other cases the issues lie squarely on Oracle's shoulders. The biggest single issue that we have hit in the past couple of months is that the Solaris 10 Update 10 "Feature" Kernel patch (145900-19) changed private Solaris interfaces. These changes led to third party software that used these private Solaris interfaces to break. The most common issue that customers reported as a result of this issue was that systems running EMC PowerPath and Solaris 10 experienced a system panic if 144500-19 was installed. This is detailed in SunAlert 1358671.1 EMC have since released a patch for PowerPath to fix this specific problem. Similar issues have been reported with other third party multipathing solutions like Hitachi HDS, Falconstor and Dynapath. I am not saying that Oracle are blameless in the Kernel patching issues. For example, there was a change made in patch 147440-04, that broke systems using a Veritas (VxVM) swap or dump device volume. As a result patch 147440-04 was withdrawn from MOS and SunAlert 1374089.1 was issued. There have been other issues with KU 147440-xx that only affect systems running very old firmware versions, or other edge cases. Examples of this are SunAlerts 1365975.1, 1359916.1 & 1380247.1. I agree that there have certainly been more some issues with the KU patch in the past couple of months than usual, the release of 147440-08 fixed the last major outstanding issue (the VxVM issue detailed in 1374089.1). In any case where Oracle know (or are made aware) of a patch issue the following happens: - We add a note to the "Special Install Instructions" section of the patch to warn customers of the issue ASAP. - If appropriate we will also release a SunAlert to detail "Data Loss" or "System Availability" issues. - If the issue is severe we will withdraw a patch. If you are looking to assess the likelihood of running into an issue as a result of installing a patch (particularly the KU) there are a number of things you can/should do: Read the latest version of README, specifically the "Special Install Instructions" - eg. https://updates.oracle.com/Orion/Services/download?type=readme&bugfix_name=147440-08 Look up the patch on the flash version of MOS (if possible) Personally I'm not a fan of the flash-based MOS, but there are a couple of really useful features: The "Related Knowledge to this patch" will list any SunAlerts that contain that patchid. (This means that issues that are either caused by or fixed in this patch will be detailed here.) There is a "Community Discussion" on the right of the patch description. This gives customers the opportunity to provide feedback on any issues they have experienced with that specific patch. This feedback flows into the moderated Oracle "Patch Reviews - SUN" Community and is also displayed on a per patch basis in this "Community Discussion" frame. The reason I ask, and would love to hear from others that patch multiple tiers of servers ( you know, production, testing, development etc etc ), is that I actually read the kernel patch README's. In the past that seemed to be a good policy. I could actually see the bugids affected and then determine if it was reasonable to apply the patch on the test level servers or rush to get it into the prod level. Patch 147440-09 is less than thrilling. Here is the bugid list in the README : 6878961 problem with NFS 6927023 need support for AMD family 15h processor 6932919 need support for AMD's family 15h ISA enhancements 7030516 hpet_acpi_init() should be called only if hpet is really required 7047435 'genunix: WARNING: preconfig failed: disk' when configure hard disk driv e for removal 7105132 deadman panic on a T3-1 Well gee, "problem with NFS" means what exactly? Does it mean that unless you apply this patch you have a security issue or a pending kernel panic and core dump? The other bugids apply support for the bulldozer AMD chip and that's a good thing since HP has been shipping those for a while. Would be cool to see what this "problem with NFS" is all about. However when I login to MOS that bugid is not even listed. See image attached. I can see this bugid : https://supporthtml.oracle.com/ep/faces/secure/km/BugDisplay.jspx?id=7047435 Which is in the README but NOT on the MOS page for this kernel patch. If I try to see https://supporthtml.oracle.com/ep/faces/secure/km/BugDisplay.jspx?id=6878961 I get a warm and fuzzy "The Bug ID is invalid or you do not have permission to view the bug". The same goes for bugid 6382683 which is listed on the MOS page but NOT in the README. Seriously, can Oracle be trusted or is this a case of "trust us, we know, you don't, and you don't need to know." Because that really does not fly well with me. Ok, so the above discussion is all related to the patch content (i.e. what's being fixed). While I understand your frustration here (and admire your attention to detail), what you are experiencing is not new under Oracle. This issue is related to security fixes (though there may be rare cases where other non-security bugs that are not publicly visible either). Before the Oracle acquisition, Sun never published bug reports for any security issues. (Back in the old SunSolve days we would release a "HTML" version of a patch README very similar to https://updates.oracle.com/Orion/Services/download?type=readme&bugfix_name=147440-08 that would contain links to bug reports for non-security bugs only.) In addition, the Bug description in the README for a patch was (and still is) reviewed by the security team to ensure that it is not providing enough information on any security-related issues to hackers looking to reverse-Engineer security vulnerabilities into potential attacks. The idea is that you get enough information to decide if you use the particular technology and if you feel it is appropriate for you to install the patch. It's far from perfect, but with security issues we must err on the side of caution. For this reason we do not (and never had) made bug reports for security issues publicly available. HTH, -Don Dennis -- Don O'Malley Manager, Patch/Package System Test Revenue Product Engineering | Solaris | Hardware East Point Business Park, Dublin 3, Ireland Phone: +353 1 8199764 Team Alias: rpe_patch_system_test...@oracle.com