sw

iijlabセミナー: 狭義のTeXと広義のTeX、それぞれの進化

IMG_20190521_174225

午前中は酷い雨だったけど夕方にはやんでくれた。

IMG_20190521_174613

[2019-05-21 18:01]

  • 日本人の知らないTeX/八登崇之 at TeXユーザの集い2010 を読む前提知識を提供するかんじで。
  • クヌースがつくったTeXはもうつかわれてない。つかってるのはクヌースだけ。
  • XeTeXはジーテックとよむ。
  • LaTeXはいじらない方針だったけどTeX Live 2015からは変えていく方針になった。
  • TeXのレイヤー: 文章を入力する人/文章を組版する人/仕組みを開発する人
  • webに対応させると HTML/CSS/JS
  • いきなりマクロ言語のところをいじるのは無謀
    • コアの部分をいじろうとしてハマるパターン
  • 図を書けるようにした: TikZ/PGF
  • LuaTeX: JSでDOMをいじるようなことがTeXでできる。
  • XeTeX(2004),LuaTeX(2007)でUnicodeに対応した。それまでは8bit化されてただけ。
  • pdfTeXにinputencパッケージでエンジンそのままでUTF-8(ただしグリフは255文字まで)対応してしまった。
  • TeXは \foo というコマンドだけでなく文字もコマンンドとしてあつかえる。
  • CJKパッケージもおなじ戦略だが文字が256文字におさまらないので256文字でサブフォントとして対応。
  • フォントはコマンドできりかえる。
  • tfm: 昔はフォントは印刷所にしかなかったり。フォントの概要だけを納めたファイル。
  • コミックだと漢字はゴシック、ひらがなは明朝だったり、フォントをくみあわせる需要がある。
  • DVIもフォントを仮想化する -> VF
  • NFSS: LaTeXにおける抽象化: encoding,family,series,shape,size
  • fontenc
  • フォントの設定だけで4つもファイルを用意する必要がある。
  • システムフォントをつかいたかった -> XeTeX
  • 日本語ならBXjsclsパッケージをつかうとすべてそろう。
  • pxchfonというパッケージをつかうとDVIをハックしてフォントがえらべるようになる。

[2019-05-21 19:08]

  • Q: uplatexじゃなくても日本語はつかえる?
  • A: luatexでも日本語処理のパッケージがあるので使える状態になっている。
  • Q: 若者育成は?
  • A: 若い人もいる。ptexを開発している日本人は25歳。

[2019-05-21 19:11]

_1240217x

MewでISO-2022-JPなのに丸数字つかってるメールを読む方法

Mewcp5022x.el をダウンロードしてパスがとおったところにおいて、

.mewに

(require 'cp5022x)
(add-to-list 'mew-cs-database-for-decoding '("iso-2022-jp" cp50220-unix))

と書いたらok.

追記

SCRAM: Salted Challenge Response Authentication Mechanism

passwd salt iteration                                            nonce
    |   |    |                                                     |________________________________________,
    V   V    V                                                     |                                        |
Hi( *,  *,   * ) = SaltedPassword ---------------------------------)----------,                             |
                          |                                        |          |                             |
                          V                                        |          V                             |
                    HMAC(key, "Client Key") = ClientKey            |    HMAC(key, "Server Key") = ServerKey |
                                               |    |              |                                   |    |
                                               |    V              |                                   |    |
                                               |  H(*) = StoredKey |                                   |    |
                                               |              |    |                                   |    |
                                               |              V    V                                   V    V
                                               |        HMAC(key, str) = ClientSignature         HMAC(key, str) = ServerSignature
                                               |                           |
                                               V___________________________V
                                              XOR
                                               |
                                               V
                                          ClientProof

Server:
  exchange nonce
  recv ClientProof
  StoredKey = authDB[username]
  ClientSignature = HMAC(StoredKey, nonce)
  ClientKey = ClientProof XOR ClientSignature
  if H(ClientKey) == StoredKey then
      OK // the client knows the correct ClientKey.
  else
      NG



HMAC(key, str): Apply the HMAC keyed hash algorithm
H(str): Apply the cryptographic hash function
Hi(str, salt, i):

 U1   := HMAC(str, salt + INT(1))
 U2   := HMAC(str, U1)
 ...
 Ui-1 := HMAC(str, Ui-2)
 Ui   := HMAC(str, Ui-1)

 Hi := U1 XOR U2 XOR ... XOR Ui

jambow

いってきた: DNS温泉 番外編(2019年2月)

前日に予習資料に目をとおしておこうとしたのだが、まにあわず。

_1220358x_1220360x

DNS温泉とは

  • DNS温泉: 鈴木先生主催 呑むついでに話す
  • DNS補講: 温泉参加者限定
  • DNS番外編: だれでも

IMG_20190216_114700

[2019-02-16 12:01]

基礎講座 / 鈴木常彦_1220361x

DNS温泉5の資料にもとづいて
  • http://www.e-ontap.com/dns/onsen5
  • DNSの学び方
    • JPRSの本がいちばん正確だが、それでも首をかしげるところも..
    • RFC違反の実装もある
    • RFCもあやしい
    • 自分で考えるしかない
  • RFC1034,1035,2181,2308,8020(3308の訂正),1912(よくあるまちがい集)
  • 自律分散といいつつICANNを頂点とする階層構造
  • DNSにいろんなものをつめこめる → DNS camel
  • ラベルは any binary string (rfc2181) ホスト名は英数とか限定だがドメイン名はなんでもよい
  • ドメイン名は内部表現上で255オクテットまで。
  • RRs=Resource Record set (複数のsじゃなくてsetのs)
  • TTL: how long a RR can be cached. should be discarded.
  • RDATA: owner,type,class
  • QNAME minimizationない伝統的なやりかたならroot zone serverにFQDNで問合せる。
  • stub resolverからfull resolverのあいだは多段になる可能性がある。
  • 誤解するので 再帰問い合わせ→再帰検索要求と大学の授業ではいっている (RD flag=1)
  • full resolver: iterative searchをする。個々の問い合わせは非再帰問い合わせ.(RD=0)
  • 最終回答にはAA bitがたっている。ただし自称AAでしかない。委任されているかどうかが重要。
  • アプリがDNS RRをキャッシュするのはTTLがわからないので危険。でも攻撃を避けるのにdns rebinding攻撃を避けるためにキャッシュすることもある。
  • zoneとはなにか? むつかしい。
  • サブドメインとゾーンのちがい。
    • chukyo-u.ac.jpゾーンの親としてのac.jpゾーンはない(昔はあった)。ac.jpがあってもjと管理者が同じなので意味がない。
  • グルーのはなしは難しいので後半でやるかも。
  • ゾーンの構成物
    • 自分が権威をもつRR
    • 頂点 SOA NS
    • サブゾーン NS
    • サブゾーンNSのA
  • 内部名=下部名 in-bailwick
  • sibling glue
  • recursiveはもともとサーバーのモードのことだった 昔はcache serverとcontents serverが混在してた
  • DNS応答5種類 (djbの分類)
    • CNAME (別名)
    • NXDOMAIN (名前がない)
    • NOERROR (成功)
    • referral (委任)
    • NODATA=(NOERROR+SOA) (名前はあるけどそのタイプはない)

_1220364x

[2019-02-16 13:00]

  • sibling glueとは
    • zone jp.
    • zone example.ne.jp.
      • NS ns.example.ad.jp
    • zone example.ad.jp.
      • NS ns.example.ad.jp
      • ns A 192.0.2.1
  • jpサーバに xx.example.ne.jp の問い合わせがあったときにns.example.ad.jp Aを返すことができる=sibling glue。(jpからみたら内部名。sibling domain)
  • sibling glue <-> strict glue
  • BINDとNSDはsibling glueを返す実装になっている。
  • sibling glue: エセグルーとよんでいる。
  • 例:
    • www.ctc.co.jp. NS ns1.hs.ctc.jp. 外部名 (a.dns.jpが知らない)
    • www.ctc.co.jp. NS ns2.dc.ctc.ad.jp. sibling

[2019-02-16 13:16]

休憩

わざわざ外部名をつかうのはレンタルサーバのIPアドレスが変更になってもだいじょうぶだから、というのがきこえてきた。

[2019-02-16 13:26]

DNS温泉4教材
  • http://www.e-ontap.com/dns/onsen4/
  • 否定応答
  • RFC2308は古い 問題を引き起している
  • QNAMEがCNAMEの指す先まで含むことになっている。BINDの実装を追認するRFCになっている?
  • FORWARDER: もともとfull resolverのこと。proxyのことだけだとおもいがちだが。
  • NXDOMAINなのにanswerにCNAMEがはいっているのはなぜか? contentsとcacheが混在しているか2つのゾーンをもっているか。
  • このRFCにはそもそも正しい(典型的な)NXDOMAINの例が載ってない。
  • NODATA:疑似応答コード. RCODE=NOERRORでanswerに適切なレコードがないことで示す。
  • SOAのMINIMUMフィールドとSOA自身のTTLの小さい方がネガティブキャッシュのTTLになる。
  • dig soa iij.ad.jp.
    • iij.ad.jp. 86500 SOA ... 3600
  • dig wwwwwww.iij.ad.jp @dns0.iij.ad.jp +norec
  • 否定応答ではSOAのTTLはSOAのTTLとminttlの小さい方にセットされるべき。
  • もし小さい値にセットしない実装があった場合、クライアント側が小さい方を選ばないといけない。
  • 古い実装でNXDOMAINのときに上位のNSを返してくるものがある。example.jp.がjp. NSを返してくるとか。そんなものは信用でいない。簡単に毒入れできてしまう。
  • server failure: 設定がおかしいときはだまりこむのがいいとおもう(鈴木)。
  • server failureはTTLが提供されないにもかかわらずネガティブキャッシュしてよいと書いてある。このRFCおかしい。
  • キャッシュサーバはSOAをちゃんと返す。
  • RFC2308のおかしいところがRFC8020でやっと訂正された。
  • タイトル: NXDOMAIN: There Really Is Nothing Underneath
  • nom.のしたにsub.example.nom.があるけどexample.nom.がない、という場合がある(最近はかなり減った)
  • pseudoの発音は「スド」
  • NXDOMAINがかえってきたら、その下はすべて存在しないと扱ってよい。RFC2308を訂正して、もともとRFC1034にもどった。
  • 利益: QNAME minimizationのときに役だつ。
  • dig ns aws.amazon.com
  • dig aws.amazon.com @...amazon.com +norec
  • CNAMEがかえってくる
  • キャッシュサーバにきくとCNAMEチェインをたどってAまでかえしてくれる。
  • RFC的にはかえすのはおかしい。
  • dig com.cdn.amazon.com は権威サーバにといあわせるとNXDOMAINがかえってくるけど、その下にドメインはある。amazonはがんばって撲滅しようとしていらしいが... お客さん向けのはなおしたが、自分達用のはまだ残っている。
  • unboundでqname-minimisation: yes + qname-minimisation-strict:yes にしてみると、ひけなくなる。
  • www.chuko-u.ac.jpのNSがxxx.elb.amazonawx.com.になっているのでこまった。
  • elb.amazonawx.com. TXT を置くようにした。実装はいじらずに。

[2019-02-16 14:30]

  • cache-min-ttl おおきくしすぎると浸透しなくなる
  • cache-max-ttl メモリ使用量とのかねあいか?
  • TTL 0はキャッシュするなという意味。
  • TTLみじかすぎるとcache poisoningによわい。
  • TTLの推奨値はRFCにはない。
  • kantei.go.jp. はTTL 300 にしている(たぶんDoSくらったときに逃げられるように)がjpのサーバは86400をかえしてくる。
  • DNS温泉番外編2016でくわしくやった。
  • cache serverはcontents serverのTTLを減算していった値をSOAでstubに返すが、maxできりつめた値を返すかどうかは実装しだい。RFCにはそこまでかいてない。
  • BINDで孫ゾーンをつくれば子ゾーンをNXDOMAINにできるかも。ゾーン共存サーバの場合。

[2019-02-16 14:51]

休憩

IMG_20190216_145301IMG_20190216_170815

[2019-02-16 15:05]

RFC5155補足資料 / こやね @xkoyane_1220366x

  • DNSSEC: RFC4033,4034,4035で規定、キャッシュポイズニング対策
  • レコード: RRSIG(RRのsign),DNSKEY(pubkey),DS(KSK pubkey hash;上位ゾーンに登録する),NSEC3(ゾーンに存在するレコードをしめすもの)
  • ZSK: zone signing key, RRを署名するもの
  • KSK: key signning key, ZSKを署名するもの
  • ZSKだけで構築すると、鍵長を長くすると応答が大きくなってよくない。鍵を更新するときの手間がかかる。
  • KSKは鍵長をながくして、ZSKは小さくする。
  • ルートの公開鍵はcache serverからもってくるか、公開されているものをもってくる。
  • (KSKロールオーバのはなしは省略)
  • rfc5155: ゾーン列挙をむつかしくする。
  • NSECレコードをつかった場合はNSECチェーンをたどってゾーンの名前を列挙できてしまう。
  • NSEC3レコード: 名前をハッシュ化する
  • secure delegation: NSのほかにDSもある移譲
  • insecure delegation: NSだけ。
  • ENT: empty non-terminal. レコードがないけどサブドメインがあるもの.
  • .example. IN NSEC3 1 MX RRSIG
  • flag=1はOpt-Outを意味する。
  • hash = base32_rfc4648((sha1**iterations)(domain_nameの内部表現 + salt))
  • ハッシュをもとめるツール: nsec3hash(ISC), ldns-nsec3-hash(NLnet Labs)
  • ハッシュ整列順: ハッシュ値でソート
  • 不存在証明
  • dig a.c.x.wexample. @example.koyane.net +norec
  • closerXXXX name
  • dig a.c.x.w.example. @example.koyane.net +norec
  • next closerXXXX name
  • ワイルドカード
  • 最近接名 closest encloser
  • Q: dns cookieとかqnameのhashをつかわずにnsec3のようなふくざつなものをつかうりゆうは?
  • A: 動的に署名するのを避けた(パフォーマンス)。キャッシュサーバの容量節約(範囲でネガティブキャッシュできるとうれしい)。 CDNで肯定応答を動的に署名しているものがあるらしい。
  • Q: ラベルはany binaryということだったが、正規化はどうしてる?
  • A: たぶんそのまま。英字は小文字にするとおもう。
  • Q: cloud flareでrfc4470 NSECをかえしてきたが、なにかわかる?
  • A: わからん。
  • opt-out: insecure delegationのやつはNSEC3の生成を省略する。
  • opt-out=1だとNSEC3で署名されてないかもしれないことを示す。
  • ENTは省略
  • Q: sha1なのはなぜ?
  • A: rfc5155に書いてあるから。長いのはいやだ。NSEC3のフィールドにアルゴリズムは書いてある。あまり強くする必要もない。saltもiterationsも公開されてるし。辞書をつくりにくくするだけ。djbが辞書ツールを公開している。

[2019-02-16 15:56]

第一フラグメント便乗攻撃(アイコラ攻撃) / こやね @xkoyane

  • http://www.convivial.ne.jp/dns/extra2019/aikora.pdf
  • IPフラグメントのリアセンブル処理を悪用したもの。
  • IDがでた。藤原さん https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-00
  • 権威サーバに偽装した2ndフラグメントをリゾルバおくりつけておく。
  • EDNSでメッセージサイズが大きくできるようになった。
  • EDNSはDNSSECとIPv6では必須
  • unboundはDOビットをつねにセットして要求してくる。(RRSIGかえってきても検証しないならむだになるのに)
  • フラグメントされると: source port random, ID random,が無効になる
  • UDPチェックサム
    • チェックサムは毎回変化するが、応答内容とフラグメントする位置が固定なら事前に偽造2ndフラグメントをつくっておける。
    • 2バイトあればチェックサムは調整できる。4バイトのTTLがつかいやすい。パディングオプションもつかえる。
  • あんがいフラグメントするほどメッセージを大きくするのはむつかしい。
  • 権威サーバに対して Path MTU discoveryをつっこむのが簡単。ICMP echoをおくりつけたあとICMPをおくる。
  • PMTUDのキャッシュ時間はlinuxだと10分。
  • 2ndフラグメントのチェックサムがあわないようにして権威サーバをつかえなくさせる攻撃もありえる。
  • RRSIGをNSに差し替える攻撃: 否定応答を差し替える攻撃になる。
  • オープンレゾルバ 9.9.9.9 はこの攻撃に脆弱
  • (ついてくのつらい)
  • record rankkingが高いのを偽装できるとよりよい。

[2019-02-16 16:25]

ドメインハイジャックのデモ (公開不可)

[2019-02-16 16:36]

  • 対策
    • EDNSを512バイトにする
    • TCPフォールバック
    • 検証しないときはDO=0で
    • xxx
    • フラグメントUDPはうけとらない。
    • xxxx

[2019-02-16 16:39]

  • Q: path mtu discoveryをブロックする対策は実際にはむつかしいのでは? 他のUDPをつかうアプリへの影響があるので。
  • A: 権威サーバで対策するだけなので、権威サーバとアプリサーバを兼用しなければok
  • Q: TCPだと?
  • A: UDPよりは困難になるがMITMの可能性もあるし。
  • 藤原さんのI-DだとMTU 1220(IPv6のmin)を推奨している。1220より短かいMTUは攻撃だとみなすということで。

[2019-02-16 16:44]

Fuzzing DNS Full-Resolvers. / 坂口俊文 @siskrn_1220367x

  • fuzzing: へんなデータをおくって挙動をみる
  • 権威サーバを自作+改造して応答をランダムに変える。
  • データを書き換えたり、メッセージをエンコードしたあとに書き換えたり。
  • スタブリゾルバも自作 ランダムな問い合わせをする。

[2019-02-16 17:00]

[2019-02-16 17:03]

Route53で親子同居 / @otsuka0752_1220368x_1220369x

  • リモートLTはうまくいかなかったので代行で
  • aws
  • route53
  • publichostedzone
  • 親子同居ゾーンはみつからなかった

[2019-02-16 17:07]

終了

懇親会

  • 味仙(あじせん;みせん、ではない)にて。
  • 食べ放題・飲み放題 会費4000円
  • 8.8.8.8からの問い合わせをブロック方法: 自分で8.8.8.8に問い合わせして、アドレスを収集してフィルタに登録しているとのこと。
  • 研究室に名前をつけろということで、じょうだんで「インターネット崩壊研究室」で出したら通ってしまった、とのこと。

IMG_20190216_172740IMG_20190216_180058IMG_20190216_182925IMG_20190216_183012IMG_20190216_184338

_1220373x

IIJlabセミナー: 進化するロギング: デバッグのための古くて新しい技術

IMG_20190122_173812

ロギングはバグを特定するための古典的な手法である.ログとして記録してお
くイベントの品質が,そのままデバッグの効率に直結する.それにもかかわら
ず,従来のロギングでは開発者の経験と勘に基づいて
1) ログを出力するコード上の場所(where to log) と
2) 記録しておくべき情報 (what to log)
をアドホックに決定している.そのため,デバッグ時に必要十分な情報が得ら
れるとは限らず,デバッグを困難なものとする一因となっている.
本発表では,ログの品質を改善する「ロギングコード自動挿入」に関する最近
の研究成果を紹介する.ログの自動挿入はここ数年にわたって活発に研究され
ており,システムソフトウェア研究のトピックのひとつとなっている.既存研
究を概観したのち,発表者等が研究・開発を進めているロギング・ツールK9
について紹介する.K9 はマルチスレッド環境におけるエラー伝播を対象とし
ており,共有データを介したスレッド間でのエラー伝播の追跡を可能とする.
共有データを介したエラー伝播が発生すると,障害を起こしたスレッドのコン
トロールフローを遡っても,障害の原因となったバグにたどり着けるとは限ら
ない.K9 ではそのようなエラー伝播の追跡を支援する.実際に,K9 をLinux
カーネルに適用し,既知のカーネル・バグ 3 種の追跡が可能であることを確
認した.さらに,Linux のファイルシステム保守中に遭遇した未知の障害にも
適用し,バグの特定に有益であることを確認した.

IMG_20190122_174848IMG_20190122_175121

[2019-01-22 18:00]

  • 障害が発生したら(教科書的には): 再現→調査→対策
  • しかし:
    • そもそも再現がむつかしい。
    • 同じ実行環境が手にはいらない。
    • プライバシの観点からデータが手に入らない。
  • かわりのログを送ってもらいログを調査する。
  • しかし:
    • ログが膨大すぎて解析できない。
    • 肝心の手掛かりとなる情報がログにない。
  • 経験と勘に基づいたロギングが原因。
    • システムコールのエラー。
    • 例外的な処理。
    • 気分で入れてるだけ。
    • windows SOSP 2009
    • printf, log4j, syslog event tracing for windows (ETW)
  • 適切なログイングは難しい。
  • 専門用語:
    • logging too little: ログが少なすぎる
    • logging too much (redundant&trivial): 冗長だったり、あたりまえの内容だったり。オーバヘッド・ストレージ使用量が問題になる。
  • ロギングが研究テーマになったのは数年前から
    • 手動から自動へ
    • where to log?: どこに入れるか?
    • what to log?: どんな値を記録すればよいか?
    • what happend?: ログから障害発生の様子を自動抽出して障害の実行パスを類推する。
  • Errlog [Yuan+ OSDI'12]
    • どこでログを入れるか、入れわすれたところに自動でログを入れる。
    • 例外処理:
      • 実際にはログを取り忘れるケースが多い。250件の障害事例を調査。
    • error()を呼んでたらエラー処理というような判定をする。error()を呼ぶ条件式を集めて、ログを入れ忘れているところに追加する。プログラマは無能ではない前提。
  • SherLog [ASPLOS'10]
    • what happend? ログから実行パスを類推する。Sharはシャーロックホームズから。
  • LogEnhancer[ASPLOS'11]
    • 実行パスが類推できるように変数の値をロギングする。
  • K9ではLinuxをターゲットにした。
    • Linux as Infrastructure
    • Linuxは実用的・巨大・複雑なので、Linuxでつかえれば他のソフトでも使える。
  • 用語:
    • fault: =bug 誤りのこと バグがあっても踏まないと発症しない
    • error: バグをふんでおかしくなった状態
    • error propagation: おかしな状態は伝搬する
    • failure: 障害発生(クラッシュ・ハングアップ)
  • Palix:
    • Null: nullチェックもれ
    • Inull(Inconsistent null check): ポインタ参照(deref)したあとにnullチェック(意味がない)
    • Block: ブロックしてはいけないコンテキストでブロックする関数をよぶ
  • linuxにはだいたいいつでも700個くらいバグが残っている。
    • バグをつぶしても同じくらいバグが入ってくる。
    • 1行あたりのバグは減っている。
  • 簡単なバグだけではない
    • 関数にまたいだ問題
    • 割り込み(非同期)
  • Inter-thread error propagation
      • Btrfsでworker threadが例外時にdirtyフラグを落すのを忘れて
      • sync threadがBUG()を踏む
    • direct propagation: スレッド1が共有データを更新して、スレッド2が読む。
    • indirect propagation: スレッド1が共有データを更新して、スレッド2が読んで別の共有データを更新して、スレッド3が読む。
  • K9ではエラー伝搬を解析できるようにログを入れるが、linux規模のソフトでは正攻法は無理。
    • オーバヘッドを押える
    • 静的解析はしない
    • ポインタ解析はしない (やっても正確には分からないことが証明されている)
    • coding traditionを仮定して共有データをさがす。
      • 共有データはヒープに置かれる。
      • 共有データは構造体になっている。
        • そのなかのポインタ配列やリスト構造をみる。
        • リンクリストなどのデータ構造用のライブラリにも対応(対応しないとデータ構造を操作するだけの関数がログに出て呼び出し元が分からない)
    • indirect propagationはデータフローは追い掛けずに型レベルで推測する。
  • ファイルシステムにはバグが多いという論文がある and Btrfsは新しいファイルシステムなのでバグが多く残っているのでは? and 研究室の学生がBtrfsのメンテナ
  • Btrfsで未知のバグをK9で追い掛けた原因をつきとめられた (実証)
  • K9のオーバヘッドは、スループットで1.83%(平均)、CPU利用率で0.32%(平均)。
  • たまにスループットのオーバヘッドが少ないという論文があってもCPU使用率が高いケースがある。その場合はCPUに余裕がないとスループットが悪くなる。

[2019-01-22 19:16]

QA

  • Q: ログを入れたのはファイルシステムだけ?
  • A: yes。だがファイルシステムのコードから呼ばれている関数にもログが入っている。スケジューラとかメモリ管理とか。これら(sched,mem)にはバグが少ないという研究報告がある。クリティカルセクション内でログを吐かないようにすることで、よりオーバヘッドを減らせる余地がある。
  • Q: ロックには注目しないのか?
  • A: ロックの範囲を調べるのが簡単ではないのと、ロックが保護している変数を見つけるのも難しい。ロックもれがあった場合に困る。やってみたが良くなかった。
  • Q: K9の論文は公開されているか?
  • A: 投稿中。
  • Q: オープンソースにするのか? それとも企業に買収されるのを期待しているのか?
  • A: 日立との共同研究なので日立が買う可能性はあるが、オープンソースにする予定になっている。
  • Q: C以外の言語でもつかえるか?
  • A: LLVMの中間言語で解析しているので、言語に特化したものでなければいけるはず。

[2019-01-22 19:24]

IMG_20190122_194128

関連資料?
記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    ギャラリー
    • 今日の練習 2019-10-14(2)
    • 今日の練習 2019-10-14
    • 今日の練習 2019-10-14
    • 今日の練習 2019-10-14
    • VoidTokyo vol.6
    • VoidTokyo vol.6
    Amazon
    楽天市場
    adby google
    LINE読者登録QRコード
    LINE読者登録QRコード
    • ライブドアブログ