Amazon Linux 歴代リポジトリのカーネル情報を確認してみた(2012.09〜2017.09)
はじめに
AWSチームのすずきです。
古いAmazon Linux環境をメンテナンスするにあたり、 事前準備として歴代のAmazonLinux(2012.09以降)の最終カーネルバージョンについて確認する機会がありましたので、紹介させていただきます。
確認手順
EC2
AMIは東京リージョンで公開されている AmazonLinux 2012.09 を利用しました。
- amzn-ami-hvm-2012.09.0.x86_64-ebs - ami-426cd343
以下の「Userdata」を利用し、AmazonLinuxデフォルトのセキュリティパッチ機能を抑止して、EC2インスタンスを起動しました。
1 2 | #cloud-config repo_upgrade: none |
yum
「/etc/yum/vars/releasever」にAmazonLinuxの歴代バージョンを反映し、 歴代バージョンのリポジトリを利用したアップデートを実施、インストールされたカーネルパッケージ情報を確認しました。
- 利用スクリプト
1 2 3 4 5 6 7 8 | a=(2012.09 2013.03 2013.09 2014.03 2014.09 2015.03 2015.09 2016.03 2016.09 2017.03 2017.09) for b in ${a[@]}; do echo "${b}" | sudo tee /etc/yum/vars/releasever sudo yum clean all sudo yum update -y rpm -qi kernel > ${b}.txt done |
結果
2018年1月11日現在、AmazonLinux 2012.09から2017.09までのリポジトリからインストールされたカーネル情報は以下の通りでした。
releasever | Version | Release | Build Date: |
---|---|---|---|
(ami-426cd343) | 3.2.30 | 49.59.amzn1 | 2012年10月03日 20時06分36秒 |
2012.09 | 3.2.42 | 9.80.amzn1 | 2013年03月27日 21時07分51秒 |
2013.03 | 3.4.57 | 48.42.amzn1 | 2013年08月12日 21時49分26秒 |
2013.09 | 3.4.103 | 76.114.amzn1 | 2014年09月12日 01時02分27秒 |
2014.03 | 3.10.57 | 57.140.amzn1 | 2014年10月10日 21時46分14秒 |
2014.09 | 3.14.35 | 28.38.amzn1 | 2015年03月11日 22時54分17秒 |
2015.03 | 3.14.79 | 35.44.amzn1 | 2017年04月28日 23時22分16秒 |
2015.09 | 4.1.39 | 27.28.amzn1 | 2017年04月28日 23時28分52秒 |
2016.03 | 4.4.35 | 33.55.amzn1 | 2016年12月06日 20時35分00秒 |
2016.09 | 4.4.51 | 40.69.amzn1 | 2017年08月12日 01時17分15秒 |
2017.03 | 4.9.43 | 17.39.amzn1 | 2017年09月15日 23時44分30秒 |
2017.09 | 4.9.75 | 25.55.amzn1 | 2018年01月05日 23時55分11秒 |
まとめ
CVE-2017-5754、通称「Meltdown」として報告されているCPU由来の脆弱性、 AWSのハイパーバイザーレベルでの対策は完了しており、 仮想ホストとインスタンス、及び、同一ホストに共存するインスタンス間で メモリ内容が不正に参照されるリスクについては対策済みと報告されています。
AmazonLinux上で動作するアプリケーション間で生じうるリスクについては、 下記アップデートを含む「4.9.75-25.55.amzn1.x86_64」以降のカーネルを利用する事で軽減させる事が可能です。
AmazonLinux のデフォルトでは「latest」のリポジトリが利用されるため、最新カーネルへのアップデートが可能ですが、 AmazonLinuxをバージョン固定で利用している環境では、リポジトリの切替後にカーネルアップデートをお試しください。
尚、今回確認を実施した素のAmazonLinuxでは、「2012.09」から「2017.09」までのアップデートは問題なく完了しましたが、 検証環境を利用したアプリケーションやミドルウェア動作の事前確認や、システムバックアップとなるAMI、スナップショットの取得などを実施した上で、 アップデートを行う事をお薦めします。